直接删 _transient_% 会越清越慢，因为漏删 _transient_timeout_XXX 导致每次 get_transient() 都触发无效查询和清理逻辑；必须先删 timeout 键再删 transient 键，否则破坏缓存机制并加重数据库负担。
为什么直接删 _transient_% 会越清越慢？
常见错误是执行 delete from wp_options where option_name like '_transient_%';，看似清掉了缓存，实则漏删了对应的 _transient_timeout_xxx 记录。残留的 timeout 键会让每次调用 get_transient() 都去查一个已不存在的值，触发额外查询和无效清理逻辑，反而加重数据库负担。
必须成对删除：先删 timeout，再删 transient
WordPress 的 transient 机制依赖两个键协同工作：_transient_XXX 存值，_transient_timeout_XXX 存过期时间戳。删错顺序或漏删任一，都会导致后续缓存读写异常。
- 第一步（必须先做）：
DELETE FROM wp_options WHERE option_name LIKE '_transient_timeout_%'; - 第二步：
DELETE FROM wp_options WHERE option_name LIKE '_transient_%'; - 别用
TRUNCATE TABLE wp_options——它会重置自增 ID，可能破坏其他 option 的插入逻辑 - 如果启用了多站点且需清理全网 transient，还得额外处理
_site_transient_%和_site_transient_timeout_%
想只清“真过期”的，就得联查 timeout 值
盲目清空所有 transient 可能误伤正在使用的缓存（比如某些插件把关键配置存在 transient 里但设了很长过期时间），首次加载变慢甚至报错。安全做法是只删那些 timeout 已小于当前时间戳的记录：
SELECT t.option_name
FROM wp_options t
JOIN wp_options tt ON tt.option_name = CONCAT('_transient_timeout_', SUBSTRING(t.option_name, 12))
WHERE t.option_name LIKE '_transient_%'
AND t.option_name NOT LIKE '_transient_timeout_%'
AND tt.option_value < UNIX_TIMESTAMP();
执行前先 SELECT COUNT(*) 看数量：万级以下可手动删；超十万条建议分批，避免锁表卡住前台访问。
phpMyAdmin 里操作时最容易忽略的三件事
在 phpMyAdmin 执行 SQL 前，很多人跳过关键确认步骤：
立即学习“PHP免费学习笔记（深入）”；
- 没切换到正确数据库——选错库会导致 SQL 执行无声失败或误操作其他站
- 没勾选「显示 MySQL 返回的完整信息」——删完看不到影响行数，无法判断是否生效
- 删完没点「优化表（Optimize table）」——wp_options 表碎片化后查询效率会持续下降，尤其 autoload 字段多时更明显
真正耗时的不是删数据本身，而是删完不优化、不验证、不溯源。很多 transient 堆积根本原因是插件调用 set_transient( $key, $val, 0 ) 设了永不过期，或者压根没配过期时间就直写 add_option。这类问题不修，清完一周又满。
