MySQL触发器不支持动态表名，因SQL预编译要求表名静态；可行方案是触发器写中转表+定时任务调用存储过程PREPARE执行动态SQL。
触发器里不能拼接表名，INSERT INTO CONCAT(...) 直接报错
MySQL 触发器不支持动态表名——这是最常卡住人的地方。你写 INSERT INTO CONCAT('log_', DATE_FORMAT(NOW(), '%Y%m')) VALUES (...)，会直接抛出 ERROR 1351 (HY000): View's SELECT contains a 'CONCAT' that is not allowed 或类似语法错误。触发器体内的 SQL 是预编译的，所有表名必须在创建时静态确定，运行时无法解析变量或函数结果作为表标识符。
实操建议：
- 放弃在触发器内“自动选表”，改用固定目标表 + 应用层路由
- 若必须分表写入，把分表逻辑提到应用代码（如 Python/Java 中根据时间算出
log_202406，再发 INSERT） - MySQL 8.0+ 可考虑用
PRECEDES/FOLLOWS链式触发器配合临时表中转，但复杂度陡增，且仍无法绕过静态表名限制
用触发器 + 存储过程组合实现“伪动态”同步
虽然触发器本身不能动态建表或切表，但可以调用存储过程，而存储过程支持 PREPARE + EXECUTE 执行拼接 SQL。这是目前最可行的折中路径。
常见错误现象：在触发器里直接调用含 PREPARE 的存储过程，可能触发 ERROR 1442 (HY000): Can't update table 't1' in stored function/trigger because it is already used by statement which invoked this stored function/trigger —— MySQL 禁止在触发器中修改当前正在被触发的表，哪怕间接通过 PREPARE 也不行。
使用场景：源表 order 插入时，需按月同步到对应 order_202406 等分表。
实操建议：
- 触发器只做“登记”，把待同步数据写入一张轻量中转表
sync_queue（含src_table,src_id,sync_to,payload_json字段） - 另起一个定时任务（如每分钟跑一次
CALL sync_from_queue()），该存储过程中用PREPARE构造目标表 INSERT 语句 -
sync_to字段存表名字符串（如'order_202406'），避免每次重新计算，也方便人工干预
PostgreSQL 的 EXECUTE format(...) 看似能行，但有隐性陷阱
PostgreSQL 触发器函数支持 EXECUTE format('INSERT INTO %I ...', target_table)，语法上确实允许动态表名。但实际落地时容易踩三个坑：
性能 / 兼容性影响：
- 每次执行都触发查询计划重编译，高并发下
pg_stat_statements会看到大量重复未绑定计划，CPU 消耗明显升高 - 目标表若不存在，错误发生在运行时（
ERROR: relation "order_202499" does not exist），触发器会中断并回滚整个事务，源表插入也失败 - DDL 变更（如某张分表加了新列）后，硬编码的
INSERT ... VALUES ($1,$2,...)会因字段数不匹配直接崩掉，比 MySQL 更难提前发现
实操建议：
- 务必在
EXECUTE前加PERFORM 1 FROM pg_tables WHERE schemaname = 'public' AND tablename = target_table校验表存在 - 用
jsonb_populate_record替代手写字段列表，把NEW转成 JSON 再灌入目标表，兼容结构变化 - 别让触发器承担“建表”职责——表应由运维脚本或应用启动时预建好
真正该同步什么？别把触发器当 ETL 工具用
很多团队试图用触发器完成跨库、跨实例、带清洗逻辑的同步，结果线上延迟飙升、死锁频发。触发器本质是行级、事务内、强一致的钩子，不是异步消息管道。
容易被忽略的地方：
- 一个
INSERT INTO order触发 3 个分表写入，等于把单条语句放大为 4 次磁盘 I/O，TPS 直接腰斩 - 如果目标分表在另一个数据库实例，MySQL 触发器根本无法跨实例操作（除非用 FEDERATED 引擎，但已弃用且极不稳定）
- 没有重试机制：网络抖动导致一次同步失败，数据就永久丢失，而应用层可捕获异常、落日志、进队列重试
事情说清了就结束
