Redis UDF插件无法在MySQL 8.0+中使用，因官方已移除UDF动态加载机制；替代方案只有应用层集成Redis客户端或使用MySQL内置memcached插件。
Redis UDF 插件在 MySQL 中根本不能直接安装
MySQL 官方不支持 Redis 作为 UDF（User Defined Function）的运行环境，redis_udf 是第三方 C 编写的旧版扩展，仅适配 MySQL 5.6/5.7 且需手动编译，现代 MySQL 8.0+ 已彻底移除 UDF 动态加载信任机制（secure_file_priv 和 plugin_dir 权限收紧），强行加载会触发 Plugin 'redis_udf' is not loaded 或启动失败。
常见错误现象：
- 执行
CREATE FUNCTION redis_set RETURNS STRING SONAME 'libredisudf.so'报错ERROR 1126 (HY000) - MySQL 启动日志出现
Failed to load plugin 'redis_udf' - 即使编译成功，调用时崩溃（SIGSEGV），因 UDF 无事务上下文，无法安全访问 Redis 连接池
替代方案只有两种：
- 改用 MySQL 官方推荐的
memcached插件（仅支持简单 K/V，不支持 Redis 特性） - 把逻辑移到应用层：用
redis-py、jedis等客户端统一管理缓存读写，MySQL 只负责持久化
缓存同步必须由应用代码控制，不是靠插件自动完成
不存在“配置一下就能让 MySQL 自动同步到 Redis”的机制。所谓“同步”，本质是业务写 MySQL 后，再显式写 Redis；或读 Redis 失败后查 MySQL 并回填——这三步（写 DB、删/写缓存、处理竞态）全得自己编码实现。
容易踩的坑：
- 先删 Redis 再写 MySQL：中间窗口期其他请求可能把旧数据重载进缓存（Cache Stampede）
- 用
SET直接覆盖 Redis 值：丢失 TTL、版本号等元信息，导致缓存雪崩时无法降级 - 没加分布式锁：并发更新同一条记录时，多个线程都走“查 DB → 写缓存”路径，造成脏写
推荐做法（以 Python + redis-py 为例）：
- 写操作：用
pipeline批量执行DELETE key+SET key value EX 3600，保证原子性 - 读操作：用
GET key，命中则返回；未命中则查 DB，再用SETNX key value防穿透，失败则 fallback 到 DB - 关键字段变更时，用
PUBLISH channel data触发其他服务刷新本地缓存（非 Redis 本身）
Redis 与 MySQL 数据一致性没有银弹，只能按场景妥协
强一致？做不到。MySQL 提交成功和 Redis 写入成功之间总有网络延迟、节点故障、重试策略差异。实际能做的，是根据业务容忍度选策略：
- 订单状态类：要求最终一致即可，用延迟双删（写 DB → 删 Redis → sleep(100ms) → 再删 Redis）防脏读
- 用户资料类：允许秒级不一致，直接用 Cache-Aside 模式，配合
EXPIRE主动过期 - 库存类：必须强一致？那就放弃 Redis 缓存，改用 Redis + Lua 脚本做原子扣减，MySQL 仅做归档备份
性能影响明显：
- 每次 DB 写都带 Redis 操作，QPS 上限由慢的那个决定（通常是 Redis 网络 RTT）
- 若用
WAIT 2 1000强制 Redis 主从同步，写延迟翻倍，且从节点不可用时命令直接失败
真正该装的是 redis-cli 和监控工具，不是 UDF
与其折腾编译 libredisudf.so，不如花十分钟装好这些：
-
redis-cli --scan --pattern "user:*"：快速验证缓存键分布 -
redis-benchmark -q -n 10000 -c 50 -r 1000000 SET __test__rand_int__ rand：压测当前 Redis 性能基线 - 在应用里集成
redis-py的ConnectionPool，设置max_connections=20和socket_timeout=1，避免连接打满
最常被忽略的一点：Redis 的 maxmemory-policy 默认是 noeviction，内存超限时直接拒绝写入，而你的应用如果没捕获 redis.exceptions.ResponseError: OOM command not allowed when used memory > 'maxmemory'，就会静默失败——连日志都不报。
