mysql数据完整性依赖innodb存储引擎的约束体系，包括外键、事务acid、唯一索引等；myisam不支持外键和事务，无法保障跨表一致性；需显式指定engine=innodb、建索引、用显式事务、依赖唯一约束而非应用层校验，并慎用级联操作。
MySQL 存储引擎如何通过约束机制保障数据完整性
数据完整性不是靠某个“开关”或单一功能实现的，而是由存储引擎（主要是 InnoDB）与 SQL 层协同执行的一套约束体系。关键在于：只有 InnoDB 支持外键、事务级原子性、行级锁等核心完整性保障能力；MyISAM 不支持外键和事务，无法真正保证跨行/跨表一致性。
实操中必须确认表引擎为 InnoDB，否则即使写了 FOREIGN KEY 语法，MySQL 也会静默忽略（除非开启 foreign_key_checks=1 并显式报错）。
-
CREATE table时显式指定ENGINE=InnoDB，不依赖默认值 - 已有表用
ALTER TABLE t ENGINE=InnoDB转换，注意大表会锁表 - 检查是否生效：
SHOW CREATE TABLE t看输出中是否含ENGINE=InnoDB - 外键列必须有索引（否则创建失败），且被引用列必须是
PRIMARY KEY或UNIQUE
事务 + 原子性：避免部分写入导致的数据不一致
当多个相关操作（如扣库存 + 写订单 + 记日志）需要“全成功或全失败”时，仅靠约束不够，必须包裹在 START TRANSACTION 中。InnoDB 的事务 ACID 特性才是这类业务逻辑的底层支撑。
常见错误是误以为单条 UPDATE 自带事务保护——其实它只是自动开启隐式事务，一旦出错不会回滚其他已执行语句（除非用 autocommit=0 手动控制）。
- 显式事务模板：
START TRANSACTION; UPDATE ...; INSERT ...; COMMIT; - 任何一步失败，必须手动
ROLLBACK，否则连接保持在事务中，可能阻塞后续操作 - 避免长事务：事务持有锁时间越长，冲突概率越高，超时后可能被
innodb_lock_wait_timeout终止
唯一索引与主键：防止重复插入的硬性屏障
应用层做“先查后插”（check-then-act）是典型竞态漏洞。真正可靠的方式是依赖数据库层的唯一约束，让重复插入直接触发 Error 1062 (23000): Duplicate entry 错误。
注意 UNIQUE 约束对 NULL 的特殊处理：多列联合唯一索引中，只要任意一列为 NULL，整行就不参与唯一性校验（即允许多行 NULL）。
- 建表时定义：
UNIQUE KEY idx_email (email)或PRIMARY KEY (id) - 插入失败时捕获
1062错误码，而非检查返回影响行数 - 不要用
INSERT IGNORE掩盖问题——它会静默丢弃冲突行，掩盖业务逻辑缺陷 - 若需“存在则更新”，用
INSERT ... ON DUPLICATE KEY UPDATE，但需明确指定更新字段
外键级联操作的风险与适用边界
ON delete CASCADE 看似省事，实际极易引发意外数据丢失。例如删除一个用户，可能连带清空其所有订单、地址、收藏——而这些关联记录往往需要审计或归档，不能直接物理删除。
更安全的做法是：外键只设 ON DELETE restrict（默认），由应用层显式判断并处理关联数据。
- 级联更新（
ON UPDATE CASCADE）风险较低，适合主键变更极少的场景（如用 UUID 替代自增 ID） - 外键会显著降低大批量写入性能（每次 INSERT/UPDATE 都要校验引用关系）
- 线上表加外键需谨慎：
ALTER TABLE ADD FOREIGN KEY会锁全表，且校验历史数据可能耗时极长
外键和事务的组合看似强大，但真实系统里最常破坏数据完整性的，反而是应用代码绕过约束（比如用 LOAD DATA INFILE 导入时禁用外键检查）、或 dba 为性能临时关闭 foreign_key_checks 后忘记恢复。这些操作不会留下日志痕迹，却让约束形同虚设。