全文索引不支持触发器自动计数，因MySQL禁止在触发器中对当前表执行MATCH查询；可行方案是用标记字段+整数增减，或改用异步汇总。
全文索引本身不支持触发器自动计数
MySQL 的 FULLTEXT 索引是内部维护的倒排结构，不暴露行级变更钩子。你无法在 AFTER INSERT 触发器里“刷新”或“更新”全文索引状态——它随 DML 自动生效，但不提供可读取的实时统计接口。所谓“全文索引计数器”，实际指的是对 MATCH ... AGAINST 查询结果集的行数统计（例如有多少条记录匹配关键词），这个值必须靠额外逻辑维护，不能依赖全文索引自身。
COUNT(*) WHERE MATCH(...) 不能放进触发器
这是最常踩的坑：有人试图在触发器中写 SELECT COUNT(*) FROM t WHERE MATCH(title) AGAINST('xxx') 来更新计数表，这会直接报错 ERROR 1442 (HY000)。因为 MySQL 明确禁止在触发器中对当前正被修改的表执行任何 SELECT（哪怕是子查询或聚合），哪怕只是读取全文匹配结果也不行。
- 触发器运行时，
t表已加锁，该SELECT会形成自引用死锁条件 - 全文查询本身可能涉及临时表或排序，进一步放大锁等待和性能抖动
- 即使绕过语法限制，每次插入都重算全文匹配总数，I/O 和 CPU 开销会拖垮写入吞吐
可行方案：只存增量，不存总数
真正能落地的做法，是放弃“维护精确总数”，改为记录每条记录是否命中某类关键词，并用轻量字段标记。例如：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 在原表加一个
TINYINT字段is_tech_article，默认0 - 用应用层或存储过程判断
MATCH(title, content) AGAINST('database mysql' IN BOOLEAN MODE)是否为真，再设为1或0 - 触发器只响应这个字段变化：
UPDATE summary SET tech_count = tech_count + (NEW.is_tech_article - OLD.is_tech_article) - 确保
summary表有主键（如category），并用INSERT ... ON DUPLICATE KEY UPDATE避免重复
这样触发器内无全文查询、无跨表 SELECT、无 NULL 值陷阱，只做整数加减，才能扛住高并发写入。
更稳的选择：跳过触发器，改用异步汇总
如果业务允许秒级延迟，比触发器更可靠的是把计数逻辑移出数据库：
- 监听 binlog（用 canal / debezium）或应用层发消息，捕获含关键词的新增/删除事件
- 由独立服务消费后批量更新 Redis 计数器或汇总表，失败可重试
- 定时任务每 5 分钟跑一次
SELECT COUNT(*) FROM t WHERE MATCH(...)校准，避免漂移累积
触发器一旦上线就极难热更新——字段名改了、关键词规则变了、要加时间窗口过滤，都得停写、删、重建。而异步链路可随时替换处理逻辑，这才是生产环境的真实约束。
