分区表加索引不是简单“建一个就行”，关键在索引类型、字段选择和分区键是否对齐。用错策略，不仅不提速，还可能让查询更慢、维护更重。
分区键必须是索引键的前导列（本地索引前提）
本地索引（LOCAL）自动按分区对齐，但要求分区键必须包含在索引定义中，且通常需作为最左列。否则 Oracle 或 PostgreSQL 等会拒绝创建，或降级为全局索引。
- 正确示例（按 order_date 分区，索引含该列）：
CREATE INDEX idx_orders_local ON orders(order_date, customer_id) LOCAL; - 错误示例（缺失分区键）：
CREATE INDEX idx_orders_bad ON orders(customer_id) LOCAL; → 可能报错或无法裁剪分区
高频过滤字段优先入索引，但避免过度冗余
用户常查 customer_id + status，又按 order_date 分区，那组合索引 (order_date, customer_id, status) 比单列索引高效得多——既能分区裁剪，又能快速定位行。
Zancms外贸独立站系统2.0.6
下载
ZanCms，国产外贸独立站自助建站系统（询盘 + 商城） ZanCms 是卓越的国产外贸独立站自助建站系统，集询盘与商城功能于一体。其内置先进的 AI 翻译，轻松打破语言壁垒，让全球客户畅享无障碍浏览。系统架构设计精妙，谷歌性能评分优异，PC 指标高达 90 +，确保快速流畅的访问体验。在搜索优化方面表现卓越，精心打造的 URL 与 TDK，极大提升网站的易收录性，助力在搜索引擎中脱颖而出。多语
- 若查询多为 WHERE order_date = ? AND customer_id = ?，这个三列索引可全走索引查找
- 若再加 create_time 排序，可扩展为 (order_date, customer_id, status, create_time)，避免回表+排序
- 但别把所有 WHERE 字段都塞进去：列越多，索引越重，DML 越慢，空间占用越高
全局索引慎用：强依赖唯一性，但维护成本高
只有需要跨分区唯一约束（如主键/唯一键不包含分区键）时，才考虑 GLOBAL 索引。它不绑定分区，更新分区（如 DROP PARTITION）会令索引失效，必须 REBUILD。
- 典型场景：订单号（order_no）全局唯一，但表按时间分区 → 可建 GLOBAL UNIQUE INDEX idx_order_no ON orders(order_no);
- 风险点：执行 ALTER TABLE ... DROP PARTITION 后，该索引状态变为 UNUSABLE，应用查询直接报错
- 替代思路：用带分区键的联合唯一约束（如 (order_no, order_date)），配合本地索引，更稳定
定期检查索引使用率与碎片，别只建不看
分区表数据持续写入，旧分区可能长期只读，对应本地索引却仍在被统计或维护。不清理，统计信息过期；不合并，叶块碎片升高。
- 查哪些索引几乎没被用：
SELECT index_name, used FROM v$object_usage WHERE used = 'NO';（Oracle） - 对只读老分区，可将对应索引分区设为 UNUSABLE 后重建，或标记为 READ ONLY 表空间减少维护开销
- PG 中可用 pg_stat_all_indexes 查 idx_scan，结合 pg_total_relation_size 看膨胀率
