Database

核心用法

Database Gotchas 是一套面向生产环境的数据库运维与架构设计知识库，聚焦关系型数据库（PostgreSQL、MySQL 为主）在高并发、大规模场景下的常见陷阱与应对策略。内容涵盖六大维度：连接管理、事务控制、Schema 变更、备份恢复、复制架构、查询优化与数据完整性。

核心用法体现为问题-风险-对策三段式结构。例如连接池章节明确指出无上限连接导致应用静默挂起，建议设置 max_connections 并监控池使用率；Serverless 场景下每调用新建连接的问题，则推荐使用 RDS Proxy 或 PgBouncer 作为连接池代理。事务章节强调 MVCC 膨胀、快照隔离、死锁预防等深度话题，给出显式 BEGIN/COMMIT、一致锁序、SELECT FOR UPDATE 等具体代码级建议。

Schema 变更部分尤为实用，针对 MySQL/PostgreSQL 旧版本添加带默认值列会重写全表的问题，提供 NULL 默认→回填数据→修改默认的三步安全流程；索引创建锁表问题则给出 Postgres 的 CONCURRENTLY 与 MySQL 8+ 的 ONLINE 语法对照。

显著优点

1. 生产实战经验密集：所有建议均来自真实故障场景（如 Lambda 冷启动连接风暴、复制延迟导致脏读、大表 COUNT(*) OOM 等），非理论堆砌。
2. 跨数据库对照：同时覆盖 PostgreSQL 与 MySQL 的差异实现（如 MVCC 清理、在线 DDL 语法），便于团队技术选型。
3. 操作可落地：每个陷阱均附带具体命令或配置参数（如 ANALYZE 时机、pg_dump 一致性快照、UTC 存储规范），可直接纳入 Checklist。
4. 云原生适配：专门针对 Serverless（Lambda）、托管 RDS、读写分离架构给出连接池代理、副本一致性校验等云时代方案。

潜在缺点与局限性

1. 深度依赖关系型数据库：内容几乎完全围绕 PostgreSQL/MySQL 展开，对 MongoDB、Redis、ClickHouse 等 NoSQL/NewSQL 覆盖为零。
2. 版本敏感性强：部分建议（如 MySQL 8+ ONLINE DDL）对旧版本不适用，需读者自行核对数据库版本。
3. 缺乏量化阈值：如"单表超 100M 需分片"仅为经验值，实际阈值受硬件、查询模式、数据分布影响较大。
4. 无故障演练脚本：仅文字描述风险，未提供可运行的 Chaos Engineering 或压测复现案例。

适合人群

• 后端开发工程师：使用 ORM 但需理解 N+1 查询、连接池耗尽等底层机制
• DBA/SRE：负责 Schema 变更评审、复制延迟监控、备份策略制定
• 架构师：设计分片策略、评估 Serverless 数据库方案、制定数据一致性规范
• 技术负责人：建立团队数据库操作 Checklist，规避生产事故

常规风险

• 误操作数据丢失：如未验证备份可恢复性、未配置 WAL 保留导致 PITR 失效
• 性能回滚困难：在线 DDL 失败或复制中断可能导致长时间锁表
• 隐性成本：连接池代理（RDS Proxy）、跨区域复制、备份存储均产生额外云费用
• 时区/精度陷阱：UTC 存储规范、DECIMAL 替代 FLOAT 等若未严格执行，可能引发跨系统数据不一致

Database Gotchas 综合评估

核心用法

本 Skill 是一份面向数据库设计与运维的最佳实践参考手册，以 Markdown 文档形式呈现，无可执行代码。内容按主题组织为八大板块：连接管理、事务处理、Schema 变更、备份恢复、复制机制、查询模式、数据完整性与扩展限制。每条建议均针对真实生产环境中的常见陷阱，提供具体可行的规避方案。

典型使用场景：

• 设计新系统时预判架构风险（如分片策略、连接池配置）
• 排查线上问题时快速定位根因（如死锁、复制延迟、慢查询）
• 制定 Schema 变更 SOP，避免锁表或应用中断
• 面试准备或团队技术分享的知识库

显著优点

1. 覆盖面广：从开发层（ORM N+1 问题）到运维层（WAL 保留策略），贯通数据库全生命周期
2. 实战导向：每条建议均指向具体故障模式，如 "旧版 MySQL 添加含默认值的列会重写全表"
3. 跨数据库兼容：同时涵盖 Postgres、MySQL 特性差异，避免单一技术栈局限
4. 零依赖零风险：纯文档型 Skill，无需担心代码漏洞、数据泄露或供应链攻击

潜在缺点与局限性

1. 无交互性：静态文本无法根据用户实际 Schema 或查询计划给出个性化建议
2. 版本敏感：部分建议依赖特定数据库版本（如 MySQL 8+ 的 ONLINE DDL），需用户自行核实当前环境
3. 深度有限：高级主题（如分布式事务 2PC、共识协议细节）仅点到为止，需配合专业书籍使用
4. 无自动化：不提供索引推荐、慢查询分析等工具化能力

适合人群

• 后端/全栈开发者：预防日常开发中的事务边界、N+1 查询等典型问题
• DBA / SRE：制定变更规范、容量规划与故障预案
• 技术负责人：评估团队数据库技术债，建立运维 Checklist

常规风险

• 误操作风险：文档建议需结合实际数据量、版本、负载验证，盲目执行可能引发生产事故
• 知识过时：数据库版本迭代快，建议定期对照官方文档复核关键条目
• 认知偏差：纯文本形式可能让用户低估某些操作的破坏性（如大表 ALTER TABLE 的锁影响）

来源与可信度

维护者为个人开发者（ivangdavila），属社区贡献型内容。虽无企业背书，但技术要点与 Postgres/MySQL 官方文档及业界主流实践一致，可作为可靠参考。