PostgreSQL 分区表实战：亿级订单表按时间拆分，查询提速 100 倍
MySQL 老玩家对 “分区表” 不陌生，但大多被它的 “短板” 劝退：只支持范围 / 列表分区、查询时容易跨分区扫描、删旧数据仍会锁表。而 PostgreSQL 的分区表堪称 “MySQL 分区表的终极加强版”：支持范围、列表、哈希、复合分区，还能自动路由查询、秒级归档旧数据，亿级大表查询直接从 “秒级” 降到 “毫秒级”。
这篇是 PostgreSQL 专栏的性能优化实战篇，核心目标是帮 MySQL 老玩家 “无缝上手” PG 分区表：从分区表原理对比，到亿级订单表按时间分区实战（创建→插入→查询→维护），再到避坑指南，每步都附可复现代码和性能测试，保证你看完能直接用 PG 分区表解决 “大表查询慢、删旧数据难” 的痛点。
一、先搞懂：PG 分区表为啥比 MySQL 强？（老玩家秒懂对比）
MySQL 的分区表更像 “把大文件拆成多个小文件，还得手动找”；而 PG 的分区表是 “带智能分类的文件柜，自动把文件归到对应格子，找的时候直接定位格子”。用 “文件管理” 类比，一眼看清差距：
plaintext
【MySQL分区表（范围分区）】
大表order_info→拆成order_info_202501、order_info_202502...→查询时需手动指定分区，否则扫描所有分区→删旧数据需ALTER TABLE DROP PARTITION（锁表）【PG分区表（范围分区）】
大表order_info→按create_time拆成多个子分区→查询时自动路由到目标分区→删旧数据直接DROP TABLE子分区（秒级，不锁表）
核心差异表（MySQL 8.0 vs PG 16）
| 对比维度 | MySQL 分区表（8.0） | PostgreSQL 分区表（16） | 优势总结 |
|---|---|---|---|
| 分区类型 | 仅支持范围、列表、哈希分区（单一类型） | 支持范围、列表、哈希、复合分区（如时间 + 地区） | PG（灵活应对复杂场景） |
| 查询路由 | 需手动指定分区，否则全分区扫描 | 自动路由到目标分区（基于分区键过滤） | PG（不用改 SQL，查询更高效） |
| 删旧数据 | ALTER TABLE DROP PARTITION（锁表，慢） | DROP TABLE 子分区（秒级，不锁主表） | PG（归档旧数据无业务影响） |
| 索引支持 | 全局索引易失效，分区索引需手动维护 | 支持分区索引 + 全局索引，自动同步维护 | PG（索引管理更省心） |
| 亿级数据性能 | 查询跨分区时耗时秒级，IO 压力大 | 精准路由单分区，查询毫秒级，IO 开销低 | PG（碾压级性能优势） |
老玩家吐槽式总结：MySQL 的分区表是 “半成品”，只能解决 “大表拆小表” 的基础需求；PG 的分区表是 “成品神器”，从查询、维护、性能全方面拉满，尤其适合亿级订单表、日志表、监控数据等 “按时间 / 地区拆分” 的场景。
二、核心原理：PG 分区表的 “3 个关键概念”（对应 MySQL）
不用怕陌生，PG 分区表的核心逻辑和 MySQL 相通，只是命名更精准，用表格快速对齐：