这事儿我得从一次面试聊起。去年有个朋友去大厂面试，技术面到第三轮，面试官突然问：“你觉得数据库优化最核心的是什么？”我那朋友张口就说索引、缓存、分库分表，一套组合拳打得挺溜。面试官听完笑了笑，又追问：“那你说说，如果一张表只有 50 万条数据，查询却慢得像蜗牛，你第一步会干什么？”这问题一下把他问住了。其实数据库优化这事儿，跟装修房子一个道理，很多人一上来就想着砸承重墙、换全屋水电，结果发现根本问题可能就是门锁坏了。面试官真正想看的，不是你背了多少优化方案，而是你有没有诊断问题的能力。
说到诊断，咱得先聊聊那些最容易忽视的“小毛病”。很多程序员面试时，张口就是“加索引”，但索引怎么加、加在哪，却一问三不知。我见过最离谱的案例，有人把一张表的每个字段都建了索引，结果查询反而更慢了。为啥？因为索引本身也要维护，每次插入、更新、删除数据时，索引都得跟着动。就像给一本书做了 20 级目录，翻起来反而更累。真正好的索引设计，得先搞清楚查询模式。比如用户登录场景，90% 的查询都是根据手机号或邮箱来找用户，那就给这两个字段建联合索引。要是还有状态查询，比如“查所有活跃用户”，就要考虑覆盖索引，让索引本身就能返回所有需要的数据，避免回表查询。面试官听到这儿，起码知道你是个会动脑子的人，而不是只会背书的。
但索引只是开胃菜，真正拉开差距的是对执行计划的理解。我有个徒弟，工作三年了，每次遇到慢查询第一反应就是“是不是索引失效了”。后来我让他用 EXPLAIN 命令把执行计划打出来看看，才发现问题根本不在索引上。比如有一次，一张订单表查某天的数据，明明有日期索引，执行计划却显示全表扫描。仔细一看，原来他把日期字段存成了字符串，查询时又用了 BETWEEN 这种范围条件。MySQL 认为字符串索引不划算，干脆全表扫了。这种坑，不跑执行计划很难发现。面试时如果你能主动说“我会先用 EXPLAIN 分析 SQL 执行计划，看 type 字段是不是 ALL 或 index，看 rows 字段估算扫描行数”，面试官就会知道你不是只会写 CRUD 的。
再往深里聊，就得说索引失效的几种常见场景。比如隐式类型转换：字段是 VARCHAR，传参却是数字，MySQL 会偷偷把所有数据转成数字再比较，索引自然失效。还有最左前缀原则，联合索引 (a,b,c) 若查询条件只带了 b 和 c，索引也用不上。再比如 LIKE 查询，前缀模糊匹配 “%xxx” 会导致索引失效，但后缀模糊 “xxx%” 则不会。这些细节，面试时随口说两三个，面试官就会觉得你平时干活肯定踩过坑。我见过最狠的面试者，直接掏出手机相册，翻出之前解决的慢查询截图，完整讲解执行计划、索引设计、优化前后的对比。这种实战经验，比任何理论都管用。
聊完索引，咱们再说说 SQL 本身。很多人优化数据库，第一反应是改架构、加缓存，却忽略了 SQL 语句本身可能就有问题。比如分页查询，用 LIMIT OFFSET 分页时，OFFSET 越大越慢。为啥？因为 MySQL 必须先扫描 offset+limit 行，再扔掉前面的。优化方案其实很简单：用 “WHERE id > 上次最大 id LIMIT 10” 这种游标分页，或者先用子查询拿到主键 ID 再关联原表。再比如，避免 SELECT *，只查需要的字段，减少数据传输量。还有一个容易被忽略的点——排序。ORDER BY 如果没走索引，MySQL 会生成临时文件排序，数据量大时会非常慢。这些优化点单看都不显眼，但组合起来效果惊人。我曾把一个后台报表查询的分页改成游标式、去掉多余字段，查询时间从 8 秒降到 0.3 秒。
但光优化 SQL 还不够，真正的高手会从数据模型层面思考。比如反范式设计，有时为了查询性能会刻意冗余一些字段。电商系统里，订单详情页经常要展示商品名称、价格、图片，如果这些信息都存到商品表，查询时就要多一次关联。把商品名称、价格冗余到订单明细表里，查询时一张表搞定，省去一次 JOIN。代价是更新商品信息时要同步所有相关订单，但商品信息改动不频繁，而订单查询频率极高。这种 “以空间换时间” 的思路，面试时能讲出来，说明你懂业务和架构的权衡。另一个例子是分区表，比如日志表按日期分区，查询某个月的数据时，MySQL 只扫对应分区，速度飞快。但这些方案都有代价，面试官更想看你能否权衡利弊。
说到权衡，就不得不提缓存和读写分离。很多系统一遇到性能问题就想上 Redis，但缓存不是万能药。比如用户登录会话，缓存命中率极高，适合用 Redis；但库存扣减这种场景，用缓存可能导致数据不一致，反而更麻烦。我见过一个血泪案例，某电商大促时，库存用 Redis 扣减，结果缓存雪崩导致大量订单超卖，赔了几百万。面试时如果你能说“缓存的使用要结合业务场景，强一致性场景慎用”，面试官会对你另眼相看。读写分离也是如此，主从同步有延迟，如果业务要求“写完马上能读到”，读写分离就会成为坑。比如用户刚注册完，立马跳转到个人中心，结果从库还没同步，显示“用户不存在”，体验极差。
我想说个面试中很少被提及但很重要的点——慢查询日志和监控。很多程序员直到线上出问题才去看慢查询，平时根本不管。真正优秀的工程师会主动开启慢查询日志，设置阈值比如 1 秒，然后定期分析。我认识一位阿里 P8 大佬，他每两周会跑一次慢查询报告，把 top10 的 SQL 拿出来分析，该优化的优化，该加索引的加索引。他说：“数据库优化不是一次性的事，而是持续迭代的过程。”面试时如果你能说“我会用 Performance Schema 或 sys 库分析数据库性能瓶颈”，面试官就会觉得你不是只会写代码的工具人。毕竟，数据库优化的本质是对系统性能的持续关注和主动干预，而不是等到出事才去救火。
