不能直接用PARTITION BY RANGE (TO_DAYS())，因分区键须包含在主键中会破坏唯一性；TO_DAYS()导致每月建30+分区实为“伪按月”；MySQL无动态分区调度能力，EVENT易出错；且分区裁剪在统计信息陈旧时可能失效。
为什么不能直接用 MySQL 的 PARTITION BY RANGE (TO_DAYS())
业务流水表按月分表，核心诉求是归档可控、查询高效、运维简单。但直接用 PARTITION BY RANGE (TO_DAYS()) 会踩几个硬坑：
• 分区键必须是主键或包含在主键中，若你用 id 当主键、create_time 当分区字段，就得把 create_time 加进联合主键，破坏唯一性约束逻辑；
• TO_DAYS() 按天计算，每月要建 30+ 个分区，实际只是“伪按月”，管理成本高；
• MySQL 不支持动态新增/删除分区的自动化调度（5.7/8.0 均无内置 cron），靠事件调度器（EVENT）写 SQL 拆分逻辑极易出错，比如时区偏差导致漏建下月表；
• 查询带 WHERE create_time BETWEEN '2024-01-01' AND '2024-01-31' 时，优化器未必能精准 prune 到单一分区，尤其当统计信息陈旧时。
推荐做法：应用层控制 + 真实物理分表（如 order_202401）
让表名本身携带时间维度，由业务代码或独立调度服务负责建表、路由、归档。这是目前最可控、兼容性最好、排查最直观的方式。
• 建表语句统一模板，用 CREATE TABLE order_202401 LIKE order_template 复制结构，避免字段差异；
• 所有 INSERT 必须走路由逻辑：根据 create_time 的年月生成表名，例如 2024-03-15 10:22:01 → order_202403；
• SELECT 若只查单月数据，显式指定表名（SELECT * FROM order_202403 WHERE ...），避免跨表 UNION；
• 跨月查询走汇总视图或应用层合并（不建议用 UNION ALL 动态拼接，易触发全表扫描）；
• 表名格式固定为 {prefix}_{YYYYMM}，便于 shell 脚本或 Python 自动识别和清理（如 find /var/lib/mysql/mydb -name "order_2022*" -delete）。
如何安全自动建下月表（避免重复或遗漏）
关键不是“什么时候建”，而是“谁来建、怎么判重、失败怎么兜底”。
• 不要用 MySQL EVENT 在服务端跑建表逻辑——它无法感知应用是否正在写入、无法发告警、失败不通知；
• 推荐用独立定时任务（如 Linux cron + Python 脚本），每天凌晨 2 点检查：当前系统时间的下个月表是否存在，不存在则执行 CREATE TABLE IF NOT EXISTS order_202404 LIKE order_template；
• 检查逻辑必须用 SELECT COUNT(*) FROM information_schema.tables WHERE table_schema='mydb' AND table_name='order_202404'，不能依赖本地时间文件或缓存；
• 建表后立刻执行 INSERT INTO table_build_log (table_name, build_time) VALUES ('order_202404', NOW()) 记录日志，用于审计与故障回溯；
• 若建表失败（如磁盘满、权限不足），脚本必须退出非零码并触发企业微信/钉钉告警，不能静默跳过。
查询路由和 ORM 怎么适配
主流 ORM（如 MyBatis、SQLAlchemy、Django ORM）都不原生支持动态表名，硬编码或字符串拼接风险高。
• MyBatis：用 <bind> 标签在 XML 中计算表名，例如 <bind name="tableName" value="'order_' + @java.time.format.DateTimeFormatter.ofPattern('yyyyMM').format(new java.time.LocalDate())"/>，再在 SQL 中写 FROM ${tableName} —— 注意必须校验 tableName 是否符合 order_\d{6} 正则，防 SQL 注入；
• SQLAlchemy：定义基类，重写 __table_args__ 为函数，在查询前动态返回表名，但要注意连接池复用时的线程安全；
• 更稳妥的做法是封装 DAO 层：所有对流水表的访问都走 OrderDao.insert(order, time) 方法，内部自动解析 time 并路由到对应表，上层完全无感；
• 特别注意：事务内跨月写入（如一笔订单创建在 1 号、支付记录写在 2 号）必须拆成两个独立事务，不能强求单事务跨表，否则丧失分表意义。
真正难的不是建多少张表，而是确保每次 INSERT 都落到正确的表里，且这张表一定存在。任何绕过应用层路由、寄希望于数据库自动分发的方案，在真实业务流量下都会暴露一致性漏洞。
