不能在 BEFORE INSERT 触发器中直接 SELECT COUNT(*) 查本表行数，因会引发死锁、MVCC 偏差及 ERROR 1442；可靠方案是用独立计数器表或 information_schema.TABLES 中 AUTO_INCREMENT 字段替代。
不能直接在 BEFORE INSERT 触发器里用 SELECT COUNT(*) 查本表行数——会死锁、MVCC 偏差、甚至报错 ERROR 1442。 这是 MySQL（尤其是 InnoDB）的硬限制，不是写法问题，是引擎层禁止行为。
为什么 SELECT COUNT(*) FROM my_table 在触发器里会失败
InnoDB 在 BEFORE INSERT 中执行该语句时，会尝试对整张表加一致性读锁，而当前插入事务已持有行级锁，极易触发死锁；更隐蔽的问题是：MVCC 快照可能看不到“即将插入的这一行”，导致计数偏小，实际超限却放行。
- 错误信息典型为：
Can't update table 'my_table' in stored function/trigger（即使你只 SELECT） - 哪怕加
LOCK IN SHARE MODE或改用SELECT COUNT(*) INTO @cnt，也解决不了底层冲突 - MySQL 5.7+ 默认
REPEATABLE READ隔离级别，让这个问题更稳定复现
真正能用的两种方案：计数器表 or 表空间元数据
绕过直接查本表的限制，核心思路是把“行数”变成一个可原子更新的独立状态。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 建一张轻量计数器表，比如
table_stats，字段为table_name VARCHAR(64), row_count INT UNSIGNED - 配两个
AFTER触发器：AFTER INSERT ON my_table执行UPDATE table_stats SET row_count = row_count + 1 WHERE table_name = 'my_table'；AFTER DELETE同理减 1 -
BEFORE INSERT里只查table_stats，快、无锁、结果可靠 - 替代方案（仅限无 DELETE 场景）：
SELECT AUTO_INCREMENT FROM information_schema.TABLES WHERE TABLE_NAME = 'my_table'，它不锁表，但前提是主键自增且没手工INSERT ... VALUES (x)跳号
别踩这些坑：IGNORE、REPLACE、并发竞态
就算你用计数器表实现了校验，仍有几个现实雷区：
-
INSERT IGNORE和REPLACE INTO可能绕过BEFORE INSERT触发器——它们的执行路径不同，不是每条逻辑插入都进触发器 - 两个并发插入可能同时读到
row_count = 9999，各自加 1 后都写入，变成 10001 行（竞态条件） - 如果业务真要求强一致上限，必须在应用层做 CAS 操作：
UPDATE table_stats SET row_count = row_count + 1 WHERE table_name = 'my_table' AND row_count ，再检查ROW_COUNT()是否为 1
触发器里的行数限制本质是“尽力而为”的防护层，不是分布式锁。生产环境若真有硬性容量红线，优先考虑分区归档、定时清理或应用层控制——别把一致性压力全压给单点触发器。
