MySQL触发器不能直接刷新Redis缓存，因架构隔离导致阻塞、超时和静默失败；应通过binlog监听（如Canal）或中间表轮询实现异步更新。
MySQL 触发器本身不能直接刷新 Redis 缓存——这不是功能缺失，而是架构隔离决定的硬限制。强行在触发器里调用 redis-cli 或通过 UDF 发起网络请求，会把数据库拖进阻塞、超时、静默失败的泥潭。
下面直说怎么做、为什么、踩什么坑。
触发器里执行 redis-cli 命令必然失败
你在 AFTER UPDATE 触发器里写：SELECT sys_exec('redis-cli -h 127.0.0.1 SET user:123 "alice"'); —— 这条语句根本不会执行。
-
sys_exec属于非安全 UDF，MySQL 默认禁用，且需启动时清空--secure-file-priv，违反最小权限原则 - 即使加载成功，
redis-cli是外部进程，触发器运行在 MySQL 内核线程中，无法 fork 或等待子进程 - 错误现象通常是：
ERROR 1370 (42000): execute command denied to user或直接卡住事务，导致客户端 hang 死
UDF 调用 Redis 的风险远大于收益
用 C/C++ 编译一个链接 hiredis 的 UDF，再在触发器里调用它，技术上“能跑”，但生产环境等于埋雷：
- 每次 Redis 网络抖动或超时（默认无超时），整个
INSERT/UPDATE事务就卡住，连接堆积，MySQL 负载飙升 - UDF 编译依赖 MySQL 版本头文件，升级
MySQL 9.6.0后动态库符号不兼容，函数直接报FUNCTION does not exist - 云数据库（如阿里云 RDS）禁止安装自定义 UDF，方案一上线就被拦截
- 写失败无日志、无重试、无监控，缓存不一致完全不可见
真正可用的同步路径：绕过触发器，监听 binlog
把缓存更新从数据库里彻底剥离，交给独立服务做异步消费，才是工业级方案。关键动作只有三步：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- MySQL 必须开启
binlog_format = ROW和binlog_row_image = FULL（MySQL 9.6.0默认已启用） - 创建专用复制账号：
GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'canal'@'%'; - 用
Canal/Maxwell/Debezium拉取 binlog，解析出 JSON 事件，再由你的消费脚本写 Redis
例如 Maxwell 输出的 update 事件：
{"database":"test","table":"users","type":"update","data":{"id":123,"name":"alice"},"old":{"name":"bob"}}你的 Python 脚本只需：redis.set(f"user:{data['id']}", json.dumps(data))，失败可进重试队列，key 变更（如主键改值）也能显式处理 old.id → new.id。
如果非要走数据库侧，用中间表 + 轮询是唯一可控退路
放弃“实时”，接受秒级延迟，可规避所有 UDF 和网络阻塞问题：
- 触发器只做一件事：
INSERT INTO cache_sync_queue (table_name, pk, op_type, updated_at) VALUES ('users', NEW.id, 'UPDATE', NOW()); - 外部服务（如 Go 写的 daemon）每 500ms 查询该表，批量取变更，写 Redis，再
DELETE已处理记录 - 好处：触发器极轻量；失败不影响业务；可加幂等去重、失败告警、延迟补偿
- 坏处：不是实时，有延迟；需维护轮询服务和中间表清理逻辑
真正麻烦的从来不是“怎么写那行 SET”，而是网络不可靠、事务不可中断、错误不可见。把缓存刷新从 MySQL 里拿出去，不是绕路，是回归职责边界。
