MySQL按月分表必须用PREPARE+EXECUTE动态建表，因SQL不支持变量表名；需校验表名防注入、检查表存在性、事件调度避开月末秒级风险，并由应用层路由读写。
MySQL按月分表为什么不能靠手动建表解决
因为手动建表无法应对持续写入场景，月底建新表、月初切流量、历史表归档等操作必须自动化，否则运维成本爆炸，还容易出错。核心矛盾在于：表名含年月（如 orders_202409），而SQL语法不支持变量拼接表名——CREATE TABLE @table_name 直接报错。
存储过程中用 PREPARE + EXECUTE 动态建表是唯一可行路径
MySQL不允许在普通SQL中直接用变量当标识符，但 PREPARE + EXECUTE 可绕过限制。关键点不是“能不能”，而是“怎么拼才安全”：
- 表名必须严格校验：只允许字母、数字、下划线，且以字母开头；用
REGEXP '^[a-zA-Z][a-zA-Z0-9_]*$'过滤，避免注入风险 - 建表语句字符串拼接时，字段定义部分不要动态化，只动态替换表名；例如
CONCAT('CREATE TABLE ', table_name, ' (id BIGINT, ... )') - 务必检查表是否已存在：
SELECT COUNT(*) FROM information_schema.tables WHERE table_schema = DATABASE() AND table_name = ?，避免重复执行失败 - 示例片段：
SET @sql = CONCAT('CREATE TABLE ', v_table_name, ' LIKE orders_template');<br>PREPARE stmt FROM @sql;<br>EXECUTE stmt;<br>DEALLOCATE PREPARE stmt;
事件调度器（EVENT）触发时机必须避开月末最后几秒
MySQL事件默认按服务器时间触发，但跨月瞬间（如 2024-09-30 23:59:59 → 2024-10-01 00:00:00）可能因事务延迟、时区或闰秒导致漏建或重复建表。实际部署必须：
- 事件调度器开启：
SET GLOBAL event_scheduler = ON，且确认 MySQL 配置文件中未禁用event_scheduler=ON - 触发时间设为每月 1 日 02:00（非 00:00），留出缓冲窗口；用
ON SCHEDULE EVERY 1 MONTH STARTS '2024-10-01 02:00:00' - 事件体内第一行加
IF DAY(NOW()) != 1 THEN LEAVE proc_label; END IF;，双重保险防误触发 - 建表逻辑必须包装在存储过程内，事件只负责调用，便于单独测试和调试
分表后查询和写入必须由应用层或中间件路由，MySQL自身不感知分表逻辑
MySQL 没有原生分表路由能力。即使建好了 orders_202409、orders_202410，INSERT INTO orders VALUES (...) 仍会报错——因为主表 orders 不存在。常见错误做法是建同名视图或触发器，但性能差且无法覆盖所有 DML 场景。
- 写入必须由应用计算目标表名（如根据
order_time字段取年月），再拼成INSERT INTO orders_202410 VALUES(...) - 查询若需跨月聚合，只能用
UNION ALL显式合并，例如SELECT * FROM orders_202409 UNION ALL SELECT * FROM orders_202410 - 别依赖
INFORMATION_SCHEMA实时查表列表做路由——高并发下元数据锁会导致延迟，应缓存表名映射关系（如 Redis 存{"202409": "orders_202409"}）
真正麻烦的不是建表，而是让所有业务代码意识到“表名是动态的”，并且在事务、索引维护、备份策略上同步适配——这点最容易被忽略。
