索引不是越多越好，它是以额外存储和写入成本换取读取效率的数据结构。有效的索引必须服务于真实访问模式，并通过执行计划和运行指标验证，而不是仅凭字段是否经常出现在 WHERE 中判断。

核心原则

  • 从慢查询日志和高频接口识别优化目标，先处理影响最大的语句。
  • 联合索引字段顺序结合等值过滤、范围条件、排序和选择性综合设计。
  • 使用 EXPLAIN ANALYZE 对比估算行数与实际行数，检查扫描、回表和排序。
  • 避免对索引列执行函数或隐式类型转换，确保条件可以利用索引。
  • 删除长期未使用或高度重叠的索引，降低写放大和缓存压力。

推荐的实践步骤

例如订单列表按 user_id 等值过滤、created_at 范围筛选并按时间倒序，可以评估 (user_id, created_at) 联合索引。上线前在接近生产数据量的环境对比执行计划和耗时，上线后观察扫描行数、缓冲池命中与写入延迟，确认优化没有把成本转移到其他路径。

EXPLAIN ANALYZE
SELECT id, total_amount, created_at
FROM orders
WHERE user_id = 1024
  AND created_at >= '2026-01-01'
ORDER BY created_at DESC
LIMIT 50;

CREATE INDEX idx_orders_user_created
ON orders(user_id, created_at);

示例用于说明实现思路，实际项目还应结合所使用的框架版本、部署环境和业务约束进行调整。重要配置要进入版本管理，并在测试环境验证后再发布。

常见误区

  • 为每个单列都创建索引，不等于能够满足组合查询和排序。
  • 使用 SELECT * 会增加回表与网络传输，也妨碍覆盖索引。
  • 只在小测试表上看毫秒耗时，无法反映生产数据分布和缓存状态。

上线前检查清单

  • 确认“从慢查询日志和高频接口识别优化目标，先处理影响最大的语句”已经通过代码审查或运行验证。
  • 确认“联合索引字段顺序结合等值过滤、范围条件、排序和选择性综合设计”已经通过代码审查或运行验证。
  • 确认“使用 EXPLAIN ANALYZE 对比估算行数与实际行数，检查扫描、回表和排序”已经通过代码审查或运行验证。
  • 确认“避免对索引列执行函数或隐式类型转换，确保条件可以利用索引”已经通过代码审查或运行验证。
  • 为失败路径、边界条件和回滚方案准备测试或演练记录。
  • 上线后观察错误率、延迟和资源消耗，确认变化符合预期。

总结

MySQL 索引设计与查询优化实战的关键在于把隐含假设变成可执行的约束，并通过测试、监控和复盘持续验证。先从影响最大的真实场景开始，小步调整并保留回滚能力，通常比一次性大范围改造更安全，也更容易积累可复用的工程经验。