数据库查询优化是后端开发中永恒的话题。随着数据量的增长，原本在测试环境中表现良好的 SQL 可能在生产环境中成为性能瓶颈。本文系统性地梳理 MySQL 查询优化的核心方法论和实践经验。

1. 索引设计原则

索引是数据库优化的第一道防线。好的索引设计能让查询性能有数量级的提升。在实践中，我遵循以下几个核心原则：

  • 最左前缀原则——复合索引中，查询条件必须从索引的最左列开始匹配。设计复合索引时，将等值查询的列放在前面，范围查询的列放在后面。
  • 覆盖索引——如果查询的所有列都在索引中，MySQL 可以直接从索引返回结果，无需回表查询。这是性能最高的查询方式。
  • 避免在大字段上建索引——BLOB、TEXT 类型的字段不适合普通索引，应使用前缀索引或全文索引替代。
  • 索引下推（ICP）——MySQL 5.6+ 支持索引条件下推，尽量利用这一特性减少回表次数。

2. 执行计划分析

EXPLAIN 是分析 SQL 性能的利器。在解读执行计划时，我重点关注以下几个信号：

  • type 字段——从优到劣依次为：const > eq_ref > ref > range > index > ALL。如果看到 ALL（全表扫描），通常意味着需要添加索引。
  • Extra 字段——Using filesort 和 Using temporary 是性能警示信号，分别表示需要额外的排序和临时表操作。
  • rows 字段——估算的扫描行数。实际行数与估算行数差异过大时，说明统计信息可能已过期，需要执行 ANALYZE TABLE。

3. 常见 SQL 反模式

  • SELECT *——取回不需要的列，增加网络传输和内存开销，且无法利用覆盖索引。
  • 隐式类型转换——WHERE varchar_col = 123 会导致索引失效。务必保持比较操作两侧的类型一致。
  • 在 WHERE 中对列做函数操作——WHERE DATE(created_at) = '2026-01-01' 无法使用索引，应改写为范围查询。
  • 大偏移量的 LIMIT——LIMIT 1000000, 20 需要扫描并丢弃前 100 万行。改用基于游标的分页或使用延迟关联优化。

4. 分库分表实践

当单表数据量超过千万级时，即使索引优化到位，写入和 DDL 操作也会成为瓶颈。分库分表是绕不开的选择。我们的经验是：优先考虑垂直拆分（按业务模块），其次考虑水平拆分（按某个分片键将数据均匀分布到多个分表）。分片键的选择至关重要——它应该使查询尽量落在单个分片上，避免跨分片查询带来的性能开销。

总结

数据库优化没有银弹，需要结合具体的业务场景和数据特征来制定策略。但万变不离其宗——理解索引的工作原理、善于使用执行计划分析工具、养成良好的 SQL 编写习惯，这三者构成了应对绝大多数性能问题的基本能力。