mysql触发器无法直接执行redis-cli del命令，因其内核层不支持网络请求，强行调用会因语法错误（如error 1418）、隐式提交禁止（error 1422）或符号未找到而失败；正确做法是通过中间表记录失效key，由外部轮询服务安全清理。

MySQL 触发器不能直接删除 Redis 缓存，因为触发器运行在数据库内核层，不支持网络请求或外部命令执行。强行用 UDF 或 sys_exec 不仅不可靠，还会阻塞事务、拖垮数据库。

触发器里写 redis-cli DEL 会报什么错？

根本不会执行——MySQL 解析器不认识 redis-cli，语法直接失败；如果绕过语法校验（比如用 UDF 封装），实际运行时会卡在系统调用层，常见错误包括：ERROR 1418 (HY000)（函数未声明特性）、ERROR 1422（隐式提交被禁止）、或 mysqld 日志里反复出现 Can't find symbol 'redis_del'。这不是配置问题，是架构层面的不可行。

用中间表记录失效 key 是最稳的轻量方案

触发器只做一件事：把要删的 key 记进一张日志表，其余交给外部服务。这样既避开网络 I/O，又保留可追溯性和失败重试能力。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 建表语句必须包含 cache_key 和 created_at 字段，推荐加 status 字段区分 pending/success/failed
• 触发器中插入的 cache_key 必须和应用层实际使用的 key 完全一致，比如应用用 user:123，就不能写成 USER:123 或漏掉前缀
• 批量更新场景（如 UPDATE users SET status=1 WHERE dept='tech'）无法靠单条 key 失效，得提前在应用层维护集合类 key，例如 users:dept:tech，再通过 DEL + SCAN 清理
• 轮询脚本建议用 SELECT ... FOR UPDATE SKIP LOCKED 读取待处理行，处理完立刻 DELETE，避免重复消费

外部轮询服务怎么写才不翻车？

轮询不是简单查表删 Redis，关键在可控性与容错。

• 轮询间隔别设太短，500ms–2s 较稳妥；高频小表容易因 FOR UPDATE 锁竞争导致延迟累积
• Redis 删除失败必须记录错误码（如 ConnectionError 或 Timeout），不能静默跳过
• 对 DEL 命令加超时控制（socket_timeout=1），防止 Redis 响应慢拖死整个轮询进程
• 若业务要求强一致性，可在轮询服务里补一层幂等判断：先 EXISTS 再 DEL，避免重复操作引发误删

真正容易被忽略的是 key 设计本身——缓存 key 如果没按业务维度分组（比如用户 ID、部门、时间范围），光靠触发器逐条删，永远跟不上批量变更节奏。同步失效的前提，是缓存结构能支撑“按需批量清理”。