MySQL 8.0触发器变慢主因是默认行为更严格：1. performance_schema.events_statements_history_long默认开启导致批量触发器性能下降；2. STRICT_TRANS_TABLES使隐式转换报错而非静默处理；3. information_schema查询在触发器中引发更重元数据锁。
MySQL 8.0 中触发器执行耗时比 5.7 更长，不是因为“8.0 变慢了”，而是因为默认行为更严格、监控更全、约束更硬——很多在 5.7 里被静默吞掉的开销，在 8.0 里暴露为显式延迟或直接报错。
performance_schema.events_statements_history_long 默认开启拖慢批量触发器
8.0 默认启用 performance_schema.events_statements_history_long，它会为每条语句（包括每次触发器调用）记录完整执行快照。在 INSERT ... SELECT 插入 10 万行时，AFTER 触发器被调用 10 万次，每次都要写入这个环形缓冲区，引发 mutex 竞争和内存拷贝开销。
- 现象：同样批量导入任务，8.0 耗时多出 30%~200%，
SHOW PROCESSLIST显示大量线程卡在Writing to net或Updating - 验证方式：
SELECT COUNT(*) FROM performance_schema.events_statements_history_long;若值持续接近 10000（默认大小），说明已满并频繁覆盖 - 实操建议：上线前立即关闭：
UPDATE performance_schema.setup_consumers SET ENABLED = 'NO' WHERE NAME LIKE 'events_statements_%'; - 注意：该设置仅对新连接生效；已有连接需重启或重新建连才生效
STRICT_TRANS_TABLES 导致隐式转换失败变显式报错
8.0 默认启用 STRICT_TRANS_TABLES，而 5.7 很多环境仍是宽松模式。这会让原本在 5.7 中“悄悄修复”的赋值操作，在 8.0 中变成事务回滚——看起来像“触发器卡住”或“插入失败”，实则是执行被中断。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 典型错误：
NEW.created_at = NOW(6)赋给精度为DATETIME（无微秒）的字段：5.7 截断后继续；8.0 直接报Truncated incorrect datetime value - 另一个常见点：
NEW.status = ''赋给ENUM('active','inactive')字段：5.7 写入空字符串或默认值；8.0 报错中断 - 实操建议：所有触发器开头加
SET sql_mode = 'NO_ENGINE_SUBSTITUTION';（比全关更安全），并在 BEFORE 中用IF显式校验 - 别依赖
SELECT @@sql_mode查会话级设置——它可能被客户端连接池覆盖，应在触发器内设
information_schema 查询在触发器中锁元数据更重
触发器里查 information_schema.COLUMNS 或 information_schema.TABLES，在 8.0 中更容易阻塞 DML。这不是查询本身变慢，而是元数据锁（MDL）持有策略更严格：8.0 的 MDL 在语句级释放，且与主 DML 共享事务上下文。
- 现象：单行 INSERT 耗时从 2ms 涨到 600ms+，
SHOW ENGINE INNODB STATUS显示waiting for table metadata lock - 根本原因：触发器内
SELECT COUNT(*) FROM information_schema.COLUMNS会申请 S 锁，若此时有 ALTER TABLE 正在执行，就会形成等待链 - 替代做法：改用
SHOW COLUMNS FROM t（不走 information_schema 路径，锁粒度更轻）；或把元数据检查移到应用层预热 - 严禁在高并发写入路径上做任何
information_schema查询——哪怕只查一张表，也可能触发全库元数据加载
真正容易被忽略的点是：你看到的“触发器变慢”，大概率不是触发器逻辑本身的问题，而是 8.0 把过去被掩盖的资源争用、权限缺失、隐式转换失败全都摊开在日志和锁等待里了。排查时别急着重写触发器，先关掉 events_statements_history_long、确认 sql_mode、删掉所有 information_schema 查询——这三步做完，80% 的“变慢”就消失了。
