定位高并发下的慢SQL
高并发场景下，慢SQL往往不是单次执行慢，而是因锁争用、连接堆积或索引失效导致“雪崩式”响应延迟。优先通过 slow_query_log 开启慢日志（建议 long_query_time ≤ 1s），并配合 log_queries_not_using_indexes = ON 捕获隐式全表扫描。注意：高并发时慢日志本身有IO开销，可临时开启，问题复现后及时关闭。
结合Performance Schema实时分析
MySQL 5.6+ 的 Performance Schema 能精准定位高并发下的资源瓶颈。重点查以下三类表：
events_statements_summary_by_digest：按SQL指纹聚合，看哪些语句执行次数多、平均延时高、锁等待时间长 events_waits_summary_global_by_event_name：观察 wait/synch/mutex/sql/LOCK_table、wait/io/file/innodb/innodb_data_file 等等待事件是否突增 session_connect_attrs + processlist：关联应用端连接信息，识别是某类接口（如下单、查询订单）集中触发慢SQL检查执行计划与锁行为
对高频慢SQL，务必用 EXPLAIN FORMAT=JSON 查执行计划，重点关注：
type 是否为 ALL / index（全表/全索引扫描）；key 是否为 NULL 或非预期索引 rows 预估扫描行数是否远超实际返回行数（说明索引区分度差或条件未走索引） Extra 中出现 Using filesort / Using temporary / Using join buffer —— 高并发下极易成为瓶颈同时在业务低峰期模拟请求，用 SELECT * FROM performance_schema.data_locks 查当前锁持有情况，确认是否存在间隙锁（gap lock）阻塞、主键缺失导致的表级锁升级等问题。
验证与压测闭环
优化后不能只看单条SQL变快，必须回归业务场景验证：
用 sysbench 或 pt-archiver 模拟相同并发量（如 200+ 线程）、相同QPS压测关键SQL 对比优化前后 Threads_running、Innodb_row_lock_waits、Handler_read_rnd_next 等状态变量变化 观察应用端 P95/P99 响应时间、数据库 CPU 和 IO 利用率是否同步下降不复杂但容易忽略：很多“慢SQL”本质是连接池配置不当（如最大连接数过小）或应用未正确释放连接，导致后续请求排队等待——排查时务必把数据库指标和应用连接池日志一起看。
