数据库的“一致性”（Consistency）是指数据在事务前后都必须满足预定义的规则和约束，不能出现逻辑上矛盾的中间状态。很多人把一致性简单地等同于事务的 C，但实际上，数据库自身的一致性保障是一套多层次、多机制组合而成的体系。依靠这些机制，数据库能够在很大程度上保证写入的数据是正确的、完整的、符合业务预期的，而不需要应用程序再做一层校验。
理解数据库自身的一致性保障机制，能让你在设计表结构、写 SQL 和调优时更有把握，也能避免大量“脏数据”进入系统的隐患。
17.1.1 实体完整性：主键与唯一约束
最基础的一致性保障就是“每一行数据必须能唯一标识”。这由主键约束和唯一约束来保证。
- 主键约束（PRIMARY KEY）：每个表只能有一个主键，主键列的值必须唯一，且不能为 NULL。InnoDB 会基于主键构建聚簇索引，数据本身按照主键顺序物理存储。当插入相同主键值时，数据库会直接返回
Duplicate entry错误，拒绝写入，彻底杜绝重复数据的产生。
- 唯一约束（UNIQUE KEY）：可以在一列或多列上定义唯一约束，确保同一字段组合不会出现重复值。与主键不同的是，唯一列允许 NULL（多个 NULL 值通常不视作重复）。在实际项目中，通常会将用户名、手机号、身份证号等逻辑上必须唯一的字段设置为唯一约束，而不是只在应用层做校验。数据库兜底远比代码校验可靠，因为代码可能因并发或 bug 而遗漏。
这两种约束是通过 B+ 树索引实现的。插入新数据时，InnoDB 会在相应索引中查找是否存在冲突键值。如果存在就直接报错，整个过程是原子且快速的。依赖约束而非仅仅依赖应用逻辑，是保证数据“物理上干净”的最佳实践。
17.1.2 参照完整性：外键约束
当不同表之间存在父子关系时，外键约束（FOREIGN KEY）可以确保引用的数据一定存在，防止孤立的数据记录。
- 级联操作：定义外键时可以指定
ON DELETE和ON UPDATE的行为，如 CASCADE（级联删除/更新）、SET NULL（置空）、RESTRICT（阻止父表操作）等。这为业务关联数据提供了明确的清理规则，防止出现标记为已删除用户但相关订单仍指向旧用户 ID 的情况。
- 性能与使用争议：外键在并发写入时会带来额外的锁开销，因为更新子表时需要对父表的引用行加锁。所以高并发场景下的核心业务表有时会去除物理外键，转而用应用层保证参照完整性，或者通过定期检查脚本找出孤儿数据。但即便如此，在设计阶段定义外键仍然是一种重要的文档化手段，它能清晰地表达数据模型，很多 DBA 也会在从库中保留外键以辅助数据校验。
对于一致性要求极高的系统（如金融、财务），外键仍是简单直接的保障方式；对于互联网高并发系统，可以权衡后放弃物理外键，但至少要保证逻辑上的外键关系通过代码和监控来维护。
17.1.3 域完整性：数据类型与检查约束
数据库需要确保每个字段的值都在其定义的“域”内，即数据类型合规且可选范围明确。
- 数据类型约束：列定义时指定为
INT就不能写入字符串，指定为DATE就不能写入非法日期。如果 sql_mode 启用了严格模式（强烈建议开启STRICT_TRANS_TABLES），任何试图写入长度超限、值超出范围的非法数据都会直接报错，而不是仅仅截断或警告。非严格模式下，MySQL 会尝试自动转换或截断，可能导致数据悄悄失真，这是很多历史遗留脏数据的根源。
- 检查约束（CHECK）：MySQL 8.0.16 及以上版本完整支持 CHECK 约束，可以在列级别或表级别定义条件，如
CHECK (age >= 0 AND age <= 200)。当插入或更新违反约束的数据时，语句直接失败。这是一种比触发器更轻量的数据合法性校验手段，建议在需要复杂规则时将校验逻辑下推到数据库层面。
- NOT NULL 约束：标记为 NOT NULL 的列不允许空值插入，避免了大量“null 陷阱”。结合默认值的合理使用（如 NOT NULL DEFAULT ''），能有效防止因应用端忘记赋值而出现的空字段。
域完整性的核心思想是 “数据库是最后一道防线”。即便应用层有代码校验，也永远不要假设它们没有 bug。在库内设置类型和检查约束，成本极低，而收益是永久性的数据安全。
17.1.4 原子 DDL 与元数据一致性
在 MySQL 8.0 以前，DDL 操作（如 ALTER TABLE）往往不是原子的：一旦操作中途失败，表结构可能已经部分修改，造成令人头痛的元数据不一致。MySQL 8.0 引入了原子 DDL 特性，将 DDL 相关的数据字典更新和文件操作包装在一个原子事务中。
- 原子化：如果一个 ALTER TABLE 语句因为意外崩溃而中断，数据库重启后会自动回滚该操作，表结构和数据文件恢复到操作前的状态，不会出现残废表。
- 数据字典的集中管理：8.0 将元数据统一存储在 InnoDB 的数据字典表中，取代了原来散落于文件系统的
.frm等文件。这使得元数据的读取和修改都可以通过事务机制来保障一致性，例如同时修改表结构和对该表的查询不会看到中间状态。
从开发者的角度，这让我们可以更放心地在业务低谷期执行 DDL，即使中途出问题，也不至于需要人工介入修复表结构。
17.1.5 事务一致性：ACID 中 C 的真义
ACID 里的 C（Consistency）实际上不是数据库自身独立保证的，它建立在 A、I、D 的基础上，配合用户定义的规则完成。换句话说：如果数据库提供了原子性、隔离性、持久性，并且用户定义了表结构和约束，那么事务就能保证从一个一致状态转移到另一个一致状态。
从数据库自身角度看，以下机制共同构成了事务一致性的底座：
- 原子性：事务要么全做要么全不做，避免只执行了一半而留下非法状态（详见第 6 章）。
- 隔离性：并发事务之间通过 MVCC 和锁机制确保不互相干扰，不会读到对方的中间状态，保证各自视角的数据逻辑完整。
- 持久性：提交后的数据不丢失，结合 Redo Log 的崩溃恢复能力，保证已确认的一致性状态被永久保存。
所以，数据库自身的一致性保障菜单里，约束是“规则”，事务是“执行框架”，二者缺一不可。
17.1.6 触发器的辅助校验（慎用）
触发器可以在数据变更前后插入一段自定义逻辑，理论上也能用于强校验或联动更新，保证某些业务规则不被绕过。比如可以创建一个触发器，在插入订单前检查账户余额是否足够，不足则直接拒绝插入。
但触发器在实际生产环境中用得不多，原因有三：一是它会隐式执行，调试和维护困难；二是会显著增加写入时的开销，容易成为性能瓶颈；三是如果触发器本身写错了逻辑，可能导致所有相关 DML 都失败。所以，除了个别简单场景（如自动更新时间戳），更推荐用 CHECK、约束或应用层逻辑来替代复杂的触发器一致性校验。
17.1.7 实践建议：把规则交给数据库
综合来看，数据库自身一致性保障的本质是 “把规则固化在存储引擎内部，让任何写入都必须经过这些规则校验”。这对于团队协作尤其重要：即使新来的同事在代码里忘记做非空判断，数据库依然能通过 NOT NULL 和严格模式拒绝写入，从源头避免脏数据。
在生产环境中，建议坚持以下习惯：
- 所有表必须显式定义主键，不要依赖 InnoDB 自动生成的隐藏 Row_id。
- 逻辑上唯一的业务字段必须创建唯一约束，如用户昵称、手机号码。
- 字段尽量设置为 NOT NULL 并提供合理的默认值，避免 null 带来的比对陷阱和索引问题。
- 生产环境必须开启严格 sql_mode，至少包含
STRICT_TRANS_TABLES和NO_ZERO_DATE，防止自动截断和非法日期入库。 - 在 MySQL 8.0 中合理使用 CHECK 约束，将简单的数值范围、字符串格式校验下沉到数据库层。
这些做法是零成本或极低成本的，却能让你在半夜时安心很多——至少保证基础的数据质量不会在底层悄悄溃堤。