索引不是“加速开关”，而是为特定查询路径预建的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写错了。
