事务隔离级别选错是性能瓶颈主因：默认用READ COMMITTED，仅强一致场景升REPEAtable READ或SERIALIZABLE；关外键可提速3–5倍但需校验兜底；UNIQUE索引并发冲突应前置缓存拦截；读写分离下关键读强制走主库或带ID查主库。
事务隔离级别选错直接拖慢查询
多数性能问题不是因为 sql 写得差，而是 READ COMMITTED 用成了 SERIALIZABLE。后者在 postgresql 或 SQL Server 中会加范围锁或序列化执行，一个慢查询可能卡住整张表的写入。
实际建议：
- 默认用
READ COMMITTED（PostgreSQL/oracle 默认，mysql InnoDB 的 RR 实际是快照读，但注意幻读） - 仅当业务明确要求“两次读必须完全一致”（如财务对账）才升到
REPEATABLE READ，且要配select ... for UPDATE显式加锁，避免隐式锁升级 -
SERIALIZABLE留给极少数强一致性场景，上线前必须压测——它在高并发下吞吐常降 50%+，不是加索引能救的
外键约束 vs 批量导入速度
开外键时，每条 INSERT 都要查父表、维护索引、触发约束检查。10 万行数据批量导入，关外键可能提速 3–5 倍；但代价是：如果应用层没兜底校验，脏数据会静默入库。
折中做法：
- etl 或离线任务：临时
SET FOREIGN_KEY_CHECKS = 0（MySQL）或ALTER TABLE ... DISABLE TRIGGER ALL（PostgreSQL），导入完再CHECK CONSTRaiNT - 在线服务：保留外键，但把关联校验从数据库下沉到应用层缓存（如用 redis 缓存常用
user_id → status），减少实时查库 - 绝不跳过校验——哪怕关外键，也要在导入后跑
SELECT count(*) FROM child WHERE parent_id NOT IN (SELECT id FROM parent)快速扫一遍
唯一索引导致 INSERT 超时失败
UNIQUE 索引本身不慢，但并发插入相同值时，数据库要等前一个事务释放锁才能报错，而不是立刻返回冲突。在高并发注册场景，用户可能卡 2 秒才看到“用户名已存在”。
解决思路不是删索引，而是提前拦截：
- 应用层先查缓存（如 redis
EXISTS user:alice），命中则直接拒绝，不走 DB - DB 层用
INSERT ... ON CONFLICT DO NOTHING（PostgreSQL）或INSERT IGNORE（MySQL），避免锁等待，但注意：这类语句不返回影响行数，需额外SELECT确认是否真插入成功 - 如果必须强一致（如发券防超发），用带
FOR UPDATE的SELECT加行锁，但务必控制事务粒度——别在锁住的行上做 http 调用
读写分离后主从延迟引发数据不一致
从库延迟 200ms 是常态，不是故障。如果用户刚提交订单就跳转到“我的订单页”，而该页读从库，很可能查不到刚下的单。
不能靠“等延迟降下来”——延迟不可控。真实可行的方案：
- 关键路径强制读主库：
/*FORCE_MASTER*/ SELECT * FROM orders WHERE user_id = ?（部分中间件支持注释路由） - 写后立即读场景，用“写后带 ID 查询”代替全量刷新：比如下单后返回
order_id，前端直接GET /orders/{id}，后端用这个 ID 查主库（ID 查询走主键索引，压力小） - 接受短暂不一致的页面（如商品浏览量），加
MAX_STALENESS = 5s控制延迟容忍阈值，超时自动切主库
一致性不是开关，是光谱。最危险的不是选低隔离级别，而是没意识到某次 SELECT 正在读一个 3 秒前的快照，而业务逻辑却假设它是实时的。