1. 为什么我会把数据库笔记当成系统来维护1.1 从一次线上事故说起三年前我接手过一个模拟项目X的后端维护系统平时跑得好好的结果某个版本上线后接口响应时间从80毫秒直接飙到4秒。查了一圈代码缓存也没失效日志也没有报错最后打开数据库慢查询日志才发现一个联表查询扫了上千万行。就是因为在某个高频查询条件上少建了一个索引。那次事故之后我养成了一个习惯凡是踩过的坑、查过的原理、验证过的参数全部写进数据库笔记。写到现在这份笔记已经接近三百条分类条目从建表规范到主从延迟排查从索引失效场景到备份恢复演练基本覆盖了后端开发里会遇到的绝大多数数据库问题。很多人觉得数据库笔记就是面试前背的八股文其实不是你真正遇到线上问题的时候翻笔记和翻文档完全是两种效率。这份笔记帮我撑过了至少三次凌晨两点的故障处理。一次是磁盘被慢查询日志写满一次是死锁导致批量任务卡死还有一次是误删了一张业务表的全部数据。如果没有平时沉淀的排查路径和恢复脚本靠临时查资料来处理至少要多花两三个小时。所以这篇文章与其说是讲数据库不如说是讲我怎么把数据库知识组织成一套能反复调用的笔记系统。里面的选型思路、索引原理、事务机制、慢查询排查和备份恢复方案都是我在实际项目里验证过的。适合刚接触后端不久、想把数据库学扎实的同学也适合已经在写业务代码、但遇到性能问题还是凭感觉猜的开发者。1.2 笔记体系的分层思路我最早做记录的时候看到什么记什么结果几个月之后回头翻根本找不到当时那条笔记在哪个文件里。后来参考了那种“检索优先”的思路把笔记重新拆成四个层次随手记录、专题整理、复盘总结、操作手册。随手记录就是遇到问题先记下来的零散碎片比如“某版本执行计划走错索引了”“某条SQL在本地和线上结果不一致”。这类内容不需要整理重点是快。专题整理是把同一主题的碎片合并成一篇完整的笔记比如“MySQL索引失效场景大全”“PostgreSQL的vacuum机制”。复盘总结是故障处理完之后把时间线、根因、修复动作、改进措施梳理清楚。操作手册是标准化的执行步骤比如备份恢复流程、慢查询分析流程这类内容要写成“照着做就行”。这个分层最大的好处是笔记从“记录过去”变成了“支撑未来”。你遇到一个新问题先查操作手册能不能直接解决再翻复盘总结看有没有类似案例最后才去跟着网上的文档临时查。数据库这种领域知识体系太庞大了靠记忆根本不现实关键是要有一本能快速检索的“实践字典”。2. 数据库选型笔记先搞清楚你要解决什么问题2.1 关系型数据库的核心价值很多做后端开发的朋友选数据库的时候习惯跟风听到哪个热门就用哪个。我在笔记里专门写了一页“选型前必须回答的三个问题”数据要不要强一致读写比例是多少数据量预期有多大关系型数据库的核心价值就在于事务和约束它能保证一批操作要么全部成功要么全部回滚这是做订单、库存、账户这类业务的基本前提。我经历过一个项目早期为了追求性能把订单状态直接写在Redis里Redis挂了之后数据回退到了几分钟之前用户那边看到订单状态反复横跳。后来还是老老实实把核心交易数据迁回了关系型数据库。这不是说Redis不好而是它的定位本身就是缓存和特定场景的高并发读写用它存核心交易数据是在用它的短处。关系型数据库的另一大价值是SQL这个通用语言。不管你是用MySQL、PostgreSQL还是Oracle只要会了标准SQL迁移和排查都多一层保障。那些复杂的报表统计、聚合计算用SQL表达起来非常自然而如果用文档型数据库硬扛代码会复杂很多。2.2 非关系型数据库的适用场景我的笔记里不会否定任何一类数据库关键是场景匹配。比如需要超高吞吐的缓存层Redis这种键值型就非常合适。需要存储灵活多变的业务字段MongoDB这种文档型数据库能让迭代省去大量改表结构的工作。需要存储海量关系数据的图结构图数据库才有优势。判断依据也很简单先看业务对数据一致性的容忍度再看数据模型是固定的还是变化的。有些业务场景比如用户会话、验证码、接口频控用Redis天经地义因为丢掉一两条数据影响不大。有些场景比如文章阅读量、点赞数允许短暂不一致也可以先放缓存再异步刷库。但凡是涉及钱、订单、权限这类不能出错的数据我的原则很明确数据库选型以关系型为主缓存只做加速不做唯一的存储。你可以把热数据放到Redis里读得快但底层必须有一个可靠的持久化存储兜底。2.3 一份可复用的选型对照表下面这个表格是我整理笔记的时候画的现在每次新项目启动我都会对着它过一遍。它不是一个绝对的标准但能帮你快速排除明显不合适的选项。数据特征推荐方向典型场景需要警惕的地方强事务、结构化强关系型数据库订单、账户、库存单表过大、索引设计不合理读多写少、允许缓存关系型缓存层商品详情、用户信息缓存穿透、缓存雪崩字段多变、结构不固定文档型数据库活动配置、商品扩展属性复杂聚合查询能力偏弱高并发计数、频控键值型数据库阅读数、验证码、限流丢失数据不可用于核心交易关系网络密集图数据库好友关系、推荐链路团队学习成本、运维成本选型做完了接下来真正决定系统能不能扛住压力的其实是表结构和索引设计。这也是我笔记里篇幅最大的一章下面单独拿出来讲。3. 索引与执行计划笔记里最不能省的一章3.1 B树到底解决了什么问题很多刚从学校出来的人说起索引就只知道“加快查询”但你要问他为什么是B树而不是二叉树、不是哈希表他就说不上来了。我在笔记里把这部分单独写了一节因为只有理解了索引的数据结构才能真正明白哪些查询能走索引哪些查询走了也是白走。B树的本质是“矮胖”的多路搜索树一个节点可以存多个键值三层左右的树就能存上千万条记录。和二叉树比它的高度小得多意味着磁盘IO次数少。和哈希索引比它支持范围查询和排序因为叶子节点是有序的而且是单向链表连接扫描起来非常顺滑。明白这个之后很多问题就通了。为什么模糊查询LIKE %关键词用不上索引因为需要从树根开始搜索但第一个字符不确定根本不知道往哪个分支走。为什么范围查询能走索引因为叶子节点上有序定位到起点之后顺着链表往后扫就行。这些特性不是靠背的是数据结构本身决定的。3.2 联合索引与最左前缀原则我见过很多同事建联合索引的时候习惯把区分度高的字段放前面这个想法大体没错但更准确的说法是联合索引的字段顺序要服从你的查询条件。比如(a, b)这个索引本质上先按 a 排序a 相同再按 b 排序。如果你经常用where b ?单独查询这个索引就帮不上忙因为 b 在整个索引里不是最前级的排序维度。最左前缀原则是联合索引最核心的约束但很多人理解成了“查询条件必须包含最左字段”这其实不准确。正确理解是查询条件里必须能用上联合索引的最左前缀优化器才可能走这个索引。比如(a, b, c)的索引where a ? and c ?能用上 a 这个前缀c 这个条件因为跳过了 b通常是无法利用索引下推到 c 的。这里有个很实用的调优技巧如果你有一个高频查询是where b ?而现有索引是(a, b)与其新建一个(b)索引不如看一下能不能调整索引顺序或者把原有索引改成(a, b, c)并用上 c 来覆盖查询。但要注意改动联合索引顺序可能影响其他查询所以要结合慢查询日志一起分析不能只看一个SQL。3.3 explain 怎么看索引失效怎么定位排查SQL性能问题第一步永远是看执行计划。在MySQL里就是EXPLAIN在PostgreSQL里就是EXPLAIN ANALYZE。我在笔记里列了一个执行计划速查清单重点看几个字段type是不是从const、eq_ref、ref、range一路劣化到了ALLkey用的到底是哪个索引rows估算的行数是不是比实际数据量还离谱。索引失效是我笔记里反复更新的一节因为每次发现新场景就补一条。最常见的几类对索引列做了函数运算、隐式类型转换导致索引失效、OR条件带了一个未索引的字段、NOT IN、LIKE以通配符开头。还有一类非常隐蔽就是字符集不一致表A是utf8mb4表B是utf8两个表关联的时候MySQL无法直接比较字节序索引经常就不走了。写到这里我才发现那些被传得神乎其神的“索引优化技巧”其实都能归结到数据结构和优化器的行为上。你把B树的工作方式想清楚就已经理解了80%的索引失效场景剩下的只是多看执行计划积累经验。4. 事务、隔离级别与并发控制从理论到排查死锁4.1 隔离级别如何影响读写事务隔离级别这个知识点几乎所有后端面试都会问但真正在工作中能准确判断问题的人却没那么多。我笔记里的做法是把四个级别放到具体场景里对比而不是只背名词。读未提交的隔离级别下一个事务能读到另一个事务未提交的数据这在金融类业务里是绝对不能接受的。读已提交是很多数据库的默认级别也是PostgreSQL的默认行为它避免了脏读。可重复读是MySQL InnoDB的默认级别除了避免脏读还保证了同一个事务内多次读取同一行数据结果一致。可串行化则完全隔离并发代价是性能下降非常明显。大部分业务系统用可重复读或读已提交就够了根本不需要上升到可串行化。真正值得花时间研究的不是背级别而是搞清楚每个隔离级别下面的间隙锁、半一致性读这些细节。比如可重复读下如果查询条件走的是非唯一索引InnoDB可能会在索引范围内加间隙锁导致看似不相干的行插入被阻塞这就是死锁和并发瓶颈的高发来源。4.2 MVCC 与 undo log 的配合为什么要引入MVCC最直接的原因是读写锁互斥会拖垮并发性能。MVCC的思路是让读操作不阻塞写操作让写操作也不阻塞读操作靠的是数据多版本。在InnoDB里每一行数据除了业务字段还隐藏了trx_id和roll_pointer前者记录最后修改它的事务编号后者指向undo log里的旧版本链。当一个普通的SELECT执行时它会根据当前事务的快照沿undo log版本链找到对当前事务可见的版本。这就是为什么你可以在一个事务里反复读结果始终一致即使其他事务已经提交了新的修改。可见性判断的规则说白了就是只有在这个事务开始之前就已经提交的版本或者这个事务自己修改的版本才会被看到。这套机制让我后来在排查“为什么这个连接看到的数据和另一个连接不一致”时完全不用猜了。先确认隔离级别再确认事务的启动时间然后沿着版本链找可见版本基本都能定位。梳理清楚MVCC之后你就能理解为什么有些框架要显式地开启事务来保证一致性为什么在长事务里不能随便执行修改操作因为长事务意味着undo log要保留很久直接拖慢数据库。4.3 死锁日志分析实例死锁是并发事务绕不开的问题我第一次遇到死锁的时候直接看懵了日志里全是互不相关的加锁记录根本不知道从哪里入手。后来我慢慢总结出一套分析死锁日志的固定套路先找到两个等待事件再看它们各自持有和等待的锁对象最后缩小到具体的SQL和索引。举一个我笔记里记录的案例。有两张表一张是订单主表一张是订单明细表业务上批量更新订单状态时先更新主表再更新明细表但不同线程处理订单的顺序不一样。一个线程要更新订单A再更新明细另一个线程先更新订单A对应明细又更新订单B锁的顺序一交叉死锁就出现了。这类问题最常见的解决办法是让所有事务按照同一个顺序操作资源比如强制按订单号排序后再逐条更新。死锁本身不会破坏数据因为它会自动回滚其中一个事务但如果你没有捕获异常用户的请求就会失败。我在笔记里特别标注了一点数据库死锁处理的标配是重试机制捕获死锁异常后等待一小段时间再次尝试执行事务通常就能成功。但是重试是兜底手段根治还靠锁顺序优化。5. 慢SQL与性能优化的完整排查链路5.1 一次慢接口排查的全过程我有个习惯接到性能问题的工单不急着打开慢查询日志先去把时间线理清楚。有一次线上接口变慢从报警到用户反馈前后不到20分钟我按下面的顺序排查第一步看监控面板确认是数据库耗时上升还是应用本身耗时上升。那次的曲线很明确数据库平均耗时从30毫秒升到了700毫秒说明问题在下游。第二步开慢查询日志找到对应时间段里执行时间排名靠前的SQL。结果有一条SQL执行了3秒多条件查一个订单流水表表里三千万行数据看起来是一个简单的等值查询但执行计划里type显示为ALL全表扫描。第三步为什么明明有索引还是全表扫我看了一下表结构问题出在查询条件里的那个字段上。这张表早期是用订单号作为分区键但查询条件用的是流水号订单号和流水号之间没有建立映射索引数据库只能把分区里所有行都扫一遍。第四步加一个流水号索引之后接口耗时回到40毫秒左右问题解决。这个案例让我养成了一个习惯每次建表都先确认未来主要的检索条件到底有哪些分区键和索引键要对着业务查询路径设计而不是对着存储路径设计。5.2 优化前后的对比优化不能只凭感觉“好像快了”要用数据说话。同一个接口优化前的耗时是750毫秒优化后是38毫秒压测下的QPS从原来的400提升到2800。这个提升主要来自两个动作一是加了那个流水号索引二是把原来在应用层做的大量循环单查合并成了批量查询。批量查询这个点很值得展开。线上业务大量存在“遍历列表然后逐个查详情”的写法每个详情都是一次数据库访问N条数据就是N次往返。改成一次IN查询之后网络往返次数从N降到了1效果立竿见影。但要注意IN列表不能太大我一般控制在一千以内超过的话分批处理。还有一个容易被忽略的点就是SQL的返回字段。很多人习惯写SELECT *但在数据行宽、字段多的情况下全字段查询会把大量用不到的数据从存储层传输到应用层CPU、内存、带宽都会被拖累。我的笔记里有一条经验核心接口的SQL一定要显式列出需要的字段不光是规范问题更是性能问题。5.3 容易被忽略的“隐性”性能问题慢SQL日志只记录超过阈值的语句但很多隐患并不会在那里面暴露。我遇到过几个典型的隐性性能问题都记在笔记里。第一个是大事务一个事务里跑了十几条更新语句虽然没有一条是慢SQL但整个事务持锁时间过长直接阻塞了其他事务的提交。第二个是连接数被打满。应用端每个请求占一个连接SQL本身执行得很快但高并发下连接池不够用请求全部排队表现在外就是“数据库慢”可数据库内部其实很空闲。遇到这种情况光看数据库层慢查询找不到答案要看应用连接池的等待时间。第三个是隐式类型转换。这个前面提过比如WHERE varchar_col 12345数据库会把字符串字段转成数值再比较索引直接失效。这类SQL执行时间不算特别慢但它出现在高频路径上每次多扫描几万行累积起来的压力就非常可观。排查隐性性能问题最有效的办法是持续观察数据库的状态指标和慢SQL趋势把一个时间段内的变化曲线和发布记录对齐很多问题都能定位到具体某次代码变更。6. 备份恢复与高可用笔记里的“保命章节”6.1 备份策略设计有一次朋友的公司出了一个事故开发在测试环境执行SQL的时候连错了生产库一个不带WHERE条件的DELETE把整张表数据清空了。这时候才发现前一个DBA走了之后备份任务已经停了两个月。这个例子充分说明数据库笔记里必须有一个专门的章节写清楚备份策略和恢复流程而且要定期演练不能等出了事再翻文档。我笔记里的推荐策略是全量备份加增量备份组合。全量备份每天一次在业务低峰期执行增量备份按binlog或WAL连续归档。这样设计的原因很直接全量恢复能还原到最近一次备份状态然后用增量日志把数据推进到故障前一刻最大程度减少丢失。备份文件也不能只放在本机磁盘我见过放本机的结果机器磁盘损坏备份和数据一起没了的。至少要有一份备份存储到独立存储异地更好。我现在的标准做法是本机保留最近三天全量备份独立存储保留三十天同时定期执行一次“抽取某个备份文件并启动一个临时实例”的验证确保备份不是一堆打不开的文件。6.2 基于 binlog 的恢复流程如果说全量备份是“回到过去”的基础binlog就是“精确到秒”的关键。以MySQL为例把binlog完整保留下来之后配合全量备份基本能做到误操作之后的精准恢复。我在笔记里写了一套标准操作步骤这里分享出来。第一步找到误操作发生的时间点越精确越好可以通过binlog日志里的时间戳确定。第二步用全量备份恢复到误操作之前的某个备份点。第三步从备份点之后的所有binlog里把误操作前的时间段重放出来让数据推进到误操作前一刻。第四步导出恢复出来的数据再导入生产环境时需要特别注意别覆盖掉故障期间产生的其他正常数据通常的方式是只恢复被误删的表。这套流程最关键的点在于恢复之前先想清楚“目标状态”是什么否则很容易翻车。有一次我在演练中执行到第三步时发现binlog里有大量其他表的事务只过滤误操作表需要按表名过滤binlog事件不然会把其他表也恢复到旧状态引发二次事故。所以我的笔记里特别提醒恢复操作必须先备份当前生产库哪怕只是误删了一张表先补一个完整备份再动手万一恢复过程出错还有回头路。高可用方面常见的架构是主从复制加故障切换。主库负责写从库负责读和备份主库挂了之后可以切换从库。但这里有个平衡问题半同步复制能在主库故障时减少数据丢失但会稍微增加写入延迟。单体应用规模下强一致优先先把主从搭建好业务量上来之后再考虑分库分表。避免一上来就设计一套特别复杂的分布式方案维护成本往往超出收益。7. 数据库笔记的沉淀方法写给同样做笔记的人7.1 我整理笔记的三层结构前面说了笔记分四层这里讲一下具体到“数据库”这个主题时我是怎么组织的。第一层是按数据库产品分目录MySQL目录、PostgreSQL目录、Redis目录、MongoDB目录各自独立。第二层是按主题建文档比如MySQL目录下面有“索引.md”“事务.md”“备份恢复.md”“慢查询排查.md”。第三层是每篇文档内部一定要有一个“踩坑记录”小节里面按时间倒序记录实际遇到的坑。为什么必须按产品分目录因为不同数据库的机制差异太大了MySQL的间隙锁在PostgreSQL里就不完全一样Redis的持久化策略和MySQL更不是一个思路。如果混在一起写查找的时候会非常混乱。踩坑记录是笔记里价值最高的部分里面不需要写完整的理论知识只需要记录现象、根因、排查过程、修复方式、恢复验证。每一条控制在十个字到两百字之间关键是要能快速定位到对应的正文。比如我有一条踩坑记录只有一句话“某版本批量更新时死锁频率上升原因为锁顺序不统一已按订单号排序解决。”看到这句话就能顺着索引章节找到详细的死锁分析。7.2 让笔记变成可复用的排查手册很多人做笔记失败不是因为不勤快而是因为笔记只有“知识点”没有“操作流程”。数据库知识最值钱的部分恰恰是操作流程。比如“如何快速判断一个慢SQL该不该优化”你光知道执行计划有全表扫描没有用还得知道怎么结合表行数、查询频率、写入压力来决定优化优先级。我的一个习惯是每处理完一个线上问题就把分析的SQL、日志片段、执行计划、优化前后的对比数据补充到对应的专题文档里。这样笔记会越来越厚但检索效率越来越高。因为数据库问题和医学病例很像症状千奇百怪但按“索引失效”“锁等待”“主从延迟”这类标签归档后下次遇到相似情况你翻笔记就能直接锁定排查范围。还有一点值得提操作手册要写成“复制粘贴就能用”的标准。比如备份恢复流程里的每个命令、每个参数我都写全数据目录、备份目录、binlog位置都用变量标注。因为人在紧张状态下会漏步骤有一份直接对着执行的清单能大大降低操作失误率。我甚至把常用SQL片段单独存了一个文件比如“查看表大小.sql”“查看当前事务.sql”“查看锁等待.sql”用的时候直接打开复制效率提升非常明显。个人体会最深的是笔记要“反人性”一点不要只记自己懂的东西。遇到不理解的现象哪怕最后没有解决也要先把现象记下来标注“未解决待查”。很多时候正是这些悬而未决的记录在某个深夜突然给你灵感成了后面解决大问题的突破口。