MySQL触发器无法直接调用Redis命令，因其运行在内核层且不支持网络请求；正确做法是通过中间表记录失效key，由外部服务轮询清理，兼顾安全与可控性。
MySQL触发器里不能直接调用Redis命令
触发器运行在数据库内核层，不支持发起网络请求或执行外部命令。想在AFTER UPDATE里直接redis-cli DEL key会失败——这不是权限问题，是MySQL根本没提供这个能力。
常见错误现象：ERROR 1418 (HY000): This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA（即使绕过这个，后续也会卡在系统调用上）。
- 正确做法是把缓存失效动作“推”出去：写一条消息到中间表，或发到MQ，由外部服务监听并清理Redis
- 如果必须轻量级，可用
SIGNAL抛出自定义错误，配合应用层的异常捕获做兜底清理（但不推荐，耦合高） - 别用UDF（用户自定义函数）硬接Redis——维护成本高、安全风险大、MySQL 8.0+默认禁用动态库加载
用中间表+轮询实现低侵入缓存失效
这是中小系统最稳的折中方案：触发器只负责记日志，不碰网络；单独起一个轻量服务定时扫表、删Redis、再删记录。
建一张cache_invalidation_log表：
CREATE TABLE cache_invalidation_log ( id BIGINT PRIMARY KEY AUTO_INCREMENT, cache_key VARCHAR(255) NOT NULL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );
在业务表的触发器里插入记录：
DELIMITER $$
CREATE TRIGGER user_after_update AFTER UPDATE ON users
FOR EACH ROW
BEGIN
INSERT INTO cache_invalidation_log(cache_key) VALUES (CONCAT('user:', NEW.id));
END$$
DELIMITER ;
- 注意
cache_key要和应用层实际使用的key完全一致，大小写、前缀、序列化格式都不能差 - 轮询服务建议用
SELECT ... FOR UPDATE SKIP LOCKED避免重复处理，处理完立刻DELETE该行 - 轮询间隔别设太短（如100ms），否则小表也可能被频繁锁表；500ms–2s较稳妥
Redis缓存key设计必须支持批量失效
如果每个查询都存成user:123、user:456这种离散key，触发器只能逐条删——一旦批量更新（比如UPDATE users SET status=1 WHERE dept='tech'），就无法知道该删哪些key。
- 必须为关联查询预埋“标签”：比如给所有技术部用户加个集合
users:dept:tech，每次读取时用SADD维护，失效时DEL users:dept:tech+SCAN匹配user:*<code>并异步清理（慎用SCAN，生产环境优先走中间表）</li> <li>更实用的是“版本号”方式：缓存key写成<code>user:123:v2
，把v2存在单独的cache_version表里，触发器只更新版本号，应用读缓存前先查版本再拼key - 别依赖Redis过期时间当“自动失效”——它只是延迟保证，不是实时性保障；缓存穿透/雪崩风险依然存在
PostgreSQL比MySQL更适合这事？
PostgreSQL的LISTEN/NOTIFY机制能真正实现实时通知：触发器里NOTIFY cache_invalidated, 'user:123'，外部服务长连接接收后立刻删Redis。MySQL没有等价原生能力。
- 如果你的数据库已用PG，这是比中间表更干净的路径，延迟可压到毫秒级
- 但要注意
NOTIFY不保证送达（连接断开就丢），需搭配重试或持久化日志兜底 - 别为了这个功能强行换数据库——多数场景下中间表+合理轮询已足够，复杂度和收益要算清楚
真正难的从来不是“怎么删Redis”，而是“删对哪个key”和“删得及时又不误伤”。业务语义没理清之前，任何自动失效机制都会变成定时炸弹。
