数据库引擎有哪些坑

数据库引擎（MySQL InnoDB、PostgreSQL、MongoDB、SQL Server 等）在实际使用中“坑”非常多，往往不是语法问题，而是引擎机制、并发模型、存储结构和默认行为导致的。下面按常见数据库引擎分类 + 通用坑来说明，偏实战经验。

一、MySQL / InnoDB 常见坑

1. 事务与锁的坑

• 行锁升级为表锁
  • 索引失效（函数、隐式转换）会导致行锁变表锁
  • 例子：WHERE phone = 13800000000（phone 是字符串）
• 死锁不可完全避免
  • 高并发下即使代码正确也可能死锁
  • 必须做：重试机制 + 固定加锁顺序
• 长事务是灾难
  • 占用 undo log、MVCC 版本链
  • 导致表膨胀、主从延迟

2. 索引的坑

• 最左前缀失效
  • (a,b,c) 索引，WHERE b=1 用不到
• 隐式类型转换
  • 字符串字段用数字查 → 全表扫描
• 覆盖索引误解
  • SELECT * 基本不可能覆盖
• 索引选择性差
  • 性别、状态字段建索引几乎没用

3. 主从复制坑

• 主从延迟
  • 大事务、DDL、从库压力大
• 并行复制限制
  • 同一 schema / 同一事务只能串行
• 半同步复制不是强一致
  • 网络抖动仍可能丢数据

4. 其他坑

• COUNT(*) 在 InnoDB 很慢
• DELETE 大量数据会锁表 + 产生碎片
• ORDER BY RAND() 极慢
• 默认 utf8 不是真正的 UTF-8（应是 utf8mb4）

二、PostgreSQL 常见坑

1. vacuum 机制

• 不 vacuum → 表膨胀
• 长事务会阻止 vacuum
• 默认 autovacuum 可能跟不上写入

2. 事务 ID 回卷（XID wraparound）

• 极端情况会导致数据库“冻结”
• 必须监控 age(datfrozenxid)

3. 锁更“凶”

• DDL 锁非常重
• ALTER TABLE 可能阻塞所有读写

4. 索引

• 表达式索引、部分索引很强，但容易忘
• LIKE 'abc%' 才能用索引（%abc 不行）

三、MongoDB 常见坑

1. 事务支持弱

• 4.0+ 才支持多文档事务
• 分片集群事务代价极高

2. 数据一致性

• 默认 最终一致
• 写可能丢（没配置 write concern）

3. 内存与性能

• 热数据必须进内存
• 索引设计错 → 全集合扫描

4. 文档设计坑

• 无限数组增长 → 性能崩
• 嵌套过深 → 查询困难

四、SQL Server 常见坑

• 默认隔离级别是 READ COMMITTED SNAPSHOT
• 锁升级（行 → 页 → 表）
• 统计信息过期导致执行计划崩
• TempDB 是性能瓶颈点

五、所有数据库引擎的“通用坑”

1. 以为数据库能保证一切

• 唯一索引 ≠ 业务幂等
• 事务 ≠ 高可用
• 主从 ≠ 备份

2. 误用 ORM

• 自动生成烂 SQL
• N+1 查询
• 隐式全表加载

3. 容量与性能误判

• 开发环境快 ≠ 生产快
• 数据量 ×10 后全变样

4. 备份与恢复被忽视

• 有备份 ≠ 能恢复
• 没演练过恢复 = 没备份

六、总结一句话

数据库引擎最大的坑，是“它按自己的规则运行，而你以为是按你的预期运行”。

如果你愿意，可以告诉我：

• 用的是哪种数据库（MySQL / PG / Mongo / 其他）
• 是开发 / 运维 / 架构场景
• 当前遇到的问题（慢查询 / 死锁 / 主从延迟等）

我可以直接给你针对性避坑清单 + 实战建议。