MySQL慢查询优化需系统推进：先通过慢日志和EXPLAIN定位瓶颈，再从SQL与索引、表结构、配置及硬件五层针对性优化，强调归因分析与持续迭代。
MySQL慢查询本质是资源消耗过大或执行路径低效，解决核心是定位瓶颈 + 针对性优化。不是盲目加索引或调参数，而是从SQL写法、索引设计、表结构、配置和硬件五个层面系统推进。
一、快速定位慢查询根源
先确认“谁慢”、“为什么慢”，再动手优化，避免瞎调。
- 开启慢查询日志：slow_query_log = ON，设置long_query_time = 1（单位秒，按业务容忍度调整）
- 用mysqldumpslow或pt-query-digest分析日志，聚焦Rows_examined高、执行时间长、出现频次高的SQL
- 对单条慢SQL执行EXPLAIN，重点看type（是否用到索引）、key（用了哪个索引）、rows（扫描行数）、Extra（是否有Using filesort/Using temporary）
二、SQL与索引优化是见效最快的一环
80%的慢查询可通过改写SQL或补全索引解决，优先做。
- 避免SELECT *，只查必需字段；少用LIKE '%xxx'、OR、NOT IN等易失效索引的操作
- 联合索引遵循最左前缀原则：WHERE a=1 AND b=2 AND c>3，索引应建在(a,b,c)而非单独建多个单列索引
- 区分覆盖索引：如果SELECT a,b WHERE a=1，索引(a,b)可避免回表，显著提速
- 对排序分页场景，避免OFFSET大值：用WHERE id > 上一页最大id LIMIT 20替代LIMIT 10000,20
三、表结构与数据访问模式要匹配
设计不合理，索引也救不了。关注字段类型、拆分逻辑和读写分离可能性。
- 字段能用TINYINT不用INT，VARCHAR(50)够用就别设VARCHAR(255)——减少I/O和内存占用
- 大文本（如content、html）或冷数据（如历史日志）建议垂直拆分到独立表，主表保持轻量
- 高频写+低频读的场景（如计数器），可用缓存+异步落库，避免直接COUNT(*)或频繁UPDATE
- 读多写少且数据量大的业务，考虑读写分离，让从库承担报表、搜索等压力
四、配置与硬件兜底，但别依赖
参数调优有收益，但边际效应明显；硬件升级见效快，成本也高。适合在前面几层优化后收尾使用。
- innodb_buffer_pool_size设为物理内存的60%~75%（专用DB服务器），确保热数据常驻内存
- 适当增大sort_buffer_size和join_buffer_size（单连接级别），但避免全局设过大导致内存争抢
- SSD替代HDD、增加内存、升级CPU，对I/O密集或复杂计算型查询提升明显
- 注意：不要盲目调query_cache_size（MySQL 8.0已移除），它在高并发写场景下反而成瓶颈
基本上就这些。慢查询优化不是一次动作，而是“监控→分析→验证→迭代”的闭环。上线前用生产级数据压测，上线后持续观察慢日志变化。不复杂但容易忽略——关键在坚持归因，而不是堆技巧。
