databases

数据库：生产环境配置与运维

配置、调优、设计架构、迁移、备份和审核数据库引擎——涵盖从单节点开发环境到符合 PCI 要求的生产集群。目标是打造正确、高性能、持久可靠的数据库，能够经受故障并通过审计。

目标版本（2026 年 10 月）：

• PostgreSQL 18.6（生命周期结束日期为 2030-11；2026 年 8 月 13 日发布），维护分支：17.11、16.15、15.19、14.24（生命周期结束日期为 2026-11-12——现在就规划从 14 升级）；PostgreSQL 19 RC 1（2026-10-15）仅供测试
• MongoDB 9.0.2（新主版本，2026-09-28 正式发布，生命周期结束日期为 2031-10）；8.0 系列 8.0.34（生命周期结束日期为 2029-10）；8.0.32 修复了 CVE-2026-89099，是 8.0 系列的安全基准版本。快速发布系列仅适用于 Atlas，支持窗口较短——锁定版本前请核实最新信息
• MariaDB 11.8.9（LTS，生命周期结束日期为 2028-06）、12.3.3（LTS，生命周期结束日期为 2029-06）；13.x 滚动发布版每季度正式发布，且在后续版本发布时即结束生命周期——请核实最新信息
• MySQL 8.4.12（LTS；2026 年 8 月 18 日发布）、9.7.3（9.7 LTS 系列；2026 年 8 月 18 日发布）；创新系列的支持窗口较短——请核实最新信息
• Redis 8.10.2；Valkey 9.1.2（9.0 系列为 9.0.6）——锁定版本前请核实最新信息
• SQL Server 2025 RTM + CU9（2026-09-15 发布）
• PgBouncer 1.26.0（修复 CVE-2026-19888/6668/6669）、Pgpool-II 4.7.3、ProxySQL 3.0.11（3.0.9+ 修复 CVE-2026-48772/48773；CVE-2026-48774 影响 4.0 系列，已在 4.0.9 中修复）

此技能涵盖以下领域，具体取决于上下文：

• 配置 - 引擎设置、身份验证、TLS、调优参数
• 架构设计 - 索引策略、分区、规范化、类型选择
• 迁移 - 跨引擎迁移、零停机 DDL、ORM 迁移工具
• 运维 - 备份/恢复、复制、连接池、监控
• 性能 - 查询计划分析、索引优化、清理/维护
• 合规 - PCI-DSS 4.0 加密、审计日志、密钥管理、数据脱敏
• Redis/Valkey 运维 - 缓存或持久化数据分类、内存/驱逐、持久化、 复制、ACL/TLS 和流恢复

适用场景

• 配置数据库引擎（postgresql.conf、mongod.conf、my.cnf、MSSQL 设置）
• 设计或审核数据库架构（索引、分区、类型、约束）
• 规划或执行跨引擎迁移（MySQL -> PostgreSQL 等）
• 制定备份/恢复策略和 PITR
• 配置复制（流式、逻辑、副本集、GTID）
• 调优连接池（PgBouncer、ProxySQL、应用端连接池）
• 分析查询性能（EXPLAIN、慢查询日志、索引使用情况）
• 满足数据库层面的 PCI-DSS 4.0 合规要求（加密、审计日志、访问控制）
• 评估使用托管数据库还是自托管数据库
• 暴露引擎原生指标，并诊断数据库特有的健康状况或查询信号
• 将 Redis 或 Valkey 用作缓存、数据存储、会话存储或流

不适用场景

• 在 Kubernetes 上部署数据库（StatefulSets、PVC、运算符）- 使用 kubernetes
• 通过 IaC 配置托管数据库（RDS、Cloud SQL、Atlas）- 使用 terraform
• 使用 Docker Compose 运行数据库容器 - 使用 docker
• 与数据库相关的 Ansible playbook 和角色 - 使用 ansible
• 应用层面的数据库问题（N+1、事务误用、ORM 陷阱）- 使用 code-review
• SQL 注入检测、代码中的连接字符串密钥 - 使用 security-audit
• 运行迁移的 CI/CD 流水线 - 使用 ci-cd
• 跨服务遥测流水线、仪表板、告警路由或 SLO - 使用 observability
• 其他非关系型引擎（Cassandra、DynamoDB、ClickHouse 等）- 使用相关平台技能或通用指南

---

AI 自检

AI 工具总会犯同样的数据库错误。在返回任何生成的 SQL、架构、迁移或配置前，请根据此列表进行核验：

迁移

• 版本化迁移会检测意外的架构漂移；仅对有意支持重复运行的操作使用保护逻辑
• 添加 NOT NULL 列时包含 DEFAULT 值（或分两步执行：添加可为空的列、回填数据、再改为 NOT NULL）
• 对有实时写入的 PostgreSQL 数据库构建索引时，仅在支持的情况下使用 CONCURRENTLY，并在事务块之外执行；失败后检查是否存在无效索引
• 大表变更分批执行，而非放在单个事务中（避免锁升级和 OOM 风险）
• 迁移向后兼容（旧版应用仍可使用新架构运行）
• 未经用户明确确认，不执行 DROP TABLE 或 DROP DATABASE
• 迁移运行器会记录已应用的版本；可重复运行的运维脚本会收敛到预期状态，并验证已有对象
• 已测试恢复方案：在安全时执行向下迁移；若回退会丢失数据，则记录向前修复或还原方案
• PG 枚举变更在事务块之外使用 ALTER TYPE ... ADD VALUE（PG 12+ 允许在事务中执行，但新值要等事务提交后才能使用——若要立即使用该值，请单独运行此操作）

架构

• 新增时间戳列时使用 timestamptz（PG）、DATETIME2（MSSQL）、DATETIME（MySQL——TIMESTAMP 存在 2038 年问题）
• MySQL 字符集使用 utf8mb4（而非仅支持 3 字节字符的 utf8），PG 使用 UTF8
• PG 10+ 的标识列使用 GENERATED ALWAYS AS IDENTITY，而非 SERIAL（无法绕过）
• 外键显式指定 ON DELETE 行为（不要依赖引擎默认值）
• 所有外键列都建立索引（与 MySQL InnoDB 不同，PG 不会自动创建这些索引）
• 复合索引列顺序遵循：等值列在前，范围列在最后，并按选择性排序

配置

• pg_hba.conf 中不使用 trust 或 md5 身份验证（使用 scram-sha-256）
• MySQL sql_mode 包含 STRICT_TRANS_TABLES（防止静默截断数据）
• 所有连接都强制使用 TLS（而非仅仅“支持” TLS）
• 根据实际工作负载设置 max_connections，而非沿用默认值
• 密码身份验证使用现代哈希方案（PG 使用 SCRAM-SHA-256，MySQL 使用 caching_sha2_password）
• 配置文件中不包含默认密码或示例密码

批量操作

• 批量插入需分块处理——绝不要将无界数组传入单条 INSERT ... VALUES 语句
• 块大小按 floor(max_host_parameters / columns_per_row) 计算，其中宿主参数限制为：PostgreSQL 65,535、MySQL 65,535、SQLite 32,766（默认 SQLITE_MAX_VARIABLE_NUMBER）、MSSQL 2,100
• 应用面向多个后端时，块大小采用所有支持的引擎中最低的限制
• 在原子性重要时，分块写入须置于同一事务中（“先删除再全部插入”始终如此）；否则，确保每个块都可幂等执行，以便失败后继续运行。
• 测试需断言：当行数超过安全分块阈值时，会触发多次插入调用

通用

• 所有 SQL 都使用参数化查询／预处理语句（绝不进行字符串拼接）
• 连接池设置的总和不超过所有应用实例的 max_connections
• 通过实际还原来测试备份策略（备份却不测试还原，就只是寄希望于好运，并非策略）
• 密钥（密码、连接字符串）通过环境变量或密钥管理器注入，而非写入配置文件
• 检查引擎／版本：SQL 语法、索引选项和复制建议与指定的引擎及主版本相符
• 管控数据丢失路径：迁移、删除、重建索引和故障转移均包含备份、试运行、回滚或维护时段方面的指引
• 应用跨领域的 Agent 卫生规范——参见 references/agent-hygiene.md

---

最佳实践

• 在隔离的目标环境中进行恢复演练；验证应用程序的读写、数据一致性、加密密钥访问和 PITR 边界。根据 RTO/RPO 衡量恢复耗时和数据丢失量，然后记录源备份、检查项和清理操作，且不要覆盖在线数据。
• 如果查询模式或延迟要求不同，请分离在线、后台和分析型工作负载。

工作流

步骤 1：确定领域

根据请求判断：

• “配置 PostgreSQL / 调整设置” -> 配置
• “设计架构 / 检查索引” -> 架构设计
• “从 X 迁移到 Y / 添加列” -> 迁移
• “设置备份 / 复制 / 连接池” -> 运维
• “此查询很慢 / 优化” -> 性能
• “PCI 审计 / 加密数据库” -> 合规
• “检查此架构/配置” -> 应用生产环境检查清单 + AI 自检

步骤 2：收集需求

编写 SQL 或配置之前，先确定以下事项。如果用户未说明，请采用所示的合理默认值：

• 引擎和版本 - 不同版本的行为差异很大。默认值：最新稳定版（见上文的目标版本）。
• 部署模式 - 自托管（金属服务器、VM、容器、K8s）还是托管（RDS、Cloud SQL、Atlas）。默认值：除非上下文另有说明，否则假设为自托管。
• 工作负载类型 - OLTP（大量小型事务）、OLAP（少量大型查询）还是混合型。默认值：OLTP。
• 数据量 - 行数、表大小、增长率。默认值：中等（1-100GB）。如果未知，则针对增长进行优化。
• 合规要求 - PCI-DSS CDE？HIPAA？数据分类是什么？默认值：不纳入合规范围（但仍应用安全基线）。
• HA 要求 - RTO/RPO 目标、多可用区、只读副本。默认值：单节点并启用 PITR。
• 现有基础设施 - 当前正在运行什么、使用了哪些 ORM/驱动程序。若可访问，请检查代码库。

步骤 3：构建

遵循下方对应领域的章节。完成前始终应用生产环境检查清单并进行 AI 自检。

构建前阅读 references/build-patterns.md：其中包含查询优化（PostgreSQL、MySQL、MongoDB 执行计划）、锁和死锁诊断、PgBouncer 容量规划以及迁移安全的快速入门模式，还包含任何破坏性操作或会更改生产环境的操作之前必须完成的检查清单。

步骤 4：验证

先检测客户端（command -v psql mongosh mysql sqlcmd）；缺少客户端属于需要报告的缺口，不能算作检查通过。如果检查失败，请修复配置、查询或迁移，然后返回步骤 3。破坏性操作失败后，应停止并重新规划；切勿临时变通后再次尝试。

# PostgreSQL
psql -c "SHOW config_file;"                    # verify config location
pg_isready -h localhost                         # connection check
psql -c "SELECT * FROM pg_hba_file_rules;"     # verify pg_hba.conf
psql -c "EXPLAIN (ANALYZE, BUFFERS) <query>;"  # query plan analysis

# MongoDB
mongosh --eval "db.adminCommand({getCmdLineOpts: 1})"  # verify config
mongosh --eval "rs.status()"                            # replica set health
mongosh --eval "db.collection.explain('executionStats').find({})"

# MySQL / MariaDB
mysql -e "SELECT @@sql_mode;"                  # verify strict mode
mysql -e "SHOW VARIABLES LIKE 'innodb%';"      # InnoDB settings
mysql -e "EXPLAIN FORMAT=TREE <query>;"        # query plan (MySQL 8.0+)

# MSSQL
sqlcmd -Q "SELECT @@VERSION;"
sqlcmd -Q "DBCC CHECKDB ('dbname') WITH NO_INFOMSGS;"  # integrity check

---

引擎路由

• PostgreSQL：SCRAM、连接池器、WAL 或逻辑复制、pg_stat_statements，以及审慎的 vacuum 策略
• MongoDB：副本集健康状况、架构验证、oplog 容量规划，以及避免扇出式文档模式
• MySQL/MariaDB：严格模式、utf8mb4、GTID 或 Galera 方案，以及了解 MySQL/MariaDB 的差异
• MSSQL：内存限制、TempDB 布局、Query Store，以及备份或恢复规范
• Redis/Valkey：区分缓存与持久数据、确保内存/淘汰策略安全、持久化、复制、ACL/TLS 以及流消费者恢复。阅读 references/redis-valkey.md。

---

架构、迁移和性能

• 为实现零停机架构变更，优先采用扩展-收缩模式。
• 复合索引的列顺序仍遵循等值、排序、范围。
• 有意选择租户隔离方案；对 PCI 敏感的共享架构设计需要额外审查。
• 将查询计划审查和监控视为常规运维，而非仅在紧急情况下开展的工作。
• 留意会使 LEFT JOIN 语义失效的 WHERE 子句（筛选外侧表会将其转换为 INNER JOIN——将筛选条件移入 ON 子句或使用子查询）。

主要版本升级

在进行任何 PostgreSQL 主要版本升级之前，请阅读 references/version-upgrades.md，了解方法选择（pg_upgrade、逻辑复制、转储/恢复）、零停机操作手册、回滚和注意事项。

请阅读 references/migration-patterns.md，了解跨引擎类型映射、ORM 迁移工具和详细的迁移模式。

---

连接池、备份与平台选择

• 备份规范包括恢复测试、加密、保留期限限制，以及监控备份时效性。
• 托管数据库可以减少繁琐工作，但不能免除共同责任或合规审查。
• 自托管数据库能换来更多控制权，但代价是高可用性、补丁管理和运维负担。

---

生产环境检查清单

所有引擎

• 身份验证使用现代哈希方式（SCRAM-SHA-256、caching_sha2_password、证书身份验证）
• 所有连接均强制使用 TLS（而不仅仅是“可用”）
• 不使用默认密码、trust 身份验证或无密码访问
• 在数据库前配置连接池（PgBouncer、ProxySQL 或应用端连接池）
• max_connections 根据实际工作负载设置，而非使用默认值
• 已实施、测试并监控备份策略
• 已编写并测试恢复流程（至少每月一次）
• 已配置监控（连接数、查询性能、复制延迟、磁盘使用量）
• 已启用慢查询日志，并设置适当的阈值
• 已识别并删除无效/未使用的索引
• 字符编码正确（MySQL 使用 utf8mb4，PG 使用 UTF8）

然后，请阅读 references/production-checklist.md，了解针对各引擎（PostgreSQL、 MySQL/MariaDB、MongoDB、MSSQL）的检查项，以及完成任何审查、配置或生产环境变更前的 PCI-DSS 4.0 合规检查项。其 CVE 补丁版本下限仅为最低要求；对于当前发行版，请使用顶部的 目标版本 部分。

---

参考文件

• references/config-templates.md - 编写引擎、pg_hba、角色或 PgBouncer 配置时阅读
• references/backup-patterns.md - 进行任何备份、恢复、PITR 或保留期限变更前阅读
• references/migration-patterns.md - 进行跨引擎迁移、类型映射、ORM 工具配置或大表 DDL 操作时阅读
• references/redis-valkey.md - Redis 或 Valkey 用于存储数据、会话或流时阅读
• references/version-upgrades.md - 进行任何 PostgreSQL 主要版本升级前阅读
• references/build-patterns.md - 在步骤 3 中阅读，了解查询、锁、连接池和迁移安全模式；执行任何破坏性操作前也要阅读
• references/production-checklist.md - 与“所有引擎”检查清单一起阅读，了解引擎专属检查项和 PCI-DSS 4.0 检查项

---

输出约定

完整约定请参阅 references/output-contract.md。

• 技能名称： DATABASES
• 交付物类别： audits
• 模式： 条件式。当调用任务是分析、审查、审计或改进现有仓库内容时，遵循 references/output-contract.md 中关于报告篇幅和证据的规则，并将交付物写入 docs/local/audits/databases/<YYYY-MM-DD>-<slug>.md。当调用任务是回答问题、讲解概念、构建新产物或生成内容时，可自由作答，不受该约定约束。
• 严重级别： P0 | P1 | P2 | P3 | info（参阅共享约定；仅用于审计/审查模式）。

相关技能

• code-review - 包含一个 databases.md 参考文档，介绍应用层数据库错误模式（事务误用、NULL 处理、ORM N+1、类型强制转换）。此技能涵盖引擎配置和运维；code-review 涵盖应用如何使用数据库。
• security-audit - 用于检测应用代码中的 SQL 注入和扫描凭据
• kubernetes - 用于在 K8s 上部署数据库（StatefulSets、operators、PVCs）
• terraform - 用于配置托管数据库（RDS、Cloud SQL、Atlas）
• docker - 用于在 Docker Compose 中运行数据库容器
• ansible - 用于数据库服务配置管理
• ci-cd - 用于运行迁移的 CI/CD 流水线（在 CI 中执行架构、迁移门控、回滚自动化）
• observability - 用于跨服务遥测流水线、仪表板、告警路由和 SLO。 此技能负责数据库原生指标、引擎运行状况和查询诊断。
• message-queues - 用于代理交付约定、重试、死信、排序和重放。此 技能负责 Redis/Valkey 引擎配置和流数据安全。

---

规则

1. 没有经过恢复测试的备份不算备份。 每月测试恢复。记录操作步骤。
2. pg_hba.conf 中不得使用 trust 身份验证。 开发环境、Docker 环境以及任何地方都不行。使用 scram-sha-256。
3. PostgreSQL 必须使用连接池。 PG 的每连接一个进程模型若没有连接池就无法扩展。除非有具体理由，否则使用 PgBouncer。
4. PostgreSQL 中必须为外键创建索引。 PG 不会自动创建。缺少外键索引会导致 JOIN 和级联 DELETE 执行顺序扫描。
5. MySQL 始终使用 utf8mb4。 utf8 是个谎言——它仅支持 3 字节，无法存储表情符号或许多 CJK 字符。
6. PostgreSQL 始终使用 timestamptz。 不带时区的 timestamp 不存储时区；服务器时区更改时就会出问题。
7. 仅使用磁盘级加密不符合 PCI-DSS 4.0。 要求 3.5.1.2 需要 TDE、列级加密或应用层加密。
8. 修补 MongoBleed（CVE-2025-14847）。 自托管的 MongoDB < 8.0.17 / 7.0.28 / 6.0.27 可被主动利用，且无需身份验证。
9. 修补 MongoDB 压缩 DoS 漏洞（CVE-2026-25611）。 攻击者可通过精心构造的 OP_COMPRESSED 消息在预身份验证阶段发动 DoS。默认配置受影响（自 3.6 起启用压缩）。已在 8.0.18+ / 8.2.4+ / 7.0.29+ 中修复。
10. 修补 PgBouncer。 PgBouncer < 1.25.1（CVE-2025-12819）可能允许未认证的 SQL 执行，前提是 track_extra_parameters 包含 search_path 且设置了 auth_user（两者均为非默认配置）。2026 年 5 月发布的 1.25.2 增加了进一步的修复（CVE-2026-6664/6665/6666/6667：整数溢出、SCRAM、空指针解引用、KILL_CLIENT 授权）。2026 年 9 月发布的 1.26.0 修复了 CVE-2026-19888（通过不含 nonce 的 SCRAM 客户端最终消息导致未认证崩溃）、CVE-2026-6668（默认 max_packet_size 下因数据包缓冲区溢出导致预身份验证挂起）和 CVE-2026-6669（服务器 SCRAM 迭代次数不受限制）。升级到 1.26.0+——这些修复风险较低。
11. 未经批准的精确命令不得执行破坏性操作。 删除、破坏性恢复、故障转移和后端终止，仅可根据已批准的命令文本，对已确认的目标执行。