最近帮几个朋友看 Java 面试，发现一个有意思的现象：很多人张口闭口都是微服务、分布式、高并发，结果一聊到数据库优化，立马就蔫了。面试官问“慢查询怎么排查”，有人能扯到缓存、读写分离，但说不清楚索引怎么建。这事挺要命的。数据库优化是 Java 面试里的硬通货，不是加分项，而是基础分。你算法写得再花哨，数据库这关过不去，面试官心里就会打问号——这人到底有没有实战经验？
先聊聊索引。面试官最爱问索引的类型和适用场景，但很多人只会背“B+ 树、哈希索引”这些名词。你要真在项目里调过优，就知道索引不是越多越好。比如一个订单表每天新增几十万条数据，如果给每个字段都建索引，插入性能会直接崩掉。实战中，索引设计要看查询频率和区分度。像性别这种字段，区分度太低，建了索引跟没建一样，还不如不要。面试时可以这么说：我排查慢查询时，先看 EXPLAIN 的执行计划，重点关注 type 列，如果是 ALL（全表扫描），就考虑加索引。加了之后要用 SHOW INDEX 验证，还得测一下 INSERT 性能，避免顾此失彼。
再说说 SQL 写法。很多程序员写 SQL 跟写散文似的，怎么顺手怎么来，完全不考虑数据库怎么执行。比如 SELECT 这种写法，一拿出来就会被扣分。原因很简单：查询的字段越多，数据库需要扫描的数据量就越大，IO 开销也越高。更关键的是，如果表结构变了，SELECT 会把不需要的字段也拉出来，代码里可能就出 bug。面试官问这个，其实是在考察你有没有性能敏感度。真正有经验的，写 SQL 时一定会把字段列出来，该用 LIMIT 控制返回行数就用 LIMIT，该用 JOIN 替代子查询就用 JOIN。把这些细节说清楚，面试官就会知道你是有坑踩过的。
还有一点容易被忽略：事务和锁。Java 面试里，数据库优化不只是索引和 SQL，还涉及并发控制。比如电商系统的库存扣减，如果不用乐观锁或悲观锁，高并发下数据就会乱套。但很多人在面试时只会背“乐观锁用版本号，悲观锁用 FOR UPDATE”，真问起来就露怯。你需要讲出场景：比如秒杀时，用悲观锁容易死锁，用乐观锁又可能失败率高，这时候可以结合 Redis 缓存库存，或者利用数据库 UPDATE 语句自带的行锁特性。面试官听到这些，会觉得你真的在项目里解决过问题，而不是背八股文。
再说说分库分表。这话题现在很热，面试官十有八九会问。但很多人一上来就讲分片策略、中间件选型，听起来很专业，却忽略了一个前提：你的数据量到底多大？我见过一个项目，表里才 10 万条数据，就嚷嚷着要分库分表，结果性能没提升，运维复杂度却翻了好几倍。面试时要表现出判断力：先问数据量级，再决定要不要分。如果确实需要分，可以讲具体方案——比如按用户 ID 取模分片，或者按时间分表。还要考虑跨分片查询怎么办，比如用全局表、ES 或者汇总查询。这些细节才是面试官想听的。
缓存策略也是绕不开的。Java 面试里，很多人会把 Redis 和数据库优化混为一谈，但面试官问的是“数据库优化”，不是“缓存优化”。你得讲清楚两者的界限。比如热点数据可以放 Redis，但缓存和数据库的一致性怎么保证？写操作是先更新数据库还是先删缓存？这涉及到双写一致性，经典问题是“删除缓存失败怎么办”。有经验的会说：用 binlog 订阅同步，或者用消息队列保证最终一致性。但别把缓存当万能药——数据实时性要求高的场景，缓存反而添乱。面试官听到你这种权衡，会觉得你思路清晰。
还有一个容易被忽略的点：数据库配置。很多 Java 程序员只关注代码层面，对数据库的配置参数一问三不知。但面试官偶尔会问：你的 InnoDB buffer pool 大小设了多少？binlog 格式是 ROW 还是 STATEMENT？这些参数直接影响性能。比如 buffer pool 太小，数据频繁换页，查询就慢；binlog 用 STATEMENT 格式，某些更新场景下会出现主从不一致。你不需要背所有参数，但至少要知道几个关键配置的作用。面试时可以说：我会根据服务器内存大小把 buffer pool 调整到总内存的 70%‑80%，binlog 用 ROW 格式保证数据一致性。这种细节一说出来，面试官就知道你不是只会写 CRUD。
聊聊慢查询日志的实战。面试官问“你怎么定位慢查询”，很多人就回答“开慢查询日志，分析 SQL”。这个答案太笼统，等于没答。你要给出具体的操作步骤：先把 longquerytime 设为 1 秒，跑一段时间后获取慢查询日志文件，用 pt‑query‑digest 分析，找出执行频率高、耗时长的 SQL。接下来不是直接改，而是用 EXPLAIN 看执行计划，判断是全表扫描还是索引没用上。如果是索引问题，就加索引；如果是 SQL 写法问题，就重写。但有个坑：改完后要测试，不能只看 EXPLAIN 的结果，因为 EXPLAIN 只是估算，实际执行可能有偏差。把这些步骤讲清楚，面试官就会知道你真的干过这活。
话说回来，数据库优化这件事，面试官看重的不是你会多少工具，而是你有没有解决问题的思路。很多人背了一堆理论，真遇到问题就懵了。比如面试官问“查询突然变慢，怎么排查”，如果你能从 SQL 执行计划、索引、锁等待、服务器资源这几个维度逐步排查，面试官就会信服。过程不需要讲得多高深，只要逻辑自洽、细节到位，面试就稳了。
别把数据库优化想得太玄乎。它就是一个“发现问题‑分析原因‑动手解决‑验证效果”的闭环。你在项目里多踩几个坑、多翻几次慢查询日志，自然就懂了。面试官也是从这一步走过来的，他能看出你有没有真做过，心里门儿清。所以下次面试前，别只顾着刷 LeetCode，把数据库优化这块好好捋一捋，这比背 100 道算法题都管用。
