这些MySQL优化面试题我答了100遍（高频考点整理）

一、索引优化的灵魂三问（必考）

1. 索引失效的六大经典场景

• 字段类型不一致：比如给字符串字段用数字查询（name=123）
• 索引列参与运算：where id+1=100（改成id=99才能命中）
• 前导通配符搜索：like ‘%张%’（改成’张%'还能抢救）
• 使用or连接非索引字段：where age=18 or address=‘北京’
• 联合索引不遵守最左前缀：建了(a,b,c)索引却只查b和c
• 数据量小直接全表扫描（MySQL觉得用索引更慢）

2. 覆盖索引到底怎么用？

举个真实案例：用户表有500w数据，要查18岁用户的姓名。如果只有age索引，需要回表查500次；如果有(age,name)联合索引，直接索引里取数据，查询速度提升20倍！

-- 错误示例（需要回表）
SELECT name FROM users WHERE age = 18;

-- 优化方案（覆盖索引）
ALTER TABLE users ADD INDEX idx_age_name(age, name);

3. 大分页查询怎么优化？

传统写法性能灾难：

SELECT * FROM orders LIMIT 1000000,10;

优化方案三步走：

1. 延迟关联：先查ID再关联
2. 范围分页：where id > 上一页最大ID
3. 业务妥协：限制最大页码（比如只允许查前100页）

二、慢查询分析实战套路

1. Explain的隐藏考点

面试官最爱问的执行计划字段：

• type列：ALL（全表扫描）→ index → range → ref → const
• Extra列：Using filesort（要优化） / Using index（好现象）
• key_len计算：判断复合索引使用情况

2. 慢日志分析的三个维度

# 查看慢查询配置
SHOW VARIABLES LIKE 'slow_query%';

# 典型分析流程
1. 抓取top10慢SQL
2. 检查是否走索引
3. 分析扫描行数
4. 查看锁等待时间
5. 评估执行频率

三、分库分表必杀技

1. 拆分策略对比

方案	优点	缺点
范围分片	扩展简单	容易产生热点数据
哈希分片	数据分布均匀	扩容麻烦
业务键分片	符合业务场景	需要深入理解业务逻辑

2. 分页查询的终极方案

• 全局视野法：每个分片取前N页，内存排序（适合小数据量）
• 二次查询法：先查大致范围再精确查询（需要业务妥协）
• 游标分页：类似抖音无限滚动（where id > ? limit 10）

四、锁机制避坑指南

1. 死锁经典场景复现

事务A：

UPDATE account SET balance=100 WHERE id=1;
UPDATE account SET balance=200 WHERE id=2;

事务B：

UPDATE account SET balance=300 WHERE id=2;
UPDATE account SET balance=400 WHERE id=1;

（两个事务互相等待对方释放锁）

2. 间隙锁的防坑要点

• 在RR隔离级别下才会出现
• 影响范围包括记录之间的间隙
• 用SELECT ... FOR UPDATE NOWAIT可快速失败

五、高频灵魂拷问集锦

1. count(*)和count(1)哪个快？
   实测没区别！优化器会自己选最优方案

2. varchar(255)有什么讲究？
   MySQL5.0之前最大65535字节，现在可以到65535字符（utf8mb4下要小心）

3. 为什么不要用外键？
   互联网场景下影响写入性能，推荐业务层保证一致性

4. 大字段存储方案
   超过10kb的文本建议拆分成单独表（比如content表）

5. 如何安全删除千万级数据
   小批量删除：DELETE FROM logs WHERE id < 100000 LIMIT 1000
   凌晨低峰期执行，记得暂停主从同步

六、调优工具箱

1. 必须掌握的诊断命令

SHOW PROCESSLIST;  -- 查看当前连接
SHOW ENGINE INNODB STATUS;  -- 锁信息
SHOW PROFILE;  -- 执行耗时分析

2. 参数调优三件套

# my.cnf配置
innodb_buffer_pool_size = 机器内存的70%
max_connections = 500  # 根据实际情况调整
slow_query_log = 1  # 开启慢查询日志

最后划重点

面试时遇到优化问题，记住这个万能公式：
定位问题 → 分析原因 → 制定方案 → 验证效果 → 监控反馈

最后送大家一个血泪教训：永远不要在业务高峰期执行ALTER TABLE！（曾经因为这个搞崩过生产环境的人含泪提醒）