优化慢查询是提升数据库性能最直接、性价比最高的手段，通过开启慢查询日志、用EXPLAIN分析执行计划、精简SQL写法及合理建索引，可将秒级查询降至毫秒级。
优化慢查询是提升数据库性能最直接、性价比最高的手段。多数情况下，不需升级硬件，仅通过定位问题查询、调整SQL写法和合理建索引，就能把几秒甚至几分钟的查询压到毫秒级。
从慢查询日志精准定位问题
别靠猜测，先让数据库告诉你哪条SQL在拖后腿：
- MySQL中执行：SET GLOBAL slow_query_log = ON; 和 SET GLOBAL long_query_time = 1;（1秒为阈值，可按需调低至0.1）
- 开启后查看日志路径：SHOW VARIABLES LIKE '%slow_query_log_file%';
- 用pt-query-digest分析日志，快速识别“高频+高耗时”的Top SQL，例如某条SELECT * FROM orders WHERE created_at > ?占了总延迟的40%
用EXPLAIN看清执行过程
对准慢查询运行EXPLAIN，重点看三列：
- type：出现ALL代表全表扫描，必须优化；理想是ref或const
- rows：预估扫描行数，从50万降到500，性能通常提升百倍
- Extra：含Using filesort或Using temporary说明排序/分组没走索引，需调整
针对性优化SQL写法
很多慢查询源于习惯性写法，改几处就能见效：
- 删掉SELECT *，只取业务需要的字段，减少I/O和网络传输
- WHERE条件中避免对索引列用函数，比如把WHERE YEAR(create_time) = 2023改成WHERE create_time >= '2023-01-01' AND create_time
- 多表JOIN时，用INNER JOIN替代LEFT JOIN（除非业务明确要保留左表空记录）
- 子查询尽量转成JOIN或CTE，尤其避免在主查询每行都触发一次的DEPENDENT子查询
科学设计索引
索引不是越多越好，而是要匹配真实查询模式：
- WHERE、JOIN、ORDER BY、GROUP BY中高频出现的字段优先建索引
- 多条件查询优先考虑复合索引，顺序按“区分度高→常用于过滤→用于排序”排列，例如(status, city, create_time)
- 覆盖索引能避免回表：若查询只需user_id, status, amount，就建INDEX idx_cover (user_id, status, amount)，EXTRA会显示Using index
- 定期清理冗余索引，避免写操作变慢
