Database Operations

核心功能概述

database-operations 是一个面向企业级后端开发的数据库全流程优化技能，覆盖 schema 设计、迁移管理、查询调优与运维监控四大领域。其核心方法论强调"Measure First, Optimize Second"——所有优化必须基于 EXPLAIN ANALYZE 的实证分析，杜绝经验主义调优。

核心能力矩阵

| 模块 | 关键特性 |

|------|---------|

| Schema 设计 | 用户管理软删除、审计日志触发器、全文搜索 tsvector、JSONB GIN 索引 |

| 查询优化 | 执行计划解读、复合索引策略、覆盖索引、部分索引、N+1 检测 |

| 零停机迁移 | 安全列增删、多阶段列重命名、分区表自动化、CONCURRENTLY 索引创建 |

| ORM 集成 | EF Core 迁移 CLI、AsNoTracking 只读优化、投影查询避免 N+1 |

| 缓存层 | Redis 查询缓存、物化视图、pg_cron 定时刷新 |

| 运维监控 | 连接池健康检查、慢查询分析、表膨胀检测、未使用索引清理 |

显著优势

1. 生产级安全范式：所有索引创建强制使用 CONCURRENTLY 避免锁表；迁移必须包含回滚脚本；分区与软删除方案成熟可直接落地。
2. 量化优化闭环：提供 pg_stat_statements 慢查询定位、pg_stat_user_indexes 无用索引清理、表膨胀监控等可操作的 DBA 工具集。
3. 多语言生态覆盖：原生 SQL 方案外，同时提供 Node.js pg 连接池、TypeScript Redis 缓存、C# EF Core 最佳实践，适配全栈团队。

局限性与注意事项

• PostgreSQL 专属：代码示例强绑定 PG 方言（BIGSERIAL、TIMESTAMPTZ、pg_stat_* 系统表），MySQL/SQL Server 用户需自行迁移语法。
• 云原生特性缺失：未覆盖 Aurora Serverless、Cloud Spanner、CockroachDB 等分布式数据库的特定优化策略。
• 高可用架构浅层：读写分离、流复制监控、故障转移等主从架构内容未涉及，聚焦单机/主库优化。
• 安全认证占位：报告指出未执行实际安全扫描，生产环境需补充 SQL 注入审计、权限最小化审查。

适合人群

• 后端工程师：需要系统性提升 PG 查询性能与迁移规范
• 全栈开发者：寻求 EF Core + PostgreSQL 的一体化配置指南
• 技术负责人：建立团队数据库 Code Review 标准与监控基线

风险提示

• 分区表与物化视图的并发刷新（CONCURRENTLY）仍有短暂锁风险，超大数据量需测试验证窗口期。
• 审计日志触发器在高频写入场景可能成为性能瓶颈，建议异步化或采样写入。

核心用途

database-operations 是一套面向生产环境的数据库运维专家级 Skill，专注于 PostgreSQL 数据库的完整生命周期管理，包括 schema 设计、迁移策略、查询优化和性能调优。

显著优势

1. 系统性方法论 — 遵循"先测量、后优化"原则，强调 EXPLAIN ANALYZE 的必要性，避免盲目优化
2. 零停机迁移策略 — 提供完整的蓝绿部署兼容方案，包括列添加、重命名的安全迁移模式，支持 CONCURRENTLY 索引创建
3. 实战覆盖全面 — 涵盖用户管理、审计日志、软删除、全文搜索等高频业务场景的标准 schema 设计
4. ORM 深度整合 — 针对 EF Core 提供 AsNoTracking、投影查询、Include 优化等具体实践，解决 N+1 查询问题
5. 多级性能优化 — 从连接池配置、Redis 缓存、物化视图到表分区，形成完整的性能加速体系
6. 可观测性内置 — 提供活跃连接、慢查询、表膨胀、未使用索引等监控 SQL，便于持续运维

潜在局限

• PostgreSQL 专属：示例代码重度依赖 PostgreSQL 特性（tsvector、pg_stat_statements、pg_cron 等），MySQL/MongoDB 用户需自行转换
• .NET 生态偏向：EF Core 章节针对 .NET 开发者，Node.js/Python 等其他语言 ORM 用户参考价值有限
• 云原生缺位：未涉及 AWS RDS Aurora、Google Cloud SQL、Azure Database 等托管服务的特有优化
• 高可用架构：缺少 Patroni、PgBouncer、读写分离等集群部署方案

适合人群

• 需要设计生产级 PostgreSQL schema 的后端工程师
• 负责数据库迁移和版本控制的 DevOps/SRE 人员
• 遭遇慢查询、N+1、连接池耗尽等性能问题的技术团队
• 希望建立数据库最佳实践规范的技术负责人

使用风险

| 风险类型 | 等级 | 说明 |

|---------|------|------|

| SQL 注入误用 | 低 | 示例中的 `format()` 动态 SQL 仅在存储过程内使用，实际应用需注意参数化查询 |

| 索引滥用 | 中 | 新手可能过度创建索引，需结合 `pg_stat_user_indexes` 定期清理 |

| 分区复杂性 | 中 | 表分区增加运维负担，需配套自动分区管理脚本 |

| 迁移回滚遗漏 | 低 | 所有示例均提供 Down 迁移，但生产环境仍需额外验证 |

综合来看，这是目前生态中最完整的 PostgreSQL 运维实践指南之一，特别适合从单体应用向规模化演进的技术团队。