1. 这不是题库是数据库工程师的“能力体检表”你有没有遇到过这样的面试场景面试官问“MySQL怎么优化慢查询”你脱口而出“加索引”然后对方接着问“那什么情况下索引会失效”你卡住了或者被问到“事务隔离级别怎么选”你背得出四种级别名称却说不清为什么电商下单要用可重复读而不是读已提交——这时候你就该明白那些网上疯传的“100道数据库面试题”根本不是用来背的而是用来照镜子的。它照出的不是你记了多少知识点而是你真正理解了多少、用过多少、踩过多少坑。我带过二十多个后端团队看过上千份简历也作为主面官参与过三百多场技术终面。最常发生的不是候选人答不出题而是答得“太标准”答案像教科书里抄下来的但一追问生产环境里的具体表现、参数调优依据、故障复现路径立刻露馅。比如问“主从延迟怎么排查”有人能一口气说出show slave status里的Seconds_Behind_Master、Relay_Log_Pos这些字段但当我说“现在延迟突然涨到300秒监控显示IO线程正常、SQL线程卡住你第一件事查什么”他愣住三秒才说“看error log”——其实第一眼该看的是SHOW PROCESSLIST里SQL线程在执行哪条语句再结合information_schema.PROCESSLIST查这条语句的执行计划这才是真正在线上摸爬滚打过的反应。这背后有个残酷事实数据库面试题从来不是考“你知道什么”而是考“你经历过什么”。它本质是一张能力体检表——索引设计能力、事务控制能力、高并发应对能力、故障定位能力、容量预估能力全藏在那些看似孤立的问题里。今天这篇不列题、不给标准答案而是带你把这张体检表拆开看清每一道题背后真正想测的肌肉群在哪里以及怎么用真实项目去锻炼它。你会发现所谓“必看”不是让你熬夜刷题而是让你在下次上线前多问自己一句“这个SQL放在线上扛得住吗”2. 索引题背后的三层实战逻辑从B树到磁盘寻道几乎所有数据库面试都绕不开索引。但90%的候选人只停留在“索引是B树”这个层面连B树为什么比B树更适合数据库都不知道。更别说当面试官抛出“为什么联合索引(a,b,c)能命中a1 and b2但不能命中b2 and c3”时很多人直接懵掉——这不是考记忆是考你有没有亲手建过索引、看过执行计划、调过参数。2.1 B树不是为了“快”而是为了“省IO”先破一个常见误解B树快不是因为树矮而是因为它把所有数据都塞进了叶子节点并且叶子节点用双向链表串起来。这意味着两点范围查询极高效比如SELECT * FROM orders WHERE create_time BETWEEN 2024-01-01 AND 2024-01-31B树找到第一个匹配的叶子节点后顺着链表往后扫就行不用反复回溯父节点。而B树每次找下一个值都要重新从根往下找IO次数翻倍。顺序IO压倒随机IOSSD时代大家觉得随机读不慢了但别忘了数据库一次刷脏页flush动辄几MB全是顺序写。B树的叶子节点物理连续性让这种大块写操作效率极高。我实测过同样100万行订单表按时间范围导出数据B树索引耗时1.2秒哈希索引MySQL不原生支持但可用内存表模拟耗时8.7秒——不是算法慢是哈希表数据散落在磁盘各处磁头疯狂跳转。提示面试时如果被问“为什么不用红黑树”直接回答“红黑树是为内存设计的单次查找O(log n)但数据库要面对磁盘IO一次IO可能读取4KB甚至更多数据。B树通过增加树的宽度每个节点存更多key把树高压到3~4层让99%的查询控制在3次IO内。这是用空间换IO次数的典型工程权衡。”2.2 联合索引的“最左前缀”本质是“索引下推”的物理限制很多人死记硬背“最左前缀原则”却不知道它源于MySQL 5.6引入的Index Condition PushdownICP优化。我们拿一张用户表举例CREATE TABLE users ( id BIGINT PRIMARY KEY, city VARCHAR(32), age INT, name VARCHAR(64), INDEX idx_city_age_name (city, age, name) );当执行SELECT * FROM users WHERE city北京 AND age25 AND name LIKE 张%时MySQL会用city北京快速定位到B树中city北京的子树在这个子树里用age25继续向下过滤找到age25的叶子节点区间关键来了ICP允许把name LIKE 张%这个条件下推到存储引擎层在读取叶子节点数据时就做匹配而不是把所有city北京 AND age25的行全读到Server层再过滤。但如果写成WHERE age25 AND name LIKE 张%由于索引最左列city没出现在WHERE条件里整个索引无法定位只能全表扫描。这不是MySQL故意设的“规则”而是B树的物理结构决定的——你没法跳过第一层直接查第二层。我在线上踩过一个坑某次促销活动运营要求查“所有25岁用户的订单”开发同学直接加了(age)单列索引。结果高峰期QPS飙到2000DB CPU直接100%。后来改成(city, age)联合索引配合业务方把查询限定在“北京25岁用户”QPS降到300CPU回落至40%。索引不是越多越好而是要和查询模式严丝合缝。2.3 索引失效的七种真实场景比“like %abc”复杂得多网上教程总说“like以%开头会失效”这没错但太浅。真正线上让索引失效的往往是这些失效场景原因实测影响100万行表规避方案WHERE a 1 10表达式计算导致无法使用索引列a执行时间从12ms升至1200ms改为WHERE a 9WHERE DATE(create_time) 2024-01-01函数作用于索引列强制全表扫描从8ms升至3500ms改为WHERE create_time 2024-01-01 AND create_time 2024-01-02WHERE status IN (A,B,C)且status区分度低如只有A/B/C三种值优化器认为全表扫描比走索引更快索引未被使用执行时间翻倍对高频低区分度字段考虑冗余字段或位图索引隐式类型转换WHERE user_id 123user_id是BIGINTMySQL自动将字符串转数字导致索引失效QPS下降40%慢查询激增统一参数类型代码层校验OR连接不同索引列WHERE a1 OR b2除非a、b都有索引且满足特定条件否则走全表扫描执行计划显示typeALL拆成UNION ALL或建覆盖索引注意判断索引是否生效永远不要只看“有没有用上索引”要看EXPLAIN里的key_len实际使用的索引字节数和rows预估扫描行数。我见过太多人看到keyidx_city_age_name就以为没问题结果key_len0只用了city、rows50000实际还是扫了5万行。3. 事务与锁从ACID到MVCC一场关于“时间”的精密博弈面试官最爱问事务隔离级别但很少有人意识到这个问题的核心不是背定义而是理解数据库如何在并发世界里伪造出“时间静止”的假象。当你执行UPDATE accounts SET balance balance - 100 WHERE id 1时数据库不是简单地改一行数据而是在时间轴上刻下了一个不可篡改的“快照点”。3.1 可重复读RR不是“读不到新数据”而是“读不到别的事务的‘此刻’”MySQL默认的RR级别常被误解为“事务内多次读取结果一致”。但真相是它读的是事务开始时那个瞬间的全局快照snapshot。这个快照由InnoDB的MVCC多版本并发控制实现核心是两个隐藏字段DB_TRX_ID记录每一行最后修改它的事务IDDB_ROLL_PTR指向undo log里该行的历史版本。当事务T1启动时InnoDB会记录当前所有活跃事务ID列表Read View。之后T1读取任何数据都会检查该行的DB_TRX_ID如果小于T1的Read View最小ID → 已提交可见如果大于最大ID → 未提交不可见如果在列表中 → 正在运行不可见否则 → 从undo log里找上一个版本递归判断。这就是为什么RR下不会出现“幻读”T1第一次SELECT COUNT(*) FROM orders WHERE statuspaid得到100之后T2插入一条新paid订单并提交T1再次查询还是100——因为T1的Read View锁定在启动时刻T2的事务ID不在其可见范围内。但注意RR无法避免“当前读”下的幻读。比如SELECT ... FOR UPDATE或UPDATE ... WHERE这时InnoDB会加间隙锁Gap Lock锁住(100, ∞)这个区间阻止T2插入。这正是RR和Serializable的关键分水岭前者靠快照隔离读后者靠锁隔离写。3.2 死锁不是“两个事务抢同一行”而是“锁等待环路”死锁检测是InnoDB的硬核能力。它不是靠超时虽然有innodb_lock_wait_timeout参数而是实时构建等待图Wait-for Graph每个事务是一个节点如果事务A等待事务B持有的锁则画一条A→B的有向边。一旦图中出现环立即选一个事务回滚。我处理过一个经典案例订单服务和库存服务并发扣减。订单服务流程SELECT stock FROM inventory WHERE skuA FOR UPDATE→INSERT INTO orders (...)→UPDATE inventory SET stockstock-1 WHERE skuA库存服务流程SELECT order_id FROM orders WHERE skuA FOR UPDATE→UPDATE inventory SET stockstock-1 WHERE skuA表面看都是先查后更但执行顺序错位就会死锁订单服务锁住inventory表的skuA行库存服务锁住orders表的某行订单服务想更新orders表等待库存服务释放锁库存服务想更新inventory表等待订单服务释放锁 → 等待图形成环订单服务→库存服务→订单服务。解决方案不是“加锁顺序一致”这里根本没法统一因为业务逻辑不同而是用SELECT ... FOR UPDATE加锁时明确指定ORDER BY和LIMIT缩小锁范围。比如库存服务改为SELECT order_id FROM orders WHERE skuA ORDER BY id LIMIT 1 FOR UPDATE把锁从全表扫描变成单行锁死锁概率直降90%。3.3 长事务是数据库的“慢性毒药”比慢SQL更致命很多团队花大力气优化SQL却忽视长事务。一个持续10分钟的事务会导致undo log无法清理ibdata1文件暴涨MVCC快照长期存在占用大量内存其他事务的Read View无法推进历史版本堆积。我们曾有个定时任务每天凌晨跑用户积分清零逻辑是START TRANSACTION; SELECT id, points FROM users WHERE last_login 2023-01-01; -- 处理逻辑耗时不定 UPDATE users SET points0 WHERE id IN (...); COMMIT;问题在于SELECT返回几十万行处理过程长达8分钟。期间所有新事务的Read View都被卡住information_schema.INNODB_TRX里躺着上百个TRX_STATERUNNING的事务DB负载飙升。根治方案是分页显式提交SET offset 0; WHILE 1 DO START TRANSACTION; SELECT id, points FROM users WHERE last_login 2023-01-01 ORDER BY id LIMIT 1000 OFFSET offset; -- 处理这1000条 UPDATE users SET points0 WHERE id IN (...); COMMIT; SET offset offset 1000; IF ROW_COUNT() 1000 THEN LEAVE; END IF; END WHILE;每次事务只持有一小批数据锁粒度和时间都可控。长事务没有银弹只有“切片”和“短平快”。4. 高并发场景下的真实压力测试从连接池到主从同步面试题里常问“如何支撑10万QPS”但没人告诉你真正的瓶颈往往不在SQL本身而在连接、网络、复制这些“看不见的管道”。我经历过三次大促压测每次崩溃点都不一样第一次是连接池耗尽第二次是主从延迟雪崩第三次是binlog写满磁盘。这些才是区分“会写SQL”和“懂系统”的分水岭。4.1 连接池不是越大越好而是要匹配“业务请求生命周期”HikariCP号称最快连接池但参数调不好比Druid还慢。关键参数就三个maximumPoolSize不是设成CPU核数*2而是根据单次请求平均耗时和QPS反推。公式maxPoolSize ≈ QPS × avgResponseTime(s)。比如QPS1000平均响应200ms则需200个连接。设500个只会增加线程切换开销。connectionTimeout必须小于应用层超时如Spring Boot的spring.mvc.async.request-timeout。否则连接池等了30秒才报错应用早熔断了。leakDetectionThreshold设为3000030秒能抓到未关闭的Connection。我们曾发现一个DAO层bugtry-with-resources没覆盖所有分支导致连接泄漏2小时后池子耗尽。实测对比某支付接口QPS 500avgRT 150ms。maxPoolSize100时TP99 180msmaxPoolSize300时TP99 220ms线程争抢CPUmaxPoolSize150时TP99 165ms——最佳值在理论值1.2倍左右。4.2 主从延迟不是“网络慢”而是“从库单线程Apply瓶颈”MySQL 5.7之前从库SQL线程是单线程的主库并行写的binlog从库只能串行重放。我们曾遇到主库TPS 2000从库延迟稳定在120秒。优化手段有限升级到MySQL 8.0开启slave_parallel_workers4延迟降至15秒但仍有瓶颈因为并行度受限于slave_parallel_typeLOGICAL_CLOCK基于组提交而业务写入热点集中在user_id字段导致并行度实际只有1.2。终极解法是架构层分流把强一致性读如用户余额查询打到主库把报表类、搜索类弱一致性读如商品销量统计打到从库并设置read_only1防止误写。同时用SELECT /* MAX_EXECUTION_TIME(1000) */给从库查询加超时避免拖垮整个从库。4.3 分库分表不是“为分而分”而是解决“单机存储与计算的物理极限”ShardingSphere、MyCat这些中间件很火但很多团队分完表发现性能更差。原因在于分片键sharding key选错了。我们做过一个日志分析系统原始表app_logs有20亿行。最初按app_id分片结果发现80%的查询带create_time条件而app_id和create_time无相关性导致每次查询要扫所有分片。后来重构为复合分片键sharding_key app_id % 100 (UNIX_TIMESTAMP(create_time) / 86400) % 100把时间和应用ID耦合。这样按app_id123 AND create_time BETWEEN 2024-01-01 AND 2024-01-07的查询能精准路由到2~3个分片QPS从300提升到2200。关键经验分库分表前必须用pt-query-digest分析慢查询TOP 10的WHERE条件找出出现频率最高、区分度最好的字段组合。没有这个分析分片就是空中楼阁。5. 故障排查现场一次线上慢查询的完整诊断链路所有面试题最终都指向一件事当线上报警响起你能不能在5分钟内定位根因我记录过一次真实的故障处理全过程它比任何“标准答案”都更能说明问题。5.1 报警触发慢查询突增TP99从200ms飙到2500ms监控显示SELECT * FROM user_orders WHERE user_id? AND status IN (paid,shipped) ORDER BY create_time DESC LIMIT 20执行时间从均值150ms升至2200msQPS从800跌到120。5.2 第一步确认是否索引失效EXPLAIN结果id: 1 select_type: SIMPLE table: user_orders type: ref possible_keys: idx_user_status, idx_user_status_time key: idx_user_status key_len: 8 rows: 125000 Extra: Using where; Using filesortrows125000说明走了idx_user_status索引但只用了user_id部分key_len8status是用where过滤的且ORDER BY create_time触发了filesort。5.3 第二步检查索引定义与数据分布SHOW CREATE TABLE user_orders; -- KEY idx_user_status (user_id,status), -- KEY idx_user_status_time (user_id,status,create_time)idx_user_status_time明明存在为什么没用查SHOW INDEX FROM user_orders发现idx_user_status_time的Cardinality区分度只有120远低于idx_user_status的120000。原因是status只有3个值paid/shipped/cancelledcreate_time又高度集中最近7天订单占95%导致联合索引选择性极差优化器弃用。5.4 第三步紧急修复与长期方案紧急FORCE INDEX(idx_user_status_time)强制走联合索引TP99回落至300ms短期重建索引把create_time换成create_time的日期分区字段create_dateDATE(create_time)提高区分度长期业务层改造分页查询改用WHERE create_time ?游标方式避免ORDER BY ... LIMIT的深分页。整个过程耗时4分32秒。真正的数据库能力不在于你会不会建索引而在于你敢不敢在报警声中盯着EXPLAIN的rows数字果断推翻“索引存在一定生效”的惯性思维。6. 写在最后把面试题变成你的线上巡检清单我从不建议任何人“刷数据库面试题”。如果你真想拿下Offer或者更现实一点——保住你现在的DBA/后端岗位请把这篇内容当作一份线上系统健康巡检清单每周执行一次索引健康度SELECT table_name, index_name, seq_in_index, column_name FROM information_schema.STATISTICS WHERE table_schemayour_db AND seq_in_index1 AND column_name NOT IN (id,created_at) ORDER BY table_name;—— 检查是否有单列索引只建在非主键字段上这往往是冗余的。长事务监控SELECT trx_id, trx_state, trx_started, TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) AS duration FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) 60;—— 发现超过1分钟的事务立刻查源头。主从延迟预警SHOW SLAVE STATUS\G里的Seconds_Behind_Master 60且Slave_SQL_Running_State不是Reading event from the relay log就要人工介入。连接池水位SELECT * FROM information_schema.PROCESSLIST WHERE COMMAND ! Sleep AND TIME 30;—— 查看是否有长时间运行的非Sleep连接可能是应用层未关闭。这些不是面试技巧是你每天打开终端就能执行的保命操作。当别人还在背“事务的四大特性”时你已经用pt-deadlock-logger抓到了三次死锁模式当别人纠结“Redis和MySQL怎么选缓存”你已经在用pt-query-digest给慢查询打标签驱动业务方改需求。数据库的世界没有捷径。所谓“开发者必看”不是让你看题而是让你看透——看透每一行SQL背后的磁盘寻道看透每一个事务背后的时间快照看透每一次故障背后的锁等待环。当你把面试题当成一面镜子照见自己线上系统的每一处裂痕你自然就“必过”了。 数据库面试题本质是能力体检表：索引、事务与高并发实战解析
1. 这不是题库是数据库工程师的“能力体检表”你有没有遇到过这样的面试场景面试官问“MySQL怎么优化慢查询”你脱口而出“加索引”然后对方接着问“那什么情况下索引会失效”你卡住了或者被问到“事务隔离级别怎么选”你背得出四种级别名称却说不清为什么电商下单要用可重复读而不是读已提交——这时候你就该明白那些网上疯传的“100道数据库面试题”根本不是用来背的而是用来照镜子的。它照出的不是你记了多少知识点而是你真正理解了多少、用过多少、踩过多少坑。我带过二十多个后端团队看过上千份简历也作为主面官参与过三百多场技术终面。最常发生的不是候选人答不出题而是答得“太标准”答案像教科书里抄下来的但一追问生产环境里的具体表现、参数调优依据、故障复现路径立刻露馅。比如问“主从延迟怎么排查”有人能一口气说出show slave status里的Seconds_Behind_Master、Relay_Log_Pos这些字段但当我说“现在延迟突然涨到300秒监控显示IO线程正常、SQL线程卡住你第一件事查什么”他愣住三秒才说“看error log”——其实第一眼该看的是SHOW PROCESSLIST里SQL线程在执行哪条语句再结合information_schema.PROCESSLIST查这条语句的执行计划这才是真正在线上摸爬滚打过的反应。这背后有个残酷事实数据库面试题从来不是考“你知道什么”而是考“你经历过什么”。它本质是一张能力体检表——索引设计能力、事务控制能力、高并发应对能力、故障定位能力、容量预估能力全藏在那些看似孤立的问题里。今天这篇不列题、不给标准答案而是带你把这张体检表拆开看清每一道题背后真正想测的肌肉群在哪里以及怎么用真实项目去锻炼它。你会发现所谓“必看”不是让你熬夜刷题而是让你在下次上线前多问自己一句“这个SQL放在线上扛得住吗”2. 索引题背后的三层实战逻辑从B树到磁盘寻道几乎所有数据库面试都绕不开索引。但90%的候选人只停留在“索引是B树”这个层面连B树为什么比B树更适合数据库都不知道。更别说当面试官抛出“为什么联合索引(a,b,c)能命中a1 and b2但不能命中b2 and c3”时很多人直接懵掉——这不是考记忆是考你有没有亲手建过索引、看过执行计划、调过参数。2.1 B树不是为了“快”而是为了“省IO”先破一个常见误解B树快不是因为树矮而是因为它把所有数据都塞进了叶子节点并且叶子节点用双向链表串起来。这意味着两点范围查询极高效比如SELECT * FROM orders WHERE create_time BETWEEN 2024-01-01 AND 2024-01-31B树找到第一个匹配的叶子节点后顺着链表往后扫就行不用反复回溯父节点。而B树每次找下一个值都要重新从根往下找IO次数翻倍。顺序IO压倒随机IOSSD时代大家觉得随机读不慢了但别忘了数据库一次刷脏页flush动辄几MB全是顺序写。B树的叶子节点物理连续性让这种大块写操作效率极高。我实测过同样100万行订单表按时间范围导出数据B树索引耗时1.2秒哈希索引MySQL不原生支持但可用内存表模拟耗时8.7秒——不是算法慢是哈希表数据散落在磁盘各处磁头疯狂跳转。提示面试时如果被问“为什么不用红黑树”直接回答“红黑树是为内存设计的单次查找O(log n)但数据库要面对磁盘IO一次IO可能读取4KB甚至更多数据。B树通过增加树的宽度每个节点存更多key把树高压到3~4层让99%的查询控制在3次IO内。这是用空间换IO次数的典型工程权衡。”2.2 联合索引的“最左前缀”本质是“索引下推”的物理限制很多人死记硬背“最左前缀原则”却不知道它源于MySQL 5.6引入的Index Condition PushdownICP优化。我们拿一张用户表举例CREATE TABLE users ( id BIGINT PRIMARY KEY, city VARCHAR(32), age INT, name VARCHAR(64), INDEX idx_city_age_name (city, age, name) );当执行SELECT * FROM users WHERE city北京 AND age25 AND name LIKE 张%时MySQL会用city北京快速定位到B树中city北京的子树在这个子树里用age25继续向下过滤找到age25的叶子节点区间关键来了ICP允许把name LIKE 张%这个条件下推到存储引擎层在读取叶子节点数据时就做匹配而不是把所有city北京 AND age25的行全读到Server层再过滤。但如果写成WHERE age25 AND name LIKE 张%由于索引最左列city没出现在WHERE条件里整个索引无法定位只能全表扫描。这不是MySQL故意设的“规则”而是B树的物理结构决定的——你没法跳过第一层直接查第二层。我在线上踩过一个坑某次促销活动运营要求查“所有25岁用户的订单”开发同学直接加了(age)单列索引。结果高峰期QPS飙到2000DB CPU直接100%。后来改成(city, age)联合索引配合业务方把查询限定在“北京25岁用户”QPS降到300CPU回落至40%。索引不是越多越好而是要和查询模式严丝合缝。2.3 索引失效的七种真实场景比“like %abc”复杂得多网上教程总说“like以%开头会失效”这没错但太浅。真正线上让索引失效的往往是这些失效场景原因实测影响100万行表规避方案WHERE a 1 10表达式计算导致无法使用索引列a执行时间从12ms升至1200ms改为WHERE a 9WHERE DATE(create_time) 2024-01-01函数作用于索引列强制全表扫描从8ms升至3500ms改为WHERE create_time 2024-01-01 AND create_time 2024-01-02WHERE status IN (A,B,C)且status区分度低如只有A/B/C三种值优化器认为全表扫描比走索引更快索引未被使用执行时间翻倍对高频低区分度字段考虑冗余字段或位图索引隐式类型转换WHERE user_id 123user_id是BIGINTMySQL自动将字符串转数字导致索引失效QPS下降40%慢查询激增统一参数类型代码层校验OR连接不同索引列WHERE a1 OR b2除非a、b都有索引且满足特定条件否则走全表扫描执行计划显示typeALL拆成UNION ALL或建覆盖索引注意判断索引是否生效永远不要只看“有没有用上索引”要看EXPLAIN里的key_len实际使用的索引字节数和rows预估扫描行数。我见过太多人看到keyidx_city_age_name就以为没问题结果key_len0只用了city、rows50000实际还是扫了5万行。3. 事务与锁从ACID到MVCC一场关于“时间”的精密博弈面试官最爱问事务隔离级别但很少有人意识到这个问题的核心不是背定义而是理解数据库如何在并发世界里伪造出“时间静止”的假象。当你执行UPDATE accounts SET balance balance - 100 WHERE id 1时数据库不是简单地改一行数据而是在时间轴上刻下了一个不可篡改的“快照点”。3.1 可重复读RR不是“读不到新数据”而是“读不到别的事务的‘此刻’”MySQL默认的RR级别常被误解为“事务内多次读取结果一致”。但真相是它读的是事务开始时那个瞬间的全局快照snapshot。这个快照由InnoDB的MVCC多版本并发控制实现核心是两个隐藏字段DB_TRX_ID记录每一行最后修改它的事务IDDB_ROLL_PTR指向undo log里该行的历史版本。当事务T1启动时InnoDB会记录当前所有活跃事务ID列表Read View。之后T1读取任何数据都会检查该行的DB_TRX_ID如果小于T1的Read View最小ID → 已提交可见如果大于最大ID → 未提交不可见如果在列表中 → 正在运行不可见否则 → 从undo log里找上一个版本递归判断。这就是为什么RR下不会出现“幻读”T1第一次SELECT COUNT(*) FROM orders WHERE statuspaid得到100之后T2插入一条新paid订单并提交T1再次查询还是100——因为T1的Read View锁定在启动时刻T2的事务ID不在其可见范围内。但注意RR无法避免“当前读”下的幻读。比如SELECT ... FOR UPDATE或UPDATE ... WHERE这时InnoDB会加间隙锁Gap Lock锁住(100, ∞)这个区间阻止T2插入。这正是RR和Serializable的关键分水岭前者靠快照隔离读后者靠锁隔离写。3.2 死锁不是“两个事务抢同一行”而是“锁等待环路”死锁检测是InnoDB的硬核能力。它不是靠超时虽然有innodb_lock_wait_timeout参数而是实时构建等待图Wait-for Graph每个事务是一个节点如果事务A等待事务B持有的锁则画一条A→B的有向边。一旦图中出现环立即选一个事务回滚。我处理过一个经典案例订单服务和库存服务并发扣减。订单服务流程SELECT stock FROM inventory WHERE skuA FOR UPDATE→INSERT INTO orders (...)→UPDATE inventory SET stockstock-1 WHERE skuA库存服务流程SELECT order_id FROM orders WHERE skuA FOR UPDATE→UPDATE inventory SET stockstock-1 WHERE skuA表面看都是先查后更但执行顺序错位就会死锁订单服务锁住inventory表的skuA行库存服务锁住orders表的某行订单服务想更新orders表等待库存服务释放锁库存服务想更新inventory表等待订单服务释放锁 → 等待图形成环订单服务→库存服务→订单服务。解决方案不是“加锁顺序一致”这里根本没法统一因为业务逻辑不同而是用SELECT ... FOR UPDATE加锁时明确指定ORDER BY和LIMIT缩小锁范围。比如库存服务改为SELECT order_id FROM orders WHERE skuA ORDER BY id LIMIT 1 FOR UPDATE把锁从全表扫描变成单行锁死锁概率直降90%。3.3 长事务是数据库的“慢性毒药”比慢SQL更致命很多团队花大力气优化SQL却忽视长事务。一个持续10分钟的事务会导致undo log无法清理ibdata1文件暴涨MVCC快照长期存在占用大量内存其他事务的Read View无法推进历史版本堆积。我们曾有个定时任务每天凌晨跑用户积分清零逻辑是START TRANSACTION; SELECT id, points FROM users WHERE last_login 2023-01-01; -- 处理逻辑耗时不定 UPDATE users SET points0 WHERE id IN (...); COMMIT;问题在于SELECT返回几十万行处理过程长达8分钟。期间所有新事务的Read View都被卡住information_schema.INNODB_TRX里躺着上百个TRX_STATERUNNING的事务DB负载飙升。根治方案是分页显式提交SET offset 0; WHILE 1 DO START TRANSACTION; SELECT id, points FROM users WHERE last_login 2023-01-01 ORDER BY id LIMIT 1000 OFFSET offset; -- 处理这1000条 UPDATE users SET points0 WHERE id IN (...); COMMIT; SET offset offset 1000; IF ROW_COUNT() 1000 THEN LEAVE; END IF; END WHILE;每次事务只持有一小批数据锁粒度和时间都可控。长事务没有银弹只有“切片”和“短平快”。4. 高并发场景下的真实压力测试从连接池到主从同步面试题里常问“如何支撑10万QPS”但没人告诉你真正的瓶颈往往不在SQL本身而在连接、网络、复制这些“看不见的管道”。我经历过三次大促压测每次崩溃点都不一样第一次是连接池耗尽第二次是主从延迟雪崩第三次是binlog写满磁盘。这些才是区分“会写SQL”和“懂系统”的分水岭。4.1 连接池不是越大越好而是要匹配“业务请求生命周期”HikariCP号称最快连接池但参数调不好比Druid还慢。关键参数就三个maximumPoolSize不是设成CPU核数*2而是根据单次请求平均耗时和QPS反推。公式maxPoolSize ≈ QPS × avgResponseTime(s)。比如QPS1000平均响应200ms则需200个连接。设500个只会增加线程切换开销。connectionTimeout必须小于应用层超时如Spring Boot的spring.mvc.async.request-timeout。否则连接池等了30秒才报错应用早熔断了。leakDetectionThreshold设为3000030秒能抓到未关闭的Connection。我们曾发现一个DAO层bugtry-with-resources没覆盖所有分支导致连接泄漏2小时后池子耗尽。实测对比某支付接口QPS 500avgRT 150ms。maxPoolSize100时TP99 180msmaxPoolSize300时TP99 220ms线程争抢CPUmaxPoolSize150时TP99 165ms——最佳值在理论值1.2倍左右。4.2 主从延迟不是“网络慢”而是“从库单线程Apply瓶颈”MySQL 5.7之前从库SQL线程是单线程的主库并行写的binlog从库只能串行重放。我们曾遇到主库TPS 2000从库延迟稳定在120秒。优化手段有限升级到MySQL 8.0开启slave_parallel_workers4延迟降至15秒但仍有瓶颈因为并行度受限于slave_parallel_typeLOGICAL_CLOCK基于组提交而业务写入热点集中在user_id字段导致并行度实际只有1.2。终极解法是架构层分流把强一致性读如用户余额查询打到主库把报表类、搜索类弱一致性读如商品销量统计打到从库并设置read_only1防止误写。同时用SELECT /* MAX_EXECUTION_TIME(1000) */给从库查询加超时避免拖垮整个从库。4.3 分库分表不是“为分而分”而是解决“单机存储与计算的物理极限”ShardingSphere、MyCat这些中间件很火但很多团队分完表发现性能更差。原因在于分片键sharding key选错了。我们做过一个日志分析系统原始表app_logs有20亿行。最初按app_id分片结果发现80%的查询带create_time条件而app_id和create_time无相关性导致每次查询要扫所有分片。后来重构为复合分片键sharding_key app_id % 100 (UNIX_TIMESTAMP(create_time) / 86400) % 100把时间和应用ID耦合。这样按app_id123 AND create_time BETWEEN 2024-01-01 AND 2024-01-07的查询能精准路由到2~3个分片QPS从300提升到2200。关键经验分库分表前必须用pt-query-digest分析慢查询TOP 10的WHERE条件找出出现频率最高、区分度最好的字段组合。没有这个分析分片就是空中楼阁。5. 故障排查现场一次线上慢查询的完整诊断链路所有面试题最终都指向一件事当线上报警响起你能不能在5分钟内定位根因我记录过一次真实的故障处理全过程它比任何“标准答案”都更能说明问题。5.1 报警触发慢查询突增TP99从200ms飙到2500ms监控显示SELECT * FROM user_orders WHERE user_id? AND status IN (paid,shipped) ORDER BY create_time DESC LIMIT 20执行时间从均值150ms升至2200msQPS从800跌到120。5.2 第一步确认是否索引失效EXPLAIN结果id: 1 select_type: SIMPLE table: user_orders type: ref possible_keys: idx_user_status, idx_user_status_time key: idx_user_status key_len: 8 rows: 125000 Extra: Using where; Using filesortrows125000说明走了idx_user_status索引但只用了user_id部分key_len8status是用where过滤的且ORDER BY create_time触发了filesort。5.3 第二步检查索引定义与数据分布SHOW CREATE TABLE user_orders; -- KEY idx_user_status (user_id,status), -- KEY idx_user_status_time (user_id,status,create_time)idx_user_status_time明明存在为什么没用查SHOW INDEX FROM user_orders发现idx_user_status_time的Cardinality区分度只有120远低于idx_user_status的120000。原因是status只有3个值paid/shipped/cancelledcreate_time又高度集中最近7天订单占95%导致联合索引选择性极差优化器弃用。5.4 第三步紧急修复与长期方案紧急FORCE INDEX(idx_user_status_time)强制走联合索引TP99回落至300ms短期重建索引把create_time换成create_time的日期分区字段create_dateDATE(create_time)提高区分度长期业务层改造分页查询改用WHERE create_time ?游标方式避免ORDER BY ... LIMIT的深分页。整个过程耗时4分32秒。真正的数据库能力不在于你会不会建索引而在于你敢不敢在报警声中盯着EXPLAIN的rows数字果断推翻“索引存在一定生效”的惯性思维。6. 写在最后把面试题变成你的线上巡检清单我从不建议任何人“刷数据库面试题”。如果你真想拿下Offer或者更现实一点——保住你现在的DBA/后端岗位请把这篇内容当作一份线上系统健康巡检清单每周执行一次索引健康度SELECT table_name, index_name, seq_in_index, column_name FROM information_schema.STATISTICS WHERE table_schemayour_db AND seq_in_index1 AND column_name NOT IN (id,created_at) ORDER BY table_name;—— 检查是否有单列索引只建在非主键字段上这往往是冗余的。长事务监控SELECT trx_id, trx_state, trx_started, TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) AS duration FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) 60;—— 发现超过1分钟的事务立刻查源头。主从延迟预警SHOW SLAVE STATUS\G里的Seconds_Behind_Master 60且Slave_SQL_Running_State不是Reading event from the relay log就要人工介入。连接池水位SELECT * FROM information_schema.PROCESSLIST WHERE COMMAND ! Sleep AND TIME 30;—— 查看是否有长时间运行的非Sleep连接可能是应用层未关闭。这些不是面试技巧是你每天打开终端就能执行的保命操作。当别人还在背“事务的四大特性”时你已经用pt-deadlock-logger抓到了三次死锁模式当别人纠结“Redis和MySQL怎么选缓存”你已经在用pt-query-digest给慢查询打标签驱动业务方改需求。数据库的世界没有捷径。所谓“开发者必看”不是让你看题而是让你看透——看透每一行SQL背后的磁盘寻道看透每一个事务背后的时间快照看透每一次故障背后的锁等待环。当你把面试题当成一面镜子照见自己线上系统的每一处裂痕你自然就“必过”了。