首先检查系统资源使用情况，确认CPU、内存、磁盘IO是否存在瓶颈；接着启用慢查询日志并用pt-query-digest分析耗时SQL；通过SHOW PROCESSLIST和Performance Schema查看实时状态及SQL执行统计；再结合EXPLAIN检查索引使用情况，优化执行计划；最后定期巡检慢日志、监控连接数与缓冲池命中率，实现精准性能调优。
MySQL性能瓶颈的分析需要从多个维度入手，结合系统资源、数据库状态和SQL执行情况综合判断。关键在于快速定位问题源头，避免盲目优化。
查看系统资源使用情况
数据库性能受服务器硬件资源限制，首先要确认是否存在资源瓶颈：
- CPU使用率高：可能由复杂查询、大量计算或并发连接过多引起。可通过top或htop查看MySQL进程的CPU占用。
- 内存不足：若频繁发生swap，说明物理内存不够。检查innodb_buffer_pool_size设置是否合理，通常建议为物理内存的70%-80%。
- 磁盘IO过高：使用iostat观察磁盘读写延迟和吞吐量。长时间等待IO通常意味着索引缺失或缓冲池太小。
启用并分析慢查询日志
慢查询是性能问题的主要来源之一，开启慢查询日志能帮助识别耗时SQL：
- 在my.cnf中配置：slow_query_log = ON，long_query_time = 1（单位秒）
- 配合pt-query-digest工具分析日志，输出执行时间最长、调用次数最多的SQL语句。
- 重点关注全表扫描（Extra: Using filesort / Using temporary）的查询。
使用SHOW PROCESSLIST和Performance Schema
实时查看当前数据库运行状态：
- 执行SHOW FULL PROCESSLIST，观察是否有大量处于"Sending data"、"Copying to tmp table"等状态的连接。
- 启用Performance Schema可追踪SQL执行细节，如锁等待、文件IO、语句执行统计等。
- 查询performance_schema.events_statements_summary_by_digest表，找出平均响应时间高的SQL模板。
检查索引与执行计划
不合理或缺失的索引会显著影响查询效率：
- 对可疑SQL使用EXPLAIN分析执行计划，关注type（最好为ref或range）、rows扫描行数以及key是否命中索引。
- 避免在WHERE条件中对字段进行函数操作或类型转换，会导致索引失效。
- 考虑创建覆盖索引减少回表次数，特别是高频查询字段组合。
