SQL 分区表需平衡数据分布、查询路径与维护成本，核心是明确访问模式、数据增长及故障应对；分区键须为高频过滤条件且分布均匀；粒度应匹配生命周期；必须配套全局索引、剪枝验证与自动滚动策略。
SQL 分区表不是简单加个 PARTITION BY 就完事，核心在于让数据分布、查询路径、维护成本三者达成动态平衡。设计成败，取决于你是否提前想清楚“谁查什么、数据怎么长、出问题怎么救”这三件事。
按业务访问模式选分区键：别被时间戳绑架
很多人一上来就用 create_time 按月分区，结果发现 90% 的查询要跨 3 个月关联用户行为，性能反而更差。分区键本质是“高频过滤条件”的稳定投影——它得满足两个硬条件：查询 WHERE 里高频出现、值分布相对均匀、且变更极少。
- 订单类系统：若 80% 查询带
user_id和status，可考虑HASH(user_id)+RANGE(status)组合分区（MySQL 8.0+ 支持） - 日志类系统：若查最近 7 天错误日志最频繁，用
RANGE COLUMNS(log_time)按天分区比按月更精准，避免扫描冗余分区 - 警惕“伪高频字段”：比如
tenant_id看似合理，但如果 95% 数据集中在 3 个租户，会导致分区严重倾斜，查询仍扫全表
分区粒度要匹配数据生命周期：太粗卡运维，太细则崩查询优化器
分区数量不是越多越好。MySQL 单表建议不超过 2048 个分区，PostgreSQL 对分区数无硬限但超过 1000 个后，查询计划生成耗时明显上升。关键看两点：单分区数据量是否可控、归档 / 删除是否原子化。
- 日均新增 100 万行，保留 180 天：按天分区（180 个），单分区约 100 万行，删除过期数据只需
DROP PARTITION p_20240101，毫秒级完成 - 日均新增 5000 万行，保留 3 年：按月分区（36 个）会导致单分区超 4 亿行，此时应改用
RANGE HASH二级分区——先按年分区，再在年内按user_id % 16哈希拆分，兼顾查询剪枝与 IO 均衡 - 千万别用
DATE_SUB(NOW(), INTERVAL 1 DAY)这类动态表达式做分区定义，会导致 DDL 执行失败或分区边界错乱
必须配套的三件套：全局索引、分区剪枝验证、自动滚动策略
分区表一旦上线，光靠 DDL 不够，得有运行时保障机制。
- 本地索引（Local Index）适合分区键 + 查询键强绑定场景；但跨分区聚合（如全站 UV 统计）必须建全局唯一索引，否则
INSERT会因无法校验全局唯一性而报错 - 每次上线新查询 SQL 前，强制用
EXPLAIN PARTITIONS（MySQL）或EXPLAIN (ANALYZE, VERBOSE)（PG）确认是否真正触发分区剪枝，重点看partitions列是否只显示目标分区 - 写个轻量定时任务：每月 1 号凌晨自动
ALTER TABLE ADD PARTITION新增下月分区，并ALTER TABLE DROP PARTITION清理最老分区——避免人工遗漏导致插入失败
基本上就这些。分区表不是银弹，它是把双刃剑：用对了，千万级数据秒级响应；用错了，比普通表还慢。真正吃透的关键，在于把数据库当“协作方”而非“存储桶”——你告诉它数据怎么来、怎么查、怎么走，它才肯为你高效干活。
