MySQL触发器无法直接刷新Redis缓存，因其运行于内核线程、无网络I/O能力；UDF方案因安全风险、事务阻塞和维护困难被生产环境弃用；推荐采用binlog解析（如Canal）异步同步，或退而求其次使用触发器写中间表+外部轮询。
MySQL 触发器本身不能直接刷新 Redis 缓存——这不是语法写不对的问题，而是架构层面的硬限制。
触发器运行在 MySQL 内核线程中，无网络 I/O 能力，不支持调用外部命令或连接 Redis 客户端。任何试图在 AFTER UPDATE 里写 redis-cli SET 或 EXECUTE IMMEDIATE 'redis-cli ...' 的做法，都会报错或静默失败。
为什么 sys_exec + UDF 方案在生产环境基本不可用
虽然有 lib_mysqludf_sys 这类第三方 UDF 可执行系统命令，但它在真实场景中会立刻暴露三类致命问题：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
sys_exec需要 MySQL 启动时关闭--secure-file-priv，这违反最小权限原则，云数据库（如阿里云 RDS、腾讯云 CDB）直接禁止 - Redis 连接超时、网络抖动、服务宕机时，触发器会阻塞整个事务，导致
INSERT/UPDATE卡死，错误日志里只显示ERROR 1422或无响应 - UDF 是 C 编写的动态库，必须匹配 MySQL 版本和 ABI；升级 MySQL 后大概率崩溃，且无法打日志、无重试、无监控，缓存不一致完全不可感知
binlog 解析才是唯一被验证的可行路径
真正落地的方案是放弃“让 MySQL 主动推”，改为“让外部服务监听 MySQL 的变更流”。核心依赖不是触发器，而是 MySQL 的 binlog：
- 必须设置
binlog_format = ROW和binlog_row_image = FULL，否则字段级变更不可见 - 创建专用复制账号：
CREATE USER 'canal'@'%' IDENTIFIED BY 'pwd'; GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'canal'@'%'; - 使用
canal、maxwell或debezium拉取 binlog，它们伪装成从库，解析出 JSON 事件，例如：{"database":"shop","table":"product","type":"UPDATE","data":{"id":1001,"price":99.9,"updated_at":"2026-06-13 07:00:00"}} - 消费端拿到事件后，构造
redis.set("product:1001", json.dumps(data))，并加入幂等处理（比如先DEL product:1001再SET）
如果非要保留触发器痕迹，只能走“中间表 + 轮询”伪异步
极少数受限环境（如无法开 binlog、无运维权限部署外部服务）下，可退一步用触发器写中间表，再由外部脚本轮询更新 Redis：
- 建一张
cache_sync_queue表，字段含table_name、pk_value、op_type（INSERT/UPDATE/DELETE）、created_at - 触发器只做快速插入：
INSERT INTO cache_sync_queue VALUES ('user', NEW.id, 'UPDATE', NOW()); - 外部 Python/Go 脚本每秒查一次该表，取出未处理记录，执行 Redis 操作后
DELETE对应行 - 注意加
SELECT ... FOR UPDATE或乐观锁，避免多实例重复消费；失败任务需进重试队列，不能丢弃
关键点在于：MySQL 的职责是持久化，不是分发。把缓存同步逻辑塞进触发器，等于让会计兼任快递员和客服——活干不完，还容易弄丢单子。真正的解耦，是从源头（binlog）拿变更，而不是靠数据库内核强行往外推。
