MySQL触发器禁止动态SQL和非确定性函数：PREPARE/EXECUTE报ERROR 1336，函数未声明DETERMINISTIC则报ERROR 1418；分表需手写IF分支，跨表逻辑应移至中间表+EVENT或应用层解耦。
触发器里写PREPARE/EXECUTE一定报ERROR 1336
MySQL 触发器从底层就禁止任何动态 SQL，不是权限或配置问题，是引擎硬性限制。哪怕把 PREPARE 封装进存储过程，再由触发器调用，执行时照样抛 ERROR 1336 (0A000): Dynamic SQL is not allowed in stored function or trigger。这个错误出现，说明你正在试图绕过设计边界——得换思路，不是调参数能解决的。
分表路由必须手写IF分支，不能拼表名
想按 NEW.id % 4 路由到 log_0～log_3？触发器里不能写 CONCAT('log_', NEW.id % 4) 当表名用。字段名、表名、数据库名在触发器中都必须是静态标识符。
- 可行做法：用
IF NEW.id % 4 = 0 THEN INSERT INTO log_0 ...; ELSEIF NEW.id % 4 = 1 THEN INSERT INTO log_1 ...;显式列出所有目标表 - 表数量超过 10 个时，维护成本陡增；新增分表必须修改触发器并重新
CREATE TRIGGER - 所有分支的
INSERT字段顺序、类型、数量必须完全一致，否则会因列不匹配失败
跨表写入逻辑得移出触发器上下文
如果原触发器里有“插入 A 表后，动态构造 SQL 去更新 B 表”这类逻辑，8.0 虽支持跨表 DML，但动态拼接仍被拦。此时真正安全的做法是剥离执行时机。
- 改用中间表+事件调度器：触发器只写一行到
trigger_queue表（含操作类型、主键、参数），再由EVENT每秒轮询执行真实UPDATE或INSERT - 应用层解耦更彻底：触发器写 Redis Stream 或 Kafka，由独立消费者进程处理后续逻辑，延迟可控且不阻塞主事务
- 切勿尝试
SET SQL_LOG_BIN = 0或降级sql_mode，这些对动态 SQL 限制完全无效
函数调用要确认确定性，否则触发ERROR 1418
触发器里调用自定义函数（比如 get_balance(new.user_id)）时，若该函数内部用了 NOW()、RAND()、子查询或未声明 DETERMINISTIC，MySQL 8.0 会直接拒绝执行并报 ERROR 1418，尤其在开启二进制日志时。
- 检查函数定义：
SHOW CREATE FUNCTION get_balance;，确认是否含DETERMINISTIC或READS SQL DATA - 临时放行（仅调试）：
SET GLOBAL log_bin_trust_function_creators = 1;，但生产环境必须修复函数本身 - 更稳妥的替代：把计算逻辑移到应用层，或改用视图+物化方式预计算，避免在触发路径中引入不确定行为
最常被忽略的是嵌套调用链——你以为只改了触发器，但里面 CALL 的存储过程可能也含动态 SQL 或非确定性函数，得逐层 SHOW CREATE 检查。
