搞MySQL的人不管你是刚看完安装教程准备建库的新手还是已经在生产环境摸爬滚打了几年的老油条早晚都会撞上两个看似基础、实际能把你坑到怀疑人生的点一个是大小写规则另一个是存储引擎。这两个东西平时不怎么显眼但一旦遇到跨平台迁移、表莫名“不存在”、锁表死锁、数据损坏恢复你就会明白当初没花十分钟搞清楚它们后面就要花十个小时去填坑。这篇我打算把两者放在一起讲透顺便把围绕它们的高频问题也一并梳理掉比如为什么Linux上复制Windows库会出现表不存在、MYISAM和InnoDB到底该怎么选、redo log和doublewrite是干嘛的、锁表了怎么定位。内容偏实操尽量说人话适合所有正在用MySQL的人参考。1. 大小写规则不是“自动忽略”而是分对象分层决定很多人在网上搜“mysql自动忽略大小写”这类问题其实MySQL对大小写的处理并不是一个开关全局搞定而是分对象、分层级的。表名、库名、列名、别名、字符串内容对这些对象的大小写敏感度完全不一样。搞清楚这张表你基本就能避免绝大多数大小写引发的低级事故。1.1 lower_case_table_names三个值代表三种命运涉及库名和表名大小写最核心的参数就是lower_case_table_names它就三个取值但三种命运天差地别。0区分大小写按你建表时的名字原样存储和比较。Linux 上默认就是0。1不区分大小写建表时无论你写大写还是小写最终存储时都会被转成小写。Windows 上默认是1。2存储时保留你写的大小写但比较时不区分大小写。macOS 上默认是2。为什么会有这种差异根源在底层文件系统。Linux 主流的 ext4、xfs、btrfs 这些文件系统本身区分大小写所以 MySQL 在 Linux 上编译时默认就按0来跑库名和表名直接对应物理目录和.ibd文件Test 和 test 是两个完全不同的库。而 Windows 的 NTFS 和 macOS 默认文件系统不区分大小写macOS 可以通过磁盘工具做成区分大小写但默认不是所以客户端默认就用1或2避免因文件系统无法区分同名不同大小写的文件而出错。这里必须重点提醒lower_case_table_names最好在数据库初始化MySQL 8.0 之前在my.cnf里mysqld --initialize之前配好或者初始化后、首次启动前配好时就确定下来中途不要改。改这个参数的代价极大尤其是从 0 改成 1MySQL 在启动时会扫描整个数据目录要把所有大写表名和库名转成小写再重建数据字典表一多那种迁移基本等于做一次大手术。更关键的是如果 InnoDB 的数据字典里已经记录了大写表名而数据目录里的文件被改成了小写启动时可能直接报错或者出现“表不存在”严重的会打不开库。我个人的建议是除非你有特殊需求比如要兼容老应用里大小写混用的表名否则在 Linux 上部署时直接把lower_case_table_names1写在配置里再初始化统一小写命名。这样做的好处是跨平台迁移时不会出问题也避免开发在 Windows/Mac 上建了UserInfo到 Linux 上SELECT * FROM userinfo直接报错这种尴尬。用一条命令就能确认当前值SHOW VARIABLES LIKE lower_case_table_names;顺便说一句如果你是用 Docker 跑 MySQL同样要在容器第一次初始化数据目录前通过command: --lower-case-table-names1或者挂载配置方式提前设置否则容器起来之后再改麻烦程度跟在物理机上改没有区别。1.2 库名、表名、列名、别名的敏感度差异列名、索引名、别名、存储过程和函数名这些名字在 MySQL 里统一是不区分大小写的不管你在 Linux 还是 Windows 都一样。所以SELECT ID FROM user;和select id from user;都能正常执行列名写成Id还是id没有影响。但库名和表名就不一样了它们受lower_case_table_names参数控制。在 Linux 默认参数为0的情况下test和Test是两个完全不同的库user和User是两张完全不同的表。这一点非常容易在开发和线上环境不一致时出错。比如开发机是 Windows写 SQL 时表名随手写成Order代码里别的地方又写成order本地跑得好好的代码一发到 Linux 线上直接报Table db.order doesnt exist。其实不是表不存在是大小写对不上。另外一个容易被忽略的是导出导入场景。你用 mysqldump 从 Windows 导出的备份文件里表名可能保留了大写Windows 默认 lower_case_table_names1 时导出内容其实是小写但如果你在 Windows 上手动改成2就可能保留大写导到 Linux 上执行时如果目标库里只有小写表名就会创建出另一个不同名的表非常混乱。反过来从 Linux 导出到 Windows 一般问题不大但最稳妥的做法还是全局统一小写命名省得折腾。需要特别注意的是临时表的大小写规则和普通表一致同样受该参数影响。曾经遇到过一个案例存储过程里创建了一张临时表tmp_Data后续查询写成了tmp_data在 Windows 上跑了一两年都没问题迁到 Linux 后这个存储过程开始随机报错“表不存在”。排查了半天发现就是大小写问题临时表名和查询名大小写不一致在 Linux 默认规则下被当成了两张表。1.3 字符串比较大小写归排序规则管说完对象名再来说字符串内容的大小写。字符串比较是否区分大小写跟lower_case_table_names没关系它由表的排序规则collation决定。排序规则名里通常带_cicase insensitive不区分大小写、_cscase sensitive区分大小写或_bin按二进制字节比较必然区分。MySQL 8.0 默认字符集是utf8mb4默认排序规则是utf8mb4_0900_ai_ci这个_ci意味着你默认情况下WHERE name mysql和WHERE name MySQL结果是一样的。很多人在这个问题上产生误区以为“MySQL 命令自动忽略大小写”其实不是只是默认排序规则不区分而已。如果你需要严格区分比如用户名、验证码、订单号这类字段有几种做法第一建表时单独指定排序规则CREATE TABLE user ( username VARCHAR(50) COLLATE utf8mb4_bin, ... ) ENGINEInnoDB;第二查询时临时指定排序规则SELECT * FROM account WHERE username Admin COLLATE utf8mb4_bin;第三用二进制比较运算符SELECT * FROM account WHERE BINARY username Admin;这里有个坑要提醒如果唯一索引列使用默认的_ci排序规则那么插入admin和Admin会被认为是重复键直接报Duplicate entry。这是个高频问题经常有人莫名其妙问“为什么我插不进去明明字符串不一样”。遇到这种问题优先检查列的 collation而不是怀疑索引坏了。还有一点MySQL 8.0 里utf8mb4_0900_ai_ci比老版本的utf8mb4_general_ci更智能对许多字符的处理更符合 Unicode 标准但也意味着某些旧环境下被认为“不同”的字符在新规则下可能被认为是“相同”造成比较结果变化。所以迁移时如果排序规则变了最好对字符字段做一次针对性测试。1.4 迁移和部署中的大坑大小写问题的高发场景几乎都集中在“迁移”和“部署环境切换”。我在实际工作中见过太多事故大多数可以归为以下几类第一类Windows 开发Linux 生产。开发本地表名大小写混用代码里查询语句大小写不统一一到 Linux 就报“表不存在”。解决思路从项目一开始就规定表名、字段名一律小写SQL 关键字可以大写但表名列名必须小写这个规范要写进团队开发文档。第二类利用 binlog 做主从复制主库 Windows 从库 Linux。如果主库上建立了大写表名binlog 里记录的事件会带着原大小写名称从库在 Linux 上执行时因为 lower_case_table_names 不同可能出现找不到表的复制错误。这个问题比较隐蔽因为复制动作是后台执行的报错不显眼等发现问题时主从已经差了一大截。第三类初始化后修改 lower_case_table_names。前面说过这个参数初始化以后尽量别动。如果真改了一定要先挨个检查库表名大小写是否一致提前用 SQL 查 information_schema找出所有包含大写字母的表和库规划好转换脚本再动手。第四类Docker 部署时忽略了初始化参数。拉镜像起来就是默认参数等业务跑起来发现大小写不对又不敢直接改只能重新初始化数据目录。所以在第一次启动前把lower_case_table_names写进挂载的 my.cnf一步到位。2. 存储引擎全景从默认选型到冷门引擎存储引擎比你想象的更重要它直接决定了数据怎么存、怎么读、怎么锁、怎么恢复。MySQL 的插件式存储引擎架构让它在不同场景下可以灵活选择但这么多引擎怎么选很多人其实是懵的。下面把主流引擎从头到尾捋一遍。2.1 InnoDB 为什么能当默认一哥InnoDB 从 MySQL 5.5 开始成为默认存储引擎8.0 里几乎是绝对主力原因很简单它把事务、崩溃恢复、并发控制这些能力都做全了。InnoDB 支持 ACID 事务commit 和 rollback 是真的能保证数据一致性的。它支持行级锁写操作只锁涉及的行高并发场景下不会像表级锁那样一写全表堵死。它通过 MVCC多版本并发控制实现了读写不互斥读不会阻塞写、写不会阻塞读这对于互联网应用来说太重要了。它还支持外键约束在需要关系完整性保证的系统里外键是硬需求。最关键的是崩溃恢复能力。InnoDB 有 redo log、undo log、doublewrite buffer 这一整套机制即使数据库突然宕机或者服务器断电重启后依然能把已提交事务恢复把未提交事务回滚不会出现数据文件损坏到不可用的程度前提是硬件没坏。这一点 MyISAM 完全做不到也是我强烈建议大家不要再用 MyISAM 做业务表的根本原因。InnoDB 的表结构分两部分存.frm文件在 8.0 之前存放表结构定义8.0 引入了数据字典data dictionary后表结构元数据统一存放到系统表空间普通用户基本感知不到变化数据本身存在.ibd文件独立表空间或共享表空间里。默认是每个表一个独立表空间方便单独备份和回收空间。2.2 MyISAM能查能写但请让它退休MyISAM 是 MySQL 5.5 之前的默认引擎它的优点是查询快、占用空间小、支持全文索引但它的缺点在高并发和故障场景下非常致命。首先是表级锁。MyISAM 写入时会对整张表加锁读和写互斥意味着任何时刻只有一个会话在修改表其他会话即使是读也要等锁。这在插入频繁、更新频繁的业务表上会让延迟迅速拉高。所以“MySQL 锁表”问题里MyISAM 的锁比 InnoDB 的锁更容易出现也更容易拖垮业务。其次是没有事务。中途断电或者执行到一半出错已经写入的数据就留下来了无法回滚。曾经有过一个场景凌晨跑批量更新本来要更新一万行结果 SQL 条件写错MyISAM 表咔咔改了一半发现不对想 rollback对不起不支持只能从备份恢复那一晚上就这么没了。再就是崩溃恢复极差。MyISAM 表对异常关闭很敏感最常见的就是“Table is marked as crashed and should be repaired”报错只能用REPAIR TABLE或者 myisamchk 去修而且修复不保证数据不丢。它在断电后出现索引损坏的概率比 InnoDB 高得多。那 MyISAM 还有没有存在的意义我的结论是在 MySQL 8.0 里基本没有。如果你需要只读历史数据或者做数据仓库的底层表更优先考虑使用只读副本或归档引擎而不是把宝押在 MyISAM 上。8.0 里 MyISAM 连分区表支持都被移除了官方态度已经很明确。老项目里如果有 MyISAM 表建议尽快用ALTER TABLE t ENGINEInnoDB;转换线上转换建议在低峰期做转换过程会重建表产生大量 IO 和锁。2.3 内存表与其他特殊引擎MEMORY 引擎也叫 HEAP把数据存在内存中读写速度极快但服务重启数据就全部消失。它适合做临时数据缓存、配置汇总、实时统计的中间表但绝对不适合放核心业务数据。另一个限制是它只支持表级锁写入并发一高照样堵而且行数太多会占用大量内存可能把服务器内存吃爆。MySQL 8.0 内部临时表已经改用 TempTable 引擎但 MEMORY 依然可以被显式指定使用只是我的建议是能不用就不用实在要缓存数据用 Redis 不香吗。ARCHIVE 引擎适合做日志归档表它只支持 INSERT 和 SELECT不支持 UPDATE、DELETE也不支持索引。优点是压缩比高同样数据占用的磁盘空间比 InnoDB 小很多。CSV 引擎可以直接把数据映射到 CSV 文件适合做数据交换比如从外部系统导入数据后直接查询但不要指望它在性能和事务上有什么表现。BLACKHOLE 引擎比较特殊所有写入的数据都直接丢弃但 binlog 会正常记录所以常被用在复制架构里做分发中继或者用来验证复制链路。8.0 还有一个比较重要的变化系统表全部换成了 InnoDB彻底摆脱了 MyISAM。所以在 8.0 环境中你已经没必要关心 MyISAM 对统计信息、权限表的影响了。2.4 选型策略与决策参考选引擎不是拍脑袋核心看你的业务对事务、并发、恢复、容量这几件事的敏感程度。这里给一个简化版的决策思路有事务需求或者并发写比较多或者数据丢了会出大事一律 InnoDB。纯只读不要求事务对空间敏感可以用 ARCHIVE日志型冷数据或者干脆用只读库。计算中间结果、实时统计这种临时数据用 MEMORY 或临时表重启丢就丢不心疼。需要跨系统交换数据CSV 引擎可以做短平快的方案但不适合长期持有。任何新业务默认 InnoDB不要犹豫。我用过很多年的一个小经验选引擎之前先问自己一个问题“如果这台机器今晚断电我能不能接受这个表丢最近几秒钟的数据或者需要多长时间恢复”如果你心里没底就用 InnoDB它的崩溃恢复能力能帮你兜住大部分风险。3. InnoDB 核心机制实操复盘很多人用 InnoDB 只知道它支持事务但真要排查问题的时候对崩溃恢复、锁等待、慢查询这些现象背后的机制了解不深就会很被动。这一节我带大家把 InnoDB 的几个关键机制过一遍都是日常 DBA 和开发最容易碰到的点。3.1 聚簇索引与二级索引为什么主键要选对InnoDB 表的数据本身是一棵聚簇索引树BTree叶子节点直接存储整行数据而聚簇索引的键就是主键。如果没有显式主键InnoDB 会找一个非空唯一索引来当聚簇索引如果没有合适的它会生成一个隐藏的 ROW_ID 做聚簇索引。这带来一个非常重要的事实主键的物理组织方式决定了数据在磁盘上的排列顺序。所以主键的选择不是随便的。最好用自增整型、有序 UUID 等趋势递增的列做主键这样新插入的行基本都追加在叶子节点的最右侧不容易触发页分裂。如果用随机字符串做主键新数据会随机插入到索引树的各个位置频繁触发页分裂、页重排写入性能会明显下降表空间碎片也会增多。二级索引的叶子节点存储的是主键值而不是行指针。这意味着通过二级索引查询时如果 select 的列不在索引里就要根据主键值回表查一次聚簇索引。这也是为什么覆盖索引能大幅提升查询性能——覆盖索引让 select 的字段都在二级索引里省掉了回表。实操中看一条 SQL 是否高效用 EXPLAIN 看key列是否用了正确的索引看Extra列有没有Using index condition、Using where以及估算的rows是否合理。这里多提一句热词里的mysql explain 详解八个字的核心看 type、看 key、看 rows、看 Extra。如果 type 出现 ALL说明在做全表扫描大概率要优化。3.2 redo log 与 undo log崩溃恢复和 MVCC 的根InnoDB 的写入不是直接改磁盘上的数据文件而是先写 redo log再更新内存缓冲池里的页最后根据刷盘策略把脏页落盘。这就是 WALWrite-Ahead Logging机制。份日志记录物理层面的“对某个页做了什么修改”数据文件即使没来得及刷新重启后也能靠 redo log 把已提交事务的修改重放出来。redo log 性能非常关键因为它属于顺序写比随机写数据文件快几个数量级。MySQL 8.0.30 之后redo log 文件从原来的ib_logfile0、ib_logfile1改成了#innodb_redo目录下带编号的文件而且支持自动调整数量和大小一般不用手动干预。undo log 则相反它记录的是逻辑上的“旧值”支撑事务回滚和 MVCC。当你要回滚一个事务时InnoDB 通过 undo log 把变更的逆向操作执行一遍当一个长时间运行的事务看不到其他事务未提交的数据时也是通过 undo log 构建老版本快照。8.0 里 undo log 放在独立的 undo 表空间支持自动截断回收缓解了老版本里 undo 文件无限膨胀的问题。一个高频事故是“history list length 过高”本质是事务一直不提交旧版本数据无法清理undo 越来越大解决思路是尽快提交事务、避免大事务里做大量 DML。3.3 双写缓冲与 change buffer双写缓冲doublewrite buffer是 InnoDB 一个容易被忽略的恢复保护机制。它解决的是“部分页写入”问题如果数据库正在写一个 16KB 的页写到一半断电磁盘上的这个页就是半个新页半个旧页redo log 也无法恢复它因为物理页已经损坏。InnoDB 的策略是先把页复制到 doublewrite buffer共享表空间里的一块区域再写数据文件。如果发生半页写入损坏InnoDB 可以从 doublewrite buffer 恢复。这个机制对数据安全非常重要代价是每次刷脏页多了一次写但相比数据损坏带来的灾难这个开销完全值得。change buffer之前叫 insert buffer是另一个优化点。当二级索引页不在缓冲池里时对二级索引的写操作不会立刻去修改索引页而是先记录在 change buffer 里等后续需要读取该页或者系统空闲时再合并到索引页中。这样可以减少随机 IO显著提升非唯一二级索引较多场景下的写性能。但要注意如果二级索引特别多且数据量极大change buffer 本身也可能膨胀需要结合缓冲池大小一起调优。3.4 刷盘策略取舍innodb_flush_log_at_trx_commit是决定事务提交时 redo log 怎么落盘的参数三个取值影响了“性能”和“数据安全”的平衡1每次事务提交redo log 必须刷到磁盘才能返回。最安全最多丢失 0 个已提交事务但单次提交延迟相对最高。0每秒刷一次磁盘事务提交时只在内存写。性能最好但数据库进程崩溃或断电时最近 1 秒内已提交的事务可能丢失。2每次事务提交把日志写入操作系统缓存每秒由操作系统刷到磁盘。性能介于两者之间断电最多丢 1 秒但 MySQL 进程崩溃不会丢因为 OS 还没刷盘。我的建议是正经业务库用1不要抠这个性能如果你做的是可以容忍少量丢失的批处理或者日志采集可以调成2换取吞吐0尽量别碰尤其是跨机房、异地多活的系统里丢一秒数据可能引发严重不一致。3.5 EXPLAIN 看引擎执行计划排查 SQL 慢、锁等待、全表扫描这类问题第一步永远是看执行计划。举一个实际例子EXPLAIN SELECT * FROM orders WHERE order_no 202401010001;执行计划里重点看几个字段type访问类型从好到差大致是 const、eq_ref、ref、range、index、ALL。ALL是全表扫描必须警惕。key实际用到的索引。如果为 NULL说明没走任何索引。rows预估扫描行数数值越大潜在开销越大。Extra出现Using filesort文件排序、Using temporary临时表往往是性能重灾区。filtered5.7 之后出现表示 Server 层应用 WHERE 条件后剩余行的比例值越小说明扫描的有效率越低。如果一张表已经加了索引但 type 还是 ALL先看条件字段的类型和字符集是否一致。字段类型不一致会导致索引失效比如 varchar 字段用整数去查字符集不一致也会导致索引失效典型坑就是一张表用 utf8mb4另一张用 utf8mb3join 时索引生效不了因为排序规则不同没法直接比较。MySQL 8.0 还提供了EXPLAIN ANALYZE它会实际执行 SQL 并返回各阶段的执行时间和行数比普通 EXPLAIN 的估算值更有参考价值。语法很简单EXPLAIN ANALYZE SELECT * FROM orders WHERE order_no 202401010001;注意这只适合在测试或低峰时使用因为它是真的会执行查询的。4. 常见问题与排查技巧收录最后把我在群里、工单里见过的高频问题汇总一下配上排查思路希望能帮你少走弯路。4.1 大小写引发的“表不存在”现象迁移到 Linux 后应用报ERROR 1146 (42S02): Table mydb.userinfo doesnt exist但SHOW TABLES里明明有UserInfo这张表。排查步骤确认当前参数SHOW VARIABLES LIKE lower_case_table_names;。如果返回 0基本就是大小写不匹配。查看实际表名SELECT table_name FROM information_schema.tables WHERE table_schemamydb;。确认应用连接库时的大小写是否与建表一致。如果lower_case_table_names0且你希望不区分大小写修改my.cnf并重启但要注意修改后的影响特别是已经有大量大写表名的库。更稳妥的做法是统一应用与建表语句的大小写风格。这里给的最终建议是新环境初始化时直接lower_case_table_names1然后所有建表语句里表名小写。如果你已经踩坑且表并不多可以用RENAME TABLE UserInfo TO userinfo;逐个改表很多的情况建议写脚本批量处理并在改完后立刻做一次全量mysqldump备份。4.2 锁表定位三板斧现象业务报“锁等待超时”错误码ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction或者SHOW PROCESSLIST里大量Waiting for table metadata lock、Waiting for table lock。排查三板斧第一查看当前正在执行的事务和持锁情况SELECT * FROM performance_schema.data_locks;重点看 LOCK_TYPE、LOCK_MODE、LOCK_STATUS、LOCK_TABLE。第二查锁等待关系SELECT * FROM sys.innodb_lock_waits;这个视图能直接告诉你谁在等谁的锁还能看到阻塞和被阻塞的 SQL。第三检查标准 kill 掉阻塞源头SHOW PROCESSLIST;找到异常 Sleep 很久但持锁的连接或者长时间没有 commit 的长事务直接 KILL 对应线程 ID。但注意KILL 之前最好确认事务来源盲杀可能误伤正在跑核心业务的连接。另外一个常见误操作事务里先 SELECT 加锁再去做外部接口调用或批量更新中间耗时太长锁一直不释放导致后续请求全部堆积。这类问题不是靠调innodb_lock_wait_timeout能根治的核心是缩短事务时间、减少交互式事务。在 InnoDB 中还有一个高频陷阱UPDATE或DELETE的 WHERE 条件不走索引时InnoDB 会对扫描到的所有行加锁甚至相当于把整表锁住因为 InnoDB 的行锁是建立在索引记录上的扫描不通过索引就退化为锁全表。所以排查锁问题时顺手 EXPLAIN 一下写语句的 WHERE 条件看是否用了索引很多“锁表”就是这么造成的。4.3 检查表状态与修复MyISAM 表坏了报Table is marked as crashed可以用CHECK TABLE tablename; REPAIR TABLE tablename;但如前面所说MyISAM 修复属于补救数据完整性没法百分百保证。InnoDB 表如果出现页损坏直接REPAIR TABLE并不总是有效更常见的做法是通过备份恢复或者用innodb_force_recovery强制启动然后导出数据。在 my.cnf 里临时加innodb_force_recovery1然后启动 MySQL用 mysqldump 把损坏表数据导出来再重建表导回去。innodb_force_recovery从 1 到 6 等级递增等级越高越激进一般先从 1 试起能读出来先读不要一上来就设 6那样 InnoDB 可能会跳过很多恢复逻辑导致更多数据不可读。导完数据后记得把参数去掉再正常启动。4.4 高频问题速查表现象常见原因排查命令/处理ERROR 1146表不存在lower_case_table_names 与建表命名不一致或表确实未建SHOW TABLES; 检查 information_schemaERROR 1205锁等待超时长事务未提交、漏索引导致锁范围扩大sys.innodb_lock_waits; 优化 WHERE 索引Table is marked as crashedMyISAM 表损坏或异常关闭CHECK TABLE; REPAIR TABLE建议转 InnoDBERROR 2002 (HY000)无法连接 socketmysqld 未启动、socket 路径不对、权限问题查看 error log;netstat -lnp确认端口; 确认 my.cnf socket 路径同一字段插不进重复值列使用_ci排序规则大小写被认为是重复SHOW CREATE TABLE; 改_bin排序规则EXPLAIN 显示 ALL 全表扫描索引失效、类型/字符集不一致检查字段排序规则、索引设计更新子查询报错MySQL 对同一张表 UPDATE 子查询的限制用临时表包一层或改用 JOIN 写法不过在8.0下也需要注意派生表合并规则顺带说一下速查表里的 UPDATE 子查询。老版本 MySQL 里UPDATE t SET col (SELECT ... FROM t ...)这种写法经常报错因为不允许同时从目标表中进行子查询。8.0 虽然部分场景放宽了但同表更新子查询依然有不少限制。最常见的绕过方式是用派生表或者提前把数据查出来放进变量。这个坑虽然不是大小写和引擎直接引发的但在开发环境里遇到得比较多所以放进速查表里提醒一句。最后再分享一个我自己的习惯每次建库建表前我都会在脑子里过一遍三件事——字符集用什么、大小写参数怎么定、表用什么引擎。字符集选不好会导致乱码和索引失效大小写参数没想清楚会在迁移时一夜白头引擎选错早晚会遇到事务和恢复的噩梦。这三件事看起来基础但它们决定了数据库往后几年的稳定性。你现在花五分钟想清楚胜过以后花五个小时去救火。