MySQL触发器无法在数据变更时主动失效Redis缓存，因其内核层不支持网络I/O；正确做法是触发器仅写入中间表记录失效key，由外部轮询服务安全清理，且key设计须支持按业务维度批量失效。
MySQL 触发器无法在数据变更时主动失效 Redis 缓存——这不是写法问题，是内核层不支持网络 I/O 的硬限制。任何尝试在 AFTER UPDATE 里调用 redis-cli、sys_exec 或自定义 UDF 发送 Redis 命令的做法，都会在语法解析、权限校验或系统调用阶段失败，且极易阻塞事务。
触发器里执行 redis-cli DEL 会报什么错
根本不会走到执行阶段：redis-cli 不是 MySQL 支持的语法，直接报 ERROR 1064 (42000)；若绕过语法（比如封装进 UDF），运行时大概率触发：
-
ERROR 1418 (HY000)：函数未声明DETERMINISTIC等特性（即使加了，后续仍卡住） -
ERROR 1422 (HY000)：触发器内隐式提交被禁止（redisConnect()等系统调用会触发） - 错误日志中反复出现
Can't find symbol 'redis_del'或Plugin 'xxx' is not loaded
这些不是配置疏漏，而是 MySQL 内核线程模型与网络 I/O 天然冲突的表现。
中间表 + 外部轮询是最小可行方案
触发器只做一件事：把要失效的 key 记进一张轻量日志表，其余交给外部服务。这是唯一能兼顾事务安全、可追溯、可重试的落地方式。
- 建表必须含
cache_key和created_at，推荐加status字段（pending/success/failed） - 触发器中拼接的
cache_key必须和应用层完全一致——user:123≠USER:123≠users:123 - 批量更新场景（如
UPDATE users SET status=1 WHERE dept='tech'）无法靠单条记录覆盖，需提前在应用层维护集合类 key，例如users:dept:tech - 轮询脚本必须用
SELECT ... FOR UPDATE SKIP LOCKED读取，处理完立刻DELETE或更新status，避免重复消费
轮询服务怎么写才不拖垮 Redis 和 MySQL
轮询不是查表+删 Redis 的简单循环，关键在控制节奏与失败反馈：
- 轮询间隔建议设为
500ms–2s；设成100ms容易因FOR UPDATE锁竞争引发延迟累积 - 对
DEL命令必须设置超时：socket_timeout=1，防止 Redis 响应慢拖死整个进程 - 删除失败必须记录完整错误码（如
ConnectionError、Timeout），不能静默跳过 - 强一致性要求下，可补一层幂等判断：
EXISTS key成立再DEL，避免重复操作误删
真正容易被忽略的是缓存 key 的设计本身——如果 key 没按业务维度分组（比如用户 ID、部门、时间范围），光靠触发器逐条记录，永远跟不上批量变更节奏。同步失效的前提，是缓存结构能支撑“按需批量清理”。
