优化慢查询是提升数据库性能最直接、性价比最高的手段，通过开启慢查询日志、用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，重点看三列：

BGM猫

BGM猫是一款AI音频处理工具，灵动音科技推出的AI智能生成BGM音乐。

下载

• 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
• 定期清理冗余索引，避免写操作变慢