触发器内执行SELECT会引发O(n)性能问题，批量插入时导致全表扫描；多触发器更新同一表易死锁；禁止在触发器中使用事务控制语句；分库分表下触发器天然失效，应改用Binlog或消息队列。
触发器内执行 SELECT 会变成 O(n) 性能黑洞
批量写入时，哪怕只是 AFTER INSERT 里查一次配置表，也会被放大成每行一次查询。10 万行插入 = 10 万次 SELECT COUNT(*) FROM config WHERE key = 'timeout'，而这条语句在触发器里根本不会走索引——字段类型不一致（比如 VARCHAR 对比 BIGINT）、没加 WHERE 条件索引、或用了函数包装（如 DATE(created_at)），都会让 EXPLAIN 显示 type: ALL。
你查慢日志只看到 INSERT INTO orders 耗时 2.4s，但真正卡住的是那 10 万次全表扫描；performance_schema.events_statements_history_long 里 SQL_TEXT 还默认截断，拼都拼不全。
- 配置类查询必须提前缓存到应用层或用
GENERATED COLUMN静态化 - 真要查，必须确保字段类型完全一致、有覆盖索引、且不能出现在
IF或赋值语句中（MySQL 会直接报ERROR 1356） -
SHOW CREATE TRIGGER是唯一能确认它长啥样的方式，没法进监控告警链路
多个触发器争抢同一张统计表 → 死锁高频发生
两个触发器同时更新 user_summary：一个在 AFTER INSERT orders 里做 UPDATE user_summary SET total_amount = total_amount + NEW.amount WHERE user_id = NEW.user_id，另一个在 AFTER INSERT refunds 里也做同样操作。高并发下极易形成死锁闭环：事务 A 锁了 user_summary 行 1001，正等订单表某行；事务 B 锁了那行订单，正等 user_summary 行 1001。
错误日志只显示 Deadlock found when trying to get lock，不标触发器名、不标行号、不标 NEW/OLD 值；SHOW ENGINE INNODB STATUS 里 trx_query 显示的还是主 SQL，不是触发器逻辑。
- 统计类更新必须收口到单点（如应用层聚合后一次写入），禁止分散在多个触发器里
- 如果非要用，所有更新路径必须严格按相同顺序访问表（比如先
user_summary再orders），否则死锁概率随并发线性上升 - 触发器数量超 20 个后，
metadata_lock等待明显升高，连ALTER TABLE都可能被卡住
触发器里调用存储过程或写 COMMIT → 直接报错且定位困难
触发器运行在主 DML 事务上下文中，COMMIT 和 ROLLBACK 语法上就不允许，会抛 ERROR 1422 或 ERROR 1305。更隐蔽的是：你封装了一个带 COMMIT 的存储过程，在触发器里 CALL it()，错误信息完全不提示是哪个过程引发的。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
MySQL 5.6 及更早版本甚至不支持 SIGNAL，只能靠 INSERT INTO non_exist_table 这类黑魔法中断事务，极不可靠。你想“校验失败只回滚触发器部分”？ACID 在这里被硬性收口——唯一合法方式是 SIGNAL SQLSTATE '45000'，但这就意味着主逻辑、日志、状态变更全部一起回滚。
- 任何含事务控制（
START TRANSACTION、COMMIT）的存储过程，都不能被触发器调用 - 复杂校验逻辑必须抽离到应用层，数据库只做原子级约束（如
CHECK、外键） -
SIGNAL报错不带上下文，出问题得手动翻INFORMATION_SCHEMA.TRIGGERS查定义，没法自动化
分库分表 / 主从架构下触发器天然失效
ShardingSphere 或 MyCat 不解析触发器内部 SQL，硬编码表名（如 UPDATE order_001）会绕过分片路由规则；触发器只在主库执行，从库回放的是原始 DML —— AFTER INSERT 生成的审计记录在从库上根本不存在；多活架构下双向同步，同一触发器可能在两边重复执行，造成计数翻倍、状态错乱。
更麻烦的是：ERROR 1442（Can't update table 't' in stored function/trigger）在分布式场景下常被静默吞掉，你看到的只是延迟飙升或数据不一致，根本不知道是触发器在跨库查表时报的错。
- 只要用了中间件、读写分离、或多活，触发器就等于废代码
- 审计、同步、通知类需求，应改用 Binlog 解析（如 Canal、Debezium）或消息队列 + 应用监听
- 想验证是否生效？得在每个分片实例上单独
SHOW TRIGGERS，没法统一管理
触发器最危险的地方，不是它会崩，而是它不报错、不慢、不显眼，只在并发一上来、数据量一涨、配置一动，就悄无声息地把锁等待时间拉高、把主从延迟推到秒级、把排查路径锁死在看不见的日志截断里。
