sql数据一致性依赖acid事务、约束（主键/外键/check/not NULL）、合理索引及审慎的触发器使用，而非应用层校验。
SQL数据一致性主要靠数据库的ACID特性支撑，核心是事务机制与约束设计。不依赖应用层“手动校验”，而是让数据库自己守住底线。
利用事务保证操作原子性
多个写操作必须同时成功或同时失败，避免中间状态残留。比如转账：扣减A账户、增加B账户，二者必须在一个事务中完成。
- 显式使用 BEGIN TRANSACTION / COMMIT / ROLLBACK 控制边界
- 避免长事务——锁持有时间过长会阻塞并发，也增加回滚成本
- 注意隔离级别影响：READ COMMITTED 可防脏读，但幻读需靠 select … for UPDATE 或更高隔离级+合理索引
用约束强制数据合法
让非法数据根本插不进去，比事后修复更可靠。
- 主键/唯一约束 防止重复标识（如用户手机号、订单号）
- 外键约束 确保关联存在（如订单必须对应真实用户），ON delete CASCADE 或 ON DELETE restrict 按业务选行为
- CHECK 约束 控制字段取值范围（如 age >= 0 AND age
- NOT NULL + default 减少空值歧义，尤其对参与计算或关联的字段
合理设计主键与唯一索引
主键不只是性能优化手段，更是逻辑一致性的锚点。
- 优先用语义稳定、无业务含义的代理主键（如 BIGINT 自增或 UUID），避免用可能变更的字段（如邮箱、身份证号）作主键
- 对业务强唯一性要求的组合，建唯一索引而非依赖应用判断（如 “商户ID+交易流水号” 必须全局唯一）
- 索引覆盖关键查询条件，减少因查询不准导致的误更新或漏更新
慎用触发器与存储过程
它们能封装一致性逻辑，但也容易隐藏副作用，增加维护难度。
- 仅在约束无法表达的复杂规则下使用（如“每月首单返现”需查历史订单）
- 触发器内避免调用外部服务、长时间计算或跨库写入
- 所有逻辑必须可测试、有日志、失败时明确报错，不能静默忽略
一致性不是靠某一个功能实现的，而是事务、约束、索引、设计习惯共同作用的结果。越早把规则固化到DDL和事务里，后期数据治理成本就越低。