索引优化不是新手优先学习内容，需先掌握查询执行过程、数据分布和存储引擎行为；盲目建索引会导致写入变慢、磁盘暴涨、执行计划误选。
索引优化不是新手该优先学的内容，它需要先理解查询执行过程、数据分布特征和存储引擎行为。盲目建索引反而会让写入变慢、磁盘暴涨，甚至让优化器选错执行计划。
为什么新手直接学索引优化容易翻车
常见错误现象：EXPLAIN 看不懂 type=ALL 和 key=NULL 的实际影响；建了 idx_user_id_status 却发现 WHERE status = 'active' 根本不走索引；用 LIKE '%abc' 还指望索引生效。
- 没掌握 B+ 树结构前，无法理解最左前缀原则为何限制
WHERE条件顺序 - 不了解
cardinality和数据倾斜，就看不出为什么对性别字段建索引几乎无效 - 没看过
slow_query_log，就不知道哪些查询真正需要优化，容易对着测试数据“优化”出假结论
新手该先扎实掌握的 3 个基础点
这些是索引优化的前提，跳过它们等于在流沙上盖楼：
-
EXPLAIN输出中必须看懂的 4 列：type（访问类型）、key（实际用的索引）、rows（扫描行数估算）、Extra（比如Using filesort或Using temporary） - 区分
PRIMARY KEY、UNIQUE和普通INDEX的物理存储差异——InnoDB 下前者是聚簇索引，后者是非聚簇，直接影响回表成本 - 写出能命中索引的
WHERE条件：避免在索引列上做函数操作（如WHERE YEAR(create_time) = 2023），避免隐式类型转换（如WHERE user_id = '123'而user_id是INT）
什么情况下才该动手调索引
不是所有慢查询都靠加索引解决。先确认这几点再动 ALTER TABLE ... ADD INDEX：
- 该查询是否真的高频？低频但慢的查询，可能加个
LIMIT或前端加缓存更划算 - 表数据量是否超过 10 万行？小表全表扫描可能比索引查找更快（尤其 SSD 随机 IO 成本下降）
- 写入压力大吗？每个新增索引都会拖慢
INSERT/UPDATE/DELETE，且占用额外磁盘空间（二级索引也存主键值） - 是否已用
pt-query-digest或performance_schema定位到真实瓶颈？别只凭SELECT语句长得像就开干
索引优化真正的复杂点不在语法，而在权衡：读性能 vs 写性能、内存占用 vs 磁盘空间、单条查询提速 vs 整体 QPS 下降。很多线上事故，都是没看清这个 trade-off 就执行了 CREATE INDEX。
