索引设计从真实查询开始

不要根据表字段猜索引。先收集慢查询、调用频率、返回行数和排序方式，再围绕最重要的查询建立索引。一个低频后台查询不应该牺牲高频写入性能去换取极致速度。

联合索引的列顺序

通常先放等值过滤列，再放范围或排序列。选择性不是唯一标准，还要考虑查询是否能使用连续的索引前缀。范围条件之后的列通常无法继续用于缩小扫描范围，但可能用于覆盖查询。

SELECT article_id, title, publish_time FROM article WHERE status = "0" AND publish_status = "published" ORDER BY publish_time DESC LIMIT 20;

对这类查询，索引可以设计为 status、publish_status、publish_time、article_id。最后补 article_id 能让排序稳定，也方便改造成游标分页。

覆盖索引与回表

列表查询只返回少数字段时，可以将必要字段放入索引，减少回表。但标题等较长字段会显著增大索引体积，需要结合数据量和缓冲池命中率判断，不能为了覆盖而无限扩展索引。

  • 使用 EXPLAIN ANALYZE 查看实际扫描行数和耗时。
  • 避免在索引列上包裹函数或发生隐式类型转换。
  • 深分页改用基于时间与主键的游标分页。
  • 定期清理重复、长期未使用的索引。

关注整体成本

索引会增加写放大、磁盘占用和 Buffer Pool 压力。优化完成后不仅要看单条查询，还要观察写入耗时、锁等待、缓冲池命中率与磁盘 I/O，确认没有把成本转移到其他路径。