ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花

慢SQL是MySQL数据库性能瓶颈的核心诱因之一，会导致数据库响应延迟、连接占用过高、CPU/IO负载飙升，甚至引发服务雪崩。本文梳理慢SQL从“排查定位—原因分析—紧急处理—深度优化—监控预防”的全流程，覆盖实操步骤、核心技巧和避坑点，适配各类业务场景，助力快速解决慢SQL问题。

一、前置准备：明确慢SQL判定标准

在排查前，需先定义慢SQL。MySQL默认通过long_query_time参数判定慢SQL，默认值为10秒（可根据业务调整），即执行时间超过该值的SQL会被记录到慢查询日志中。

补充说明：业务层面的慢SQL可能更严格（如核心接口SQL执行超过500ms就影响体验），需结合业务场景调整判定阈值，避免仅依赖数据库默认参数。

二、第一步：排查定位——找到慢SQL及影响范围

核心目标：快速找到执行缓慢的SQL语句、确定其执行频率、影响的业务模块及当前对数据库的负载压力，为后续分析提供依据。主要分为3种常用方式，优先使用轻量、无侵入的方式。

2.1 方式1：查看慢查询日志（最核心、最常用）

慢查询日志是MySQL自带的日志功能，会记录所有执行时间超过long_query_time的SQL，包含执行时间、锁等待时间、扫描行数等关键信息，是排查慢SQL的核心依据。

2.1.1 开启慢查询日志（临时/永久）

临时开启（重启MySQL后失效，适合紧急排查）：

-- 开启慢查询日志
set global slow_query_log = 'ON';
-- 设置慢查询阈值（单位：秒，如设置1秒，可根据业务调整）
set global long_query_time = 1;
-- 查看慢查询日志存储路径（默认在数据目录下，文件名一般为slow.log）
show variables like 'slow_query_log_file';

永久开启（需修改配置文件my.cnf/my.ini，重启MySQL生效）：

[mysqld]
# 开启慢查询日志
slow_query_log = ON
# 慢查询阈值（单位：秒）
long_query_time = 1
# 慢查询日志存储路径
slow_query_log_file = /var/lib/mysql/mysql-slow.log
# 记录未使用索引的SQL（可选，建议开启，便于发现索引缺失问题）
log_queries_not_using_indexes = ON

2.1.2 分析慢查询日志（工具+手动）

手动查看（适合日志量较小的情况）：直接打开慢查询日志文件，重点关注以下字段：

• Query_time：SQL执行时间（核心，超过阈值即为慢SQL）；
• Lock_time：锁等待时间（若该值较大，说明SQL存在锁竞争问题）；
• Rows_examined：扫描的行数（扫描行数越多，效率越低，理想状态下应接近Rows_sent）；
• Rows_sent：返回给客户端的行数；
• 最后一行：具体的SQL语句。

工具分析（适合日志量大的情况，高效筛选）：

常用工具：mysqldumpslow（MySQL自带，轻量）、pt-query-digest（Percona Toolkit，功能强大，推荐）。

# mysqldumpslow 用法（筛选执行时间最长的10条慢SQL，按执行时间降序）
mysqldumpslow -s t -t 10 /var/lib/mysql/mysql-slow.log

# pt-query-digest 用法（生成详细的慢SQL分析报告，包含执行频率、平均耗时等）
pt-query-digest /var/lib/mysql/mysql-slow.log > slow_sql_analysis.report

2.2 方式2：实时排查（适合SQL正在执行，紧急定位）

若数据库出现卡顿，怀疑有慢SQL正在执行，可通过show processlist实时查看当前数据库连接及SQL执行状态，快速定位正在运行的慢SQL。

-- 查看所有当前连接的SQL执行状态（重点关注State和Time字段）
show processlist;
-- 简化查看，只显示非Sleep状态的连接（Sleep状态为空闲连接，不消耗资源）
show processlist where Command != 'Sleep';

关键字段解读：

• Time：当前SQL执行时间（单位：秒），若超过阈值，即为正在执行的慢SQL；
• State：SQL执行状态（如Sending data、Waiting for table lock、Creating sort index等，不同状态对应不同问题）；
• Info：具体的SQL语句（若SQL较长，可使用show full processlist查看完整语句）。

2.3 方式3：业务日志关联（定位影响范围）

结合业务系统日志，找到出现响应延迟的接口，通过接口调用的SQL语句，关联到数据库中的慢SQL，明确慢SQL影响的业务模块（如订单、支付、商品列表等），便于后续优先处理核心业务的慢SQL。

2.4 特殊场景：线上接口RT过长，定位是否为慢SQL问题

线上接口响应时间（RT）过长时，可能由应用层、网络层、缓存层或数据库层（慢SQL）导致，需按从外到内、逐步排查的思路，精准定位是否为慢SQL引发，避免盲目排查。核心逻辑：先拆分接口耗时，再锁定数据库调用环节，最终验证SQL执行效率。

2.4.1 步骤1：接口耗时拆分，初步定位异常环节

首先通过链路追踪工具或应用日志，拆分接口的整体耗时，区分“应用层耗时”“缓存层耗时”“数据库层耗时”，判断问题是否出在数据库。

• 工具推荐：SkyWalking、Pinpoint、Zipkin（链路追踪工具），可直观看到接口各环节耗时占比；
• 核心判断：若接口总RT远超业务阈值（如核心接口RT>3s），且“数据库调用环节”耗时占比超过80%（如数据库调用耗时2.8s），则大概率是慢SQL导致；若数据库调用耗时<100ms，则问题多在应用层（如代码逻辑、循环调用）、缓存层（如缓存失效、缓存穿透）或网络层。

实操示例：通过SkyWalking查看接口链路，发现查询用户订单接口总RT=3.5s，其中MySQL查询环节耗时3.3s，其他环节（参数校验、缓存查询）耗时仅0.2s，初步判断为慢SQL导致。

2.4.2 步骤2：关联应用日志，提取可疑SQL语句

从应用日志中，提取接口对应的数据库查询SQL，重点关注SQL执行时间调用次数，锁定可疑慢SQL。

• 日志排查重点：查看应用框架日志（如MyBatis、JDBC），筛选包含SQL执行时间SQL语句的日志，例如：SQL: select * from order where user_id=? and status=?，执行时间：3200ms；
• 关键注意点：若应用日志中未记录SQL执行时间，需临时开启日志打印（如MyBatis开启logImpl=SLF4J），但注意线上环境开启后需及时关闭，避免日志量过大；
• 筛选规则：优先提取执行时间>业务阈值（如500ms）调用频率高的SQL，这类SQL是导致接口RT过长的核心可疑对象。

2.4.3 步骤3：验证SQL执行效率，确认是否为慢SQL

将应用日志中提取的可疑SQL，在数据库中执行验证，结合慢查询日志、执行计划，确认是否为慢SQL。

1. 对比慢查询日志：查看慢查询日志（slow_query_log），确认该SQL是否被记录（执行时间超过long_query_time）；若未被记录，需检查long_query_time阈值是否过宽（如默认10s，而业务SQL执行3s已影响接口RT），可临时调整阈值（set global long_query_time=0.5）后重新排查；
2. 实时执行验证：在数据库中执行该SQL，记录实际执行时间，若执行时间超过业务阈值，可确定为慢SQL；
3. 执行计划分析：用explain命令分析该SQL的执行计划，查看是否存在全表扫描（type=ALL）、索引失效（key=NULL）、文件排序（Using filesort）等问题，进一步确认SQL执行低效的原因。

2.4.4 步骤4：排除其他干扰因素，锁定根因

排除非慢SQL因素，确保问题定位准确，常见干扰因素及排查方法：

• 排除网络问题：检查应用服务器与数据库服务器之间的网络延迟（ping 数据库IP、telnet 数据库端口），若网络延迟>100ms，需先排查网络链路、防火墙配置；
• 排除缓存问题：若接口依赖缓存（如Redis），检查缓存命中率、缓存是否失效，若缓存失效导致大量请求穿透到数据库，会引发数据库压力增大，间接导致SQL执行变慢（需结合数据库CPU、连接数判断）；
• 排除锁竞争问题：查看可疑SQL的Lock_time字段（通过慢查询日志或show processlist），若锁等待时间>1s，说明存在锁竞争（参考3.4节），并非单纯SQL执行低效；
• 排除数据库负载过高：查看数据库CPU、IO、连接数（show global status like 'Threads_connected'、show engine innodb status），若CPU使用率>80%、IO负载过高，可能导致所有SQL执行变慢，需先缓解数据库负载。

2.4.5 实操总结

线上接口RT过长定位慢SQL的核心流程：链路拆分找异常环节 → 应用日志提可疑SQL → 数据库验证SQL效率 → 排除干扰锁根因。通过该流程，可快速区分是否为慢SQL导致的接口延迟，避免盲目优化应用代码或数据库配置，提升排查效率。

三、第二步：原因分析——定位慢SQL的核心诱因

找到慢SQL后，核心是分析其执行缓慢的原因，常见诱因分为4大类：索引问题、SQL语句本身问题、数据库配置问题、锁竞争问题。需逐一排查，精准定位。

3.1 索引问题（最常见，占比80%以上）

索引是提升SQL执行效率的核心，索引问题主要包括：无索引、索引失效、索引设计不合理。

3.1.1 检查SQL是否使用索引

使用explain命令分析SQL执行计划，查看是否使用索引（重点关注type、key、rows字段）。

-- 语法：explain + 慢SQL语句
explain select * from order where user_id = 123 and create_time > '2026-01-01';

关键字段解读（判断索引是否生效）：

• type：连接类型，级别从优到差为：system > const > eq_ref > ref > range > index > ALL；若为ALL，说明全表扫描，未使用索引；
• key：实际使用的索引，若为NULL，说明未使用任何索引；
• rows：预估扫描的行数，行数越多，执行效率越低；
• Extra：额外信息，若出现Using filesort（文件排序）、Using temporary（临时表），说明SQL需要优化，会增加执行耗时。

3.1.2 索引失效的常见场景（重点避坑）

• 索引列使用函数（如substr(user_id, 1, 3)、date(create_time)），会导致索引失效；
• 索引列使用模糊查询（如like '%123'，前缀模糊匹配会失效，后缀模糊like '123%'不会失效）；
• 索引列使用逻辑运算（如user_id != 123、user_id <> 123），会导致索引失效；
• 联合索引不满足“最左匹配原则”（如联合索引为(user_id, create_time)，SQL查询条件仅用create_time，会导致索引失效）；
• 索引列存在NULL值（MySQL对NULL值的索引处理特殊，若索引列有大量NULL，会影响索引效率，甚至失效）；
• 数据量过小/统计信息过时（MySQL优化器会判断是否使用索引，若表数据量极小，优化器可能选择全表扫描；统计信息过时会导致优化器误判，不使用索引）。

3.1.3 索引设计不合理

如索引过多（导致插入/更新/删除操作变慢，因为需要维护索引）、索引过少（导致查询全表扫描）、联合索引顺序不合理（未将查询频率高、区分度高的字段放在前面）。

3.2 SQL语句本身问题

即使有索引，不合理的SQL语句也会导致执行缓慢，常见问题：

• 查询字段过多（如使用select *，查询不需要的字段，增加IO负载和数据传输时间）；
• 子查询过多/嵌套过深（子查询效率低，可优化为join查询）；
• join查询不合理（如多表join时，小表未放在左边，或join条件无索引）；
• 排序/分组不合理（如排序字段无索引，导致Using filesort；分组字段无索引，导致分组效率低）；
• 重复查询（同一SQL多次执行，未做缓存，浪费数据库资源）。

3.3 数据库配置问题

数据库配置不合理，会导致即使SQL和索引正常，也会执行缓慢，常见配置问题：

• 缓存配置不足（如query_cache_size过小，缓存命中率低，导致重复查询需要重新执行）；
• 连接池配置不合理（如max_connections过小，导致连接排队；wait_timeout不合理，导致空闲连接占用资源）；
• 内存配置不足（如innodb_buffer_pool_size过小，InnoDB缓存不足，导致频繁读取磁盘，IO负载飙升）；
• 日志配置不合理（如binlog日志刷盘策略过严，导致写入延迟，影响SQL执行）。

3.4 锁竞争问题

若慢SQL的Lock_time字段值较大，说明存在锁竞争，常见场景：

• 行锁竞争（如同一行数据被多个事务同时更新/删除，导致锁等待）；
• 表锁竞争（如执行alter table、lock table等操作，导致表级锁，阻塞其他查询）；
• 死锁（两个或多个事务互相持有对方需要的锁，导致长时间阻塞）。

三、第三步：紧急处理——快速缓解慢SQL影响

若慢SQL已导致数据库卡顿、业务不可用，需先紧急处理，缓解影响，再进行深度优化。核心原则：快速终止异常SQL，减少资源占用，临时规避问题。

3.1 终止正在执行的慢SQL

通过show processlist找到慢SQL的Id（连接ID），使用kill命令终止该SQL执行：

-- 查看正在执行的慢SQL，获取Id
show full processlist;
-- 终止指定Id的SQL（Id为具体的连接ID）
kill 123; -- 123为慢SQL对应的Id

注意：若慢SQL是核心业务SQL，不可直接kill，需先评估影响，可临时降级业务（如关闭非核心接口），再处理。

3.2 临时规避措施

• 临时添加索引（若确定是索引缺失导致，可临时创建索引，快速提升执行效率；后续需优化索引设计）；
• 临时关闭非核心业务查询（减少数据库负载，优先保障核心业务SQL执行）；
• 临时调整数据库配置（如临时增大innodb_buffer_pool_size、query_cache_size，缓解IO和缓存压力，重启后失效）；
• 读写分离（若有读写分离架构，可将查询请求临时切换到从库，减轻主库压力）。

四、第四步：深度优化——从根源解决慢SQL问题

紧急处理后，需针对慢SQL的核心诱因，进行深度优化，避免问题再次出现。优化顺序：先优化SQL语句，再优化索引，最后优化数据库配置和架构。

4.1 SQL语句优化（最易操作，优先优化）

4.1.1 简化查询字段，避免select *

只查询需要的字段，减少IO传输和内存占用，示例：

-- 优化前（查询所有字段，冗余）
select * from order where user_id = 123;
-- 优化后（只查询需要的字段）
select id, order_no, create_time from order where user_id = 123;

4.1.2 优化子查询，替换为join查询

子查询效率低，尤其是嵌套子查询，可替换为join查询，减少查询次数，示例：

-- 优化前（子查询）
select * from order where user_id in (select id from user where age > 18);
-- 优化后（join查询）
select o.* from order o join user u on o.user_id = u.id where u.age > 18;

4.1.3 优化join查询

• 小表驱动大表（将数据量小的表放在join左边，减少循环次数）；
• join条件必须加索引（join字段需建立索引，避免全表扫描）；
• 避免过多表join（一般不超过3-4张表join，过多会导致执行计划复杂，效率降低）。

4.1.4 优化排序和分组

排序/分组字段需建立索引，避免Using filesort和Using temporary，示例：

-- 优化前（create_time无索引，会出现Using filesort）
select * from order where user_id = 123 order by create_time desc;
-- 优化后（给(user_id, create_time)建立联合索引，避免排序）
select id, order_no, create_time from order where user_id = 123 order by create_time desc;

4.1.5 避免重复查询，使用缓存

对于频繁执行、结果不变的SQL（如商品详情、字典数据），可使用Redis等缓存工具，将查询结果缓存，减少数据库查询次数。

4.2 索引优化（核心优化，提升查询效率）

4.2.1 建立合适的索引

• 单表查询：给查询条件（where、order by、group by）中的字段建立索引；
• 多表join：给join字段建立索引；
• 联合索引：优先将查询频率高、区分度高的字段放在前面，遵循“最左匹配原则”；
• 避免过度索引：一张表索引数量建议不超过5个，索引过多会影响插入/更新/删除效率。

4.2.2 优化失效的索引

针对索引失效的场景，逐一优化：

• 索引列避免使用函数：将函数逻辑转移到应用层，或修改查询方式（如date(create_time) = '2026-01-01'改为create_time between '2026-01-01 00:00:00' and '2026-01-01 23:59:59'）；
• 模糊查询优化：避免前缀模糊（%123），可使用全文索引替代；
• 逻辑运算优化：将user_id != 123改为user_id < 123 or user_id > 123（若有索引，可使用范围查询）；
• 更新统计信息：若统计信息过时，执行analyze table 表名，更新表统计信息，让优化器正确判断是否使用索引。

4.2.3 删除无用索引

通过show index from 表名查看所有索引，删除未使用、冗余的索引（如重复索引、低效索引），减少索引维护成本。

4.3 数据库配置优化（根据服务器资源调整）

核心配置优化（需结合服务器CPU、内存、磁盘IO调整，以下为常用优化建议）：

[mysqld]
# InnoDB缓存大小（建议设置为服务器物理内存的50%-70%，提升缓存命中率）
innodb_buffer_pool_size = 8G
# 查询缓存大小（若业务中重复查询较多，可适当增大；若查询频繁变化，可设置为0）
query_cache_size = 64M
# 查询缓存过期时间
query_cache_validity = 3600
# 最大连接数（根据业务并发量调整，避免连接不足）
max_connections = 1000
# 连接超时时间（释放空闲连接，避免资源占用）
wait_timeout = 600
# 慢查询阈值（根据业务调整，核心业务可设为0.5-1秒）
long_query_time = 1
# 开启慢查询日志和无索引查询日志
slow_query_log = ON
log_queries_not_using_indexes = ON

4.4 锁竞争优化

• 行锁优化：避免同一行数据被频繁更新/删除，可通过分表、批量操作替代单次操作；
• 表锁优化：避免在业务高峰期执行alter table、lock table等操作，可选择低峰期执行；
• 死锁优化：避免事务嵌套过深，减少事务持有锁的时间，合理安排事务执行顺序；通过show engine innodb status查看死锁信息，优化事务逻辑。

4.5 架构优化（高并发场景必备）

若单库单表压力过大，慢SQL频繁出现，可通过架构优化提升性能：

• 读写分离：主库负责写入（insert/update/delete），从库负责查询，减轻主库压力；
• 分库分表：将大表（数据量超过1000万）按业务规则分表（如按时间分表、按用户ID分表），减少单表数据量，提升查询效率；
• 数据库集群：通过主从复制、集群部署，提升数据库可用性和并发处理能力；
• 引入中间件：如MyCat、Sharding-JDBC，实现分库分表、读写分离的透明化，降低开发成本。

五、实操案例：电商订单慢SQL优化实战

以下结合电商核心场景——用户订单列表查询，完整演示慢SQL从排查、分析到优化的全流程，贴合实际业务，可直接参考落地。

5.1 场景背景

电商平台“我的订单”接口，用户查询自己的订单列表（支持按订单状态筛选、按创建时间排序），高峰期接口响应时间超过3秒，远超业务阈值（500ms），被监控告警，疑似慢SQL导致。订单表order数据量1200万条，核心字段：id（主键）、order_no（订单号）、user_id（用户ID）、create_time（创建时间）、status（订单状态）、total_amount（订单金额）、pay_time（支付时间）等。

5.2 第一步：排查定位慢SQL

5.2.1 查看慢查询日志

通过mysqldumpslow筛选出高频慢SQL，核心慢SQL如下：

-- 慢SQL：用户查询自己的待付款订单，按创建时间倒序
select * from `order` where user_id = 10086 and status = 1 order by create_time desc limit 10,20;

慢查询日志关键信息：Query_time=3.8s，Lock_time=0.001s，Rows_examined=15680，Rows_sent=20，可见扫描行数极多，锁等待时间短，排除锁竞争问题。

5.2.2 实时排查验证

执行show full processlist，发现该SQL在高峰期频繁执行，Time字段均超过3秒，State为Sending data，确认该SQL是导致接口延迟的核心原因。

5.3 第二步：原因分析

5.3.1 分析执行计划

执行explain分析该SQL的执行计划：

explain select * from `order` where user_id = 10086 and status = 1 order by create_time desc limit 10,20;

执行计划关键结果：

• type=ALL：全表扫描，未使用任何索引；
• key=NULL：未使用索引；
• rows=15680：预估扫描15680行数据；
• Extra=Using where; Using filesort：存在文件排序，增加执行耗时。

5.3.2 定位核心诱因

1. 索引问题：订单表仅主键id有索引，user_id、status、create_time均未建立索引，导致查询时全表扫描；

2. SQL语句问题：使用select *查询所有字段，包含pay_time等无需展示的冗余字段，增加IO传输时间；

3. 排序问题：create_time无索引，导致排序时触发Using filesort，效率极低。

5.4 第三步：紧急处理

1. 临时终止慢SQL：高峰期通过kill命令终止长期执行的该SQL，减少数据库资源占用；

2. 临时添加索引：紧急创建联合索引idx_userid_status_createtime（user_id, status, create_time），临时提升执行效率，命令如下：

create index idx_userid_status_createtime on `order`(user_id, status, create_time);

添加索引后，SQL执行时间从3.8s降至0.12s，接口响应时间恢复正常，缓解业务影响。

5.5 第四步：深度优化

5.5.1 SQL语句优化

删除冗余字段，仅查询订单列表所需字段，避免select *，优化后SQL：

-- 优化后：只查询订单列表所需字段，减少IO传输
select id, order_no, create_time, total_amount, status 
from `order` 
where user_id = 10086 and status = 1 
order by create_time desc limit 10,20;

5.5.2 索引优化（完善索引设计）

1. 保留临时创建的联合索引idx_userid_status_createtime，该索引贴合查询条件（user_id、status）和排序条件（create_time），遵循最左匹配原则，可避免全表扫描和文件排序；

2. 检查冗余索引：确认订单表无其他无用索引，避免索引维护成本；

3. 更新统计信息：执行analyze table `order`，确保优化器正确识别索引。

5.5.3 业务层面优化

1. 缓存优化：将高频查询的订单列表（如用户最近30天的订单）缓存到Redis，缓存过期时间设为5分钟，减少数据库查询压力；

2. 分页优化：限制订单列表最大分页页数（如最多查询100页），避免大量分页查询导致的慢SQL；

3. 数据清理：定期清理3年以上的历史订单数据（归档到历史表），将订单表数据量控制在800万条以内，提升查询效率。

5.6 优化效果验证

优化后，该SQL执行时间稳定在0.05-0.1s，接口响应时间控制在100ms以内，高峰期无慢SQL告警；订单表查询扫描行数从15680行降至20行，执行效率提升99%以上。

5.7 案例总结

电商订单类慢SQL，核心诱因多为「索引缺失/不合理」和「SQL语句冗余」，优化时优先通过索引解决全表扫描和排序问题，再简化SQL、结合缓存和数据清理，可快速实现性能提升。同时需结合业务场景，避免过度优化，平衡查询效率和写入效率（如订单表插入频繁，索引不宜过多）。

六、第五步：监控预防——避免慢SQL再次出现

慢SQL优化不是一次性操作，需建立长期监控机制，提前发现、提前优化，避免问题复发。

6.1 建立慢SQL监控体系

• 工具监控：使用Prometheus+Grafana、Zabbix等监控工具，实时监控慢SQL数量、执行时间、数据库负载（CPU、IO、连接数），设置告警阈值（如慢SQL数量超过10条/分钟，触发告警）；
• 日志监控：定期分析慢查询日志（如每天凌晨分析前一天的日志），统计慢SQL的执行频率、影响范围，提前优化；
• 业务监控：监控业务接口响应时间，若接口延迟超过阈值，关联排查对应的SQL语句。

6.2 规范开发流程，从源头规避慢SQL

• SQL审核：开发人员提交SQL代码时，需进行SQL审核（可使用工具如SQLAdvisor），检查是否存在无索引、索引失效、SQL不合理等问题；
• 开发规范：制定SQL开发规范，如禁止使用select *、禁止嵌套子查询过深、join表不超过3张、查询条件需加索引等；
• 测试验证：上线前，对核心SQL进行压力测试，模拟高并发场景，检查是否存在慢SQL。

6.3 定期维护数据库

• 定期优化索引：每季度检查一次索引使用情况，删除无用索引，优化低效索引；
• 定期更新统计信息：每季度执行analyze table，更新表统计信息，确保优化器正确判断执行计划；
• 定期清理数据：清理过期数据（如历史订单、日志数据），减少单表数据量，提升查询效率；
• 定期备份：避免因数据库故障导致数据丢失，同时备份过程中可检查数据库健康状态。

七、常见避坑点总结

• 不要盲目加索引：索引不是越多越好，过多索引会影响写入效率；
• 不要忽视统计信息：统计信息过时会导致优化器误判，索引失效；
• 不要使用select *：冗余字段会增加IO和内存压力；
• 不要忽视锁竞争：锁等待时间过长，会导致SQL执行缓慢，甚至阻塞；
• 不要只优化SQL，不监控：优化后需长期监控，避免问题复发；
• 不要在高峰期执行DDL操作（如alter table）：会导致表锁，阻塞其他查询。

八、总结

MySQL慢SQL的排查处理优化，核心是“先定位、再分析、先缓解、再根治、常监控”。优先通过慢查询日志和实时排查找到慢SQL，用explain分析核心诱因（重点关注索引和SQL语句），紧急情况下先终止慢SQL、临时规避，再通过SQL优化、索引优化、配置优化、架构优化从根源解决，最后建立监控和开发规范，避免问题再次出现。

实际场景中，需结合业务特点和数据库现状，灵活调整优化方案，优先保障核心业务的稳定性和执行效率。

ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花