MySQL触发器不支持动态表名和DDL操作，归档表须预先创建；可行方案是触发器写入中转表，再由外部定时任务按月分表归档。
MySQL中CREATE TRIGGER语法不支持动态表名，归档到按月命名的表必须提前建好
触发器本身无法在运行时拼接并创建类似 archive_orders_2024_06 这样的表——CREATE TABLE 是 DDL，而 MySQL 触发器只允许执行 DML（INSERT/UPDATE/DELETE）和简单赋值。强行在触发器里调用 PREPARE + EXECUTE 会报错 ERROR 1356: Trigger cannot have a statement that does not support replication。
实操建议：
- 归档目标表（如
archive_orders_2024_06）必须在触发器激活前手动或通过外部脚本建好 - 触发器内只做
INSERT INTO archive_orders_2024_06 SELECT ...和原表DELETE - 可用存储过程配合事件调度器（
EVENT）每月初自动建下个月归档表，但触发器不参与建表
触发器里用YEAR()和MONTH()函数提取时间字段生成归档表名不可行
你不能在触发器里写 SET @tbl = CONCAT('archive_orders_', YEAR(created_at), '_', LPAD(MONTH(created_at), 2, '0')) 然后 INSERT INTO @tbl——变量表名在静态 SQL 中无效，MySQL 不支持运行时解析标识符。
替代方案只有两个方向：
- 硬编码分支：用
CASE WHEN MONTH(created_at) = 6 AND YEAR(created_at) = 2024 THEN INSERT INTO archive_orders_2024_06 ...，但维护成本爆炸，不现实 - 更可行的是：触发器只负责标记/移动到统一中转表（如
to_archive），再由外部定时任务（如每天凌晨执行的 Shell +mysql -e）按月分表INSERT INTO archive_orders_2024_06 SELECT * FROM to_archive WHERE ...，之后清空中转表
PostgreSQL可用EXECUTE动态归档，但需用plpgsql且注意权限与事务边界
PostgreSQL 的触发器函数支持 EXECUTE 动态语句，可真正实现“自动建表+插入”。但必须满足：
- 函数语言为
plpgsql，且声明为SECURITY DEFINER（否则无权建表） - 归档表名需用
quote_ident()防注入，例如：EXECUTE format('CREATE TABLE IF NOT EXISTS %I (...) ', tbl_name) - 不能在同一个事务中既
INSERT归档表又DELETE原表——若归档失败，原表数据将丢失；建议先INSERT，成功后再DELETE，并捕获异常 - 触发器类型推荐
AFTER INSERT OR UPDATE，而非BEFORE，避免干扰主逻辑
归档条件判断别直接用NOW()，要用业务时间字段并注意时区
常见错误是写 WHERE created_at ，这会导致触发器每次执行都依赖系统当前时间，而 <code>NOW() 是语句开始时刻的时间戳，在长事务中可能不准；更重要的是，它没考虑业务定义的“过期”含义——比如合同到期日是 expire_date 字段，不是插入时间。
正确做法：
- 归档条件严格基于业务字段，如
expire_date （MySQL）或 <code>expire_date （PostgreSQL，显式指定时区） - 避免在触发器里调用
NOW()/CURRENT_TIMESTAMP做比较，除非该时间就是业务规则本身 - 测试时务必用不同日期的数据验证，比如插入一条
expire_date = '2023-01-01'的记录，看是否被立即归档
实际落地时，最稳妥的路径是：触发器仅负责把过期数据移到固定中转表，归档分表、建表、清理全交给外部调度任务。这样逻辑解耦，出问题可重跑，也方便监控归档延迟。动态建表听着智能，但在生产环境反而增加不可控性。
