定位 MySQL 性能问题，核心是“先看现象、再查源头、最后验证”。不要一上来就调参数或加索引，而是顺着请求路径逐层缩小范围：从慢查询、连接状态、锁等待，到资源瓶颈（CPU、IO、内存），再到 SQL 本身和执行计划。
一、快速识别“谁在拖慢数据库”
先确认是不是真有性能问题，以及问题集中在哪类操作上：
启用慢查询日志（slow_query_log=ON），设置合理阈值（如 long_query_time=1），定期分析 mysqldumpslow 或 pt-query-digest 输出，找出执行时间长、扫描行数多、调用频次高的 SQL 实时观察活跃会话：SHOW PROCESSLIST; 或查询 information_schema.PROCESSLIST，重点关注 State 列（如 Sending data、Copying to tmp table、Locked）和 Time 值大的线程 检查是否大量连接堆积：SHOW STATUS LIKE 'Threads_connected'; 对比 max_connections，若接近上限，需查连接未释放原因（应用未 close、连接池配置不合理等）二、排查锁与事务阻塞
很多“慢”其实是等出来的，尤其在高并发更新场景：
查当前锁等待：SELECT * FROM performance_schema.data_lock_waits;（MySQL 8.0+）或 SELECT * FROM information_schema.INNODB_TRX; + INNODB_LOCKS + INNODB_LOCK_WAITS（5.7 及以前） 重点关注 trx_state='LOCK WAIT' 的事务，结合 trx_mysql_thread_id 找出被谁阻塞、持有什么锁、正在执行哪条 SQL 检查长事务：SELECT * FROM information_schema.INNODB_TRX WHERE trx_started 长事务会阻止 purge、膨胀 undo log、加剧锁竞争三、分析 SQL 执行效率
单条 SQL 慢，不等于写得差，要结合执行计划和数据分布看：
对慢 SQL 执行 EXPLAIN FORMAT=JSON，重点看：type（是否用到索引）、key（用了哪个索引）、rows（预估扫描行数）、filtered（过滤率）、Extra（是否有 Using filesort、Using temporary） 注意“假命中”：type=ref 但 rows 过大，可能是索引选择性差或统计信息不准，可执行 ANALYZE TABLE 更新统计信息 避免隐式类型转换和函数操作字段（如 WHERE DATE(create_time) = '2024-01-01'），会导致索引失效四、检查系统与配置瓶颈
数据库跑在操作系统之上，底层资源不足会直接拖垮性能：
监控服务器指标：用 top、iostat -x 1、vmstat 1 查 CPU 使用率、IO 等待（%util、await）、内存交换（si/so） 关键 MySQL 状态变量：SHOW GLOBAL STATUS 中关注 Innodb_buffer_pool_wait_free（缓冲池紧张）、Innodb_log_waits（redo log 写满）、Created_tmp_disk_tables（临时表落盘多）、Sort_merge_passes（排序合并次数高） 检查配置合理性：比如 innodb_buffer_pool_size 是否过小（建议设为物理内存的 50%–75%），innodb_log_file_size 是否太小导致频繁 checkpoint排查不是线性流程，而是一个闭环：观察现象 → 提出假设 → 验证假设（改 SQL、加索引、调参数、重启服务等）→ 对比效果。工具只是辅助，理解业务逻辑和数据特征才是准确定位的关键。
