优化 MySQL 复杂查询的核心在于减少数据扫描量、提升索引利用率、合理组织 SQL 结构。以下从常见问题出发，给出具体可操作的优化策略。
1. 合理使用索引避免全表扫描
复杂查询往往涉及多表连接或多个 WHERE 条件，如果没有合适的索引，性能会急剧下降。
建议：
为 WHERE、JOIN、ORDER BY 和 GROUP BY 中频繁使用的字段建立复合索引，注意字段顺序。 避免在索引列上使用函数或表达式，如 WHERE YEAR(create_time) = 2023，应改为 create_time BETWEEN '2023-01-01' AND '2023-12-31'。 使用 EXPLAIN 查看执行计划，确认是否走索引，重点关注 type（最好为 ref 或 range）、key（实际使用的索引）、rows（扫描行数）。2. 优化 JOIN 和子查询结构
多表关联时，不合理的 JOIN 顺序或嵌套子查询容易导致中间结果集过大。
建议：
尽量用 INNER JOIN 替代 IN 或 EXISTS 子查询，尤其是子查询返回大量数据时。 将大表放在最后 JOIN，让小结果集先过滤出来。 对子查询结果做物化（临时表），可考虑将其拆解为临时表并加索引，再参与后续查询。 避免 SELECT *，只取需要的字段，减少数据传输和内存占用。3. 分解复杂查询，分步处理
一个超长 SQL 包含多个聚合、嵌套、排序逻辑，MySQL 难以生成最优执行计划。
建议：
将大查询拆成多个简单查询，在应用层或存储过程中组合结果。 使用临时表缓存中间结果，尤其适合多次复用的子集数据。 对 GROUP BY 和 ORDER BY 字段确保有索引，且不要跨多个大表排序。4. 调整配置与统计信息
即使 SQL 写得好，数据库配置不合理也会影响优化器判断。
建议：
定期执行 ANALYZE TABLE 更新表统计信息，帮助优化器选择更优执行路径。 适当调大 sort_buffer_size、join_buffer_size，但不要过度设置。 开启慢查询日志（slow_query_log），定位执行时间长的语句。基本上就这些。关键不是写得多高级，而是清楚每一步在做什么，数据怎么流动，有没有多余的扫描或排序。用 EXPLAIN 多验证，结合业务场景调整，效果最实在。
