Appearance
数据库分区与分片：先区分问题，再决定是否拆分
修订于 2026-10-12。本文是架构取舍指南，没有“无限扩展”的承诺或本站生产实测数据。
“分区”和“分片”经常被混用。以 PostgreSQL 声明式分区为例，逻辑表可拆成多个物理分区，由数据库依据分区键路由和裁剪；应用通常仍面对同一个数据库。跨数据库或节点的分片则需要额外处理路由、扩容、跨片查询与事务。
先判断瓶颈
查询慢可能来自索引、SQL、统计信息或缓存，数据量大也不自动意味着必须分片。先检查实际执行计划、读写压力、存储增长和备份恢复窗口；能通过索引、归档、容量升级或单库分区解决的问题，应先验证这些方案。
分区键与分片键
好的键要与常用过滤条件匹配，同时避免数据或流量集中到少数分区。时间键便于按日期清理和归档，但近期写入可能集中；用户 ID 便于单用户请求路由，但跨用户统计可能需要汇总。没有“放之四海皆准”的键。
PostgreSQL 的分区裁剪要看查询是否包含可用的分区条件。可用 EXPLAIN 核对实际扫描的分区，不能仅因建了分区就推断查询一定更快。
跨片后的新成本
- 全局唯一性、跨片关联与分页排序变复杂。
- 跨片事务和一致性需要单独设计；可参考分布式事务文章。
- 扩容时数据迁移和路由切换要防止漏读、重复写与热点转移。
- 备份、恢复、监控与权限需要覆盖每个节点。
选型应通过代表性查询、数据分布和故障演练验证。把预期吞吐、延迟、运维复杂度与恢复目标一起写入决策记录。