不推荐在MySQL触发器中直接通过UDF调用Redis，因其同步阻塞特性会导致事务卡死、网络异常引发写失败、高并发下线程堆积，且UDF维护成本高、安全风险大、缺乏重试与监控；生产环境更推荐基于binlog解析（如Canal）的异步同步方案，或退而求其次采用触发器写中间表+外部服务轮询的伪异步方式。
MySQL 触发器调用 UDF 写 Redis 为什么通常不推荐
直接在 MySQL 触发器里通过 UDF 调用 Redis 是技术上可行的，但生产环境几乎没人这么干——不是写不出来，而是会把数据库拖垮。触发器本身是同步阻塞执行的，一旦 UDF 中 Redis 连接超时、网络抖动或 Redis 拒绝响应，整个 INSERT/UPDATE/DELETE 就卡住，事务无法提交。
常见错误现象包括：ERROR 1422: Explicit or implicit commit is not allowed in stored function or trigger（部分版本 UDF 不支持事务内调用）、Can't connect to Redis server 导致写操作失败、高并发下 MySQL 线程堆积。
- UDF 必须用 C/C++ 编写，依赖
hiredis或redis-cplusplus-client，还要链接boost，编译和部署门槛高 - MySQL 插件目录权限、SELinux、动态库符号导出（
extern "C"）稍有疏漏就FUNCTION does not exist - Redis 写失败无重试、无日志、无监控，数据不一致静默发生
- Row-based binlog 下触发器可能不触发（取决于
binlog_format和语句类型）
更靠谱的替代路径：监听 binlog + 外部服务同步
真正落地的方案，是绕开触发器，改用 MySQL 的 binlog 增量日志做源头。核心思路是：不让数据库承担缓存职责，只负责持久化；由一个独立服务（如 Canal、Debezium、Maxwell）解析 binlog，过滤出目标表变更，再异步更新 Redis。
这样做的好处是解耦、可监控、可重放、失败不阻塞业务。比如 Canal 启动后会伪装成 MySQL 从库，拉取 binlog 并解析为 JSON 格式事件：
{
"data": [{"id":"1001","name":"Alice","updated_at":"2026-04-12 19:30:00"}],
"type": "UPDATE",
"table": "users"
}
你的消费端收到后，只需执行：redis.set("user:1001", json.dumps(data[0])) 即可。
- 必须开启 MySQL
binlog，且binlog_format = ROW（Statement/Mixed 不保证字段级变更可见） - 需要给同步服务分配一个专用复制账号，权限至少含
REPLICATION SLAVE和REPLICATION CLIENT - 注意主键变更（如 UPDATE 修改主键）会导致 Redis key 错位，需在消费逻辑中显式处理 old_key → new_key
- DDL 变更（如加字段）不会触发数据同步，但 Canal 等工具能捕获并告警，比触发器“完全不可见”强得多
如果非要用触发器，至少加一层缓冲
真有历史包袱必须走触发器路径，唯一能接受的做法是：触发器不直连 Redis，而是往一张本地 cache_sync_queue 表里插一条记录，再由外部定时任务或常驻进程轮询该表并批量刷 Redis。
例如触发器体：
INSERT INTO cache_sync_queue (table_name, pk_value, op_type, updated_at)
VALUES ('users', NEW.id, 'UPDATE', NOW());
然后用 Python 脚本每秒查一次：SELECT * FROM cache_sync_queue WHERE status = 'pending' LIMIT 100，成功后 UPDATE ... SET status = 'done'。
- 避免触发器内任何网络 I/O、JSON 序列化、Redis 连接池管理
-
cache_sync_queue表必须加索引：INDEX idx_pending (status, updated_at) - 定时任务要处理重复消费（幂等写 Redis）、死信（超时未处理的记录需告警）
- 这种“伪异步”仍比直连 Redis 稍好，但本质还是妥协方案，仅适用于低频、非核心表
Redis 更新本身要注意原子性和粒度
无论用哪种同步方式，往 Redis 写数据时不能简单 SET 了事。用户表更新一条记录，你得决定是刷新整个哈希结构（HSET user:1001 name "Alice" email "a@b.com"），还是只更新单个字段（HSET user:1001 name "Alice"）。
容易踩的坑：
- 用
SET覆盖整个 JSON 字符串，但其他字段可能被旧值覆盖（比如前端只传了name，后端却把整条记录序列化进去） - 删除操作对应
DEL user:1001，但若业务要求“软删”，就得设个is_deleted字段并同步到 Redis，否则缓存穿透风险上升 - 没有对 Redis 操作加
pipeline或transaction，高并发下多字段更新可能部分成功部分失败 - 没设置过期时间（
EXPIRE），导致脏数据永久滞留；但也不能所有 key 都设 TTL，否则频繁回源压数据库
最麻烦的其实是关联数据——用户更新了头像，但首页排行榜缓存里还存着旧 URL。这类场景没法靠单表 binlog 解决，得靠应用层发领域事件，或者用 Redis 的 PUB/SUB 通知下游服务主动刷新。
