​​​​​​一、先建立直觉没有合适索引时数据库常常要把候选行一张张翻过去全表/大范围扫描。 有了合适索引更像先查目录再翻到那一页。【一句话】 索引不是魔法加速器而是用额外结构换「更少的数据触摸次数」。二、索引主要优化什么收益说明减少扫描量从「看很多行」变成「看很少行」支持排序/分组某些 ORDER BY / GROUP BY 可少一次文件排序加速关联JOIN 条件上的索引往往决定计划质量代价同样真实占用存储拖慢 INSERT/UPDATE/DELETE要维护索引过多索引会让优化器更「犹豫」所以索引是权衡不是越多越好。三、哪些条件更容易用上索引以常见 BTree 二级索引心智为例不同引擎细节有别但直觉通用更友好等值查询WHERE user_id ?左最长前缀匹配的联合索引范围查询在前缀列之后要小心组合方式容易失效或变差对索引列做函数/隐式类型转换WHERE DATE(created_at)...前导模糊LIKE %keyword选择性极低的列单独建索引如性别取回大量行再回表优化器可能直接选扫描【避坑】 「列上有索引」≠「这条 SQL 会走索引」。要用执行计划说话。四、联合索引顺序就是生产力假设常查WHERE app_id? AND status? AND created_at?一个常见设计是联合索引(app_id, status, created_at)原则记忆区分度高、常等值的列更靠前结合真实查询范围条件列通常放在等值列之后不要为每一种排列都建一套优先覆盖主路径【结论】 联合索引的顺序应按查询模式设计而不是按表字段顺序瞎排。五、上线前清单【清单】先用慢查询日志找到 Top SQL而不是凭感觉加索引看执行计划类型、扫描行数、是否回表、是否临时表/文件排序确认写入量高频写表慎加大量索引能合并的联合索引不要拆成一堆单列索引上线后观察QPS、写延迟、磁盘与缓冲池命中写在最后索引解决的是「找得慢」不是「算得笨」或「架构不合理」。 数据模型糟糕、一次查出十万行到应用再过滤加十个索引也救不了。【一句话带走】 先问查询要触达多少数据再决定目录该怎么建。你最近一次慢 SQL是没索引、索引建错还是回表太多欢迎留言。