索引是为特定查询预建的B+树导航图，核心作用是避免全表扫描；其生效依赖查询模式匹配，复合索引遵循最左前缀原则，写多读少或低选择性字段建索引反而拖慢性能，验证需结合key_len、Extra及ANALYZE TABLE更新统计信息。
索引不是“加速开关”，而是为特定查询路径预建的B+树导航图
MySQL用索引，根本原因不是“让查询变快”，而是避免全表扫描——当表有100万行，WHERE email = 'x@y.com' 若无索引，引擎就得逐行比对百万次；而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%。更隐蔽的问题是：
- 低选择性字段（如
gender只有'm'/'f'两个值）建索引，优化器可能直接放弃使用，还白占空间 - 短字符串列（如
VARCHAR(255)存邮箱）未指定前缀长度，索引体积暴增，缓存命中率暴跌 - MySQL 8.0已移除查询缓存（
query_cache_type），别再指望靠索引“激活”缓存来提速
怎么验证索引真正在工作？别只看EXPLAIN，盯住key_len和Extra
EXPLAIN输出里，光看type=ref不够，得细查两个字段：
-
key_len：显示实际用了索引的字节数。比如INDEX idx_name (name(10), age)，若name是utf8mb4，10字符最多占40字节，age是TINYINT占1字节，则key_len=41才说明两个字段都用上了；若只有key_len=40，说明age没参与过滤 -
Extra：出现Using index表示覆盖索引（不用回表），Using filesort或Using temporary则暴露排序/分组没走索引，得补或调序
真正容易被忽略的是：索引是否被统计信息“误判”。执行ANALYZE TABLE user_profiles强制更新统计后，有时执行计划会立刻切换到更优索引——因为优化器依赖的行数估算不准，不是SQL写错了。
