掌握这5个高频考点，让面试官眼前一亮！

1. 索引失效的7大死亡陷阱

这是面试官最爱深挖的考点，每个陷阱都配有真实案例：

• 隐式类型转换：phone字段是varchar，查询时用数字13800138000导致全表扫描
• 函数操作：WHERE YEAR(createtime)=2023会让索引失效，应改为范围查询
• LIKE前模糊：LIKE '%张三'直接判死刑，只能用LIKE '张三%'
• OR条件未全覆盖：WHERE a=1 OR b=2需要a、b都有独立索引
• 最左前缀违背：联合索引(a,b,c)只查b和c → 索引失效
• 数据倾斜：性别字段建索引（男女各占50%）效果极差
• 统计信息过期：ANALYZE TABLE多久没跑了？

2. 联合索引的最左前缀原则

用快递柜取件码举例：索引(province,city,street)就像取件码"01-02-03"

SQL示例

-- 正确用法（能用到完整索引）
WHERE province='浙江' AND city='杭州' AND street='文三路'

-- 部分有效（只用前两个字段）
WHERE province='浙江' AND city='杭州'

-- 完全失效（违背最左前缀）
WHERE city='杭州' AND street='文三路'

黄金法则：范围查询后的索引列全部失效！

3. 深分页优化方案

当面试官问"100万数据怎么查第99999页"时的标准回答：

方案	SQL示例	性能提升
延迟关联	JOIN子查询先查ID	50倍
书签记录	WHERE id > 上页最大ID	100倍
游标分页	基于有序字段分页	稳定高效

4. EXPLAIN执行计划解读

记住这三个关键指标让面试官刮目相看：

• type列：至少达到range级别，const最优
• rows列：估算扫描行数，越小越好
• Extra列：出现Using filesort立即优化排序

实战案例

-- 优化前（type=ALL，rows=100万）
EXPLAIN SELECT * FROM orders WHERE status=1;

-- 优化后（type=ref，rows=100）
EXPLAIN SELECT id FROM orders WHERE status=1;

5. 索引设计的隐藏代价

这是区分高手和新人的终极考点：

真实案例

某电商平台删除冗余索引后，写性能提升300%！

• 写操作成本：每次INSERT/UPDATE都要维护索引
• 空间占用：1GB的表，索引可能占2GB
• 优化器误判：统计信息不及时会选错索引

面试应答模板

万能公式：

1. 先看执行计划（EXPLAIN）
2. 分析扫描行数（rows）和索引类型（type）
3. 检查是否走覆盖索引（Extra列）
4. 查看排序方式（Using filesort警告）
5. 最后提出优化方案