PG 分区表实战：千万级数据的查询优化——分区+索引的正确姿势
引言 一张订单表 5000 万行，两年前建表时没人想过它会这么大：管理后台查一个用户近三个月的订单，索引还健在时 80ms，如今同样的查询变成 1.2 秒；DBA 想给 created_at 建个新索引，CREATE INDEX CONCURRENTLY 跑了三个小时还没完，期间磁盘 IO 打满影响线上；想删掉两年的历史数据，DELETE 跑了一夜没删完，还把表搞出了 40% 的膨胀。单表大了以后，慢的从来不只是查询——索引维护、数据清理、备份恢复、vacuum，每一件事都在恶化。 这些问题的共同解法是分区表：把一张逻辑大表按规则切成多个物理小段，查询只碰需要的段（分区裁剪），删除整段数据变成秒级的 DETACH/DROP，索引和 vacuum 都只发生在小分区上。PostgreSQL 10+ 的声明式分区让这件事的门槛降到了几条 DDL。这篇文章按"选分区类型 → 建按月 RANGE 分区 → 本地索引设计 → 分区裁剪验证 → 自动化维护"的顺序，用完整的 SQL 和 EXPLAIN 前后对比，讲清千万级大表分区的正确姿势——以及哪些坑（跨分区查询反而更慢、主键必须带分区键、唯一索....
