索引是为特定查询预建的B+树导航图，核心作用是避免全表扫描；其生效依赖查询模式匹配，复合索引遵循最左前缀原则，写多读少或低选择性字段建索引反而拖慢性能，验证需结合key_len、Extra及ANALYZE TABLE更新统计信息。
索引不是“加速开关”，而是为特定查询路径预建的B+树导航图
MySQL用索引，根本原因不是“让查询变快”，而是避免全表扫描——当表有100万行，WHERE email = '[email protected]' 若无索引，引擎就得逐行比对百万次；而B+树索引能把这个过程压到3~4次磁盘IO（约O(log n)）。关键在于：索引只对它“认识”的查询模式生效。比如LIKE '%abc'无法走B+树范围查找，WHERE status + 1 = 2会让字段失效，这些都不是索引“不给力”，而是查询写法绕过了索引结构本身。
复合索引怎么排字段顺序？看WHERE条件的匹配逻辑链
复合索引INDEX idx_user (city, age, status) 不是三个字段简单堆砌，而是按“最左前缀”逐级收敛：先筛city，再在同city里筛age，最后在同city+age里筛status。这意味着：
-
WHERE city = 'Beijing' AND age > 25能用上前两列，但status因范围查询中断无法继续下推 -
WHERE age = 30 AND status = 'active'完全用不上这个索引——没出现city，最左前缀断了 -
WHERE city = 'Shanghai' AND status = 'inactive'只能利用city，status被跳过（中间缺了age）
所以排序原则很实际：高频等值查询字段放最左，范围查询（>, BETWEEN）字段放中间，ORDER BY或GROUP BY字段放最后（如果需要覆盖排序）。
为什么加了索引反而更慢？写多读少时索引是负债
索引不是免费午餐。每次INSERT、UPDATE、DELETE，InnoDB都要同步更新所有相关索引页——一个表有5个索引，写一行就可能触发5次随机磁盘写。实测中，当单表日均写入超5万条且查询QPS低于200时，新增索引常导致TPS下降15%~30%。更隐蔽的问题是：
