mysql 8.0.29起已彻底移除daemon_memcached插件，因其与innodb缓存重叠、维护成本高且功能受限；推荐改用redis应用层缓存或优化innodb配置与sql索引。
memcached插件在 MySQL 8.0+ 已被移除，无法安装
MySQL 官方从 8.0.29 版本起彻底删除了 libmemcached 插件（即 daemon_memcached），相关源码、文档和编译支持全部下线。你查到的旧教程或配置步骤（比如 INSTALL PLUGIN daemon_memcached SONAME 'libmemcached.so'）在当前稳定版中会直接报错：ERROR 1126 (HY000): Can't open shared library 'libmemcached.so' 或更明确的 Unknown plugin 'daemon_memcached'。
这不是权限、路径或 SELinux 导致的配置问题，而是功能已被废弃 —— MySQL 团队认为它与 InnoDB 缓存层重叠严重，且维护成本高、使用场景窄（仅支持简单 KV 查询，不支持 JOIN/事务/条件过滤）。
替代方案：用 Redis + 应用层缓存控制更实际
如果你真需要「绕过 SQL 解析、直读缓存」来加速高频读（比如用户资料、商品详情页），Redis 是目前最通用、可控性最强的选择。关键不是换存储，而是把缓存逻辑从数据库里搬出来，交给应用自己管：
- 写操作（如
UPDATE users SET name=? WHERE id=?）后，主动SET user:123 "{'name':'Alice'}"并设 TTL - 读操作先查
GET user:123，命中则跳过 MySQL；未命中再查库并回填缓存 - 用
DEL user:123或带前缀的SCAN+DEL处理失效，避免脏数据
这样做的好处是：缓存策略可细化（不同字段不同 TTL）、能处理复合键（如 product:123:stock）、支持原子操作（INCR 计数器）、便于监控缓存命中率。而 daemon_memcached 只允许映射整张表到一个 key，且更新时无法精准失效。
如果必须用 MySQL 原生加速，优先调优 InnoDB 和查询本身
多数所谓「慢查询」根本不需要外部缓存，问题常出在索引缺失、全表扫描或锁等待上。与其折腾已废弃的插件，不如检查这几件事：
- 执行
EXPLAIN FORMAT=TREE SELECT ...看是否走了index或const，避免type: ALL - 确认
innodb_buffer_pool_size设为物理内存的 50%–75%，别小于 1GB（小实例也至少 512MB） - 关闭
query_cache_type=0（MySQL 8.0 默认已禁用，但升级用户可能遗留配置） - 对频繁
WHERE status=? ORDER BY created_at DESC LIMIT 20这类查询，建联合索引(status, created_at)而非单列
这些调整带来的性能提升，通常远超 memcached 插件在它还能用时的效果，而且稳定、可追踪、不引入新故障点。
验证是否误装了第三方补丁或旧版本残留
极少数运维会手动编译旧版插件塞进 8.0 环境，结果导致 mysqld 启动失败或随机崩溃。如果你看到 mysqld 日志里反复出现 segfault 或 symbol lookup error: undefined symbol: memcached_create，基本可以确定是混用了不兼容的二进制文件。
检查方法很简单：
- 运行
SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME LIKE '%memc%';—— 正常应返回空集 - 查插件目录：
ls -l $(mysql --help | grep 'plugin' | awk '{print $NF}')/libmemcached*，若有文件就删掉（别留着碰运气） - 确认配置文件（
my.cnf）里没有loose-daemon_memcached或plugin-load-add相关行
真正难的从来不是加功能，而是及时识别哪些功能已经不该再碰。memcached 插件就是这样一个该划掉的选项。
