phpmyadmin白屏主因是memory_limit触发导致静默终止，需查php错误日志确认“allowed memory size exhausted”，并优先检查php.ini、phpmyadmin源码覆盖及php-fpm池配置中的实际生效值。
phpMyAdmin里看不到“内存溢出”错误，先确认是不是真问题
phpMyAdmin 本身不记录 PHP 内存耗尽日志，它只是个数据库操作界面。你看到的 #1030 - Got error 28 from storage engine 或 #1205 - Deadlock found when trying to get lock 看似像崩溃，但大概率是 MySQL 层面的磁盘空间不足、锁冲突或 InnoDB 缓冲池压力大——和 WordPress 的 Allowed memory size exhausted 不是一回事。
真正由 PHP 内存溢出引发的“表崩溃”，通常表现为：
- WordPress 后台打不开，报
Fatal error: Allowed memory size of XXX bytes exhausted - 数据库表还能查（
SELECT * FROM wp_options LIMIT 1成功），但某些插件/主题的批量操作（如更新选项、导入文章）直接卡死或返回空页 - phpMyAdmin 里对应表显示
in use状态长期不释放，或执行SHOW PROCESSLIST发现大量Updating/Locked状态的慢查询
用 phpMyAdmin 快速检查是否因 wp_options 表膨胀拖垮内存
WordPress 把大量配置、缓存、临时数据塞进 wp_options 表，尤其被劣质插件滥用 update_option() 存大 JSON 或未清理的 transient 后，单条记录可能达数 MB。PHP 加载整个表（比如调用 wp_load_alloptions()）时直接爆内存。
在 phpMyAdmin 中执行以下操作：
- 选中你的数据库 → 点击
wp_options表 → 切到Structure标签页，看Data length是否远超 10MB（正常站点应 - 切到
SQL标签页，运行：SELECT option_name, LENGTH(option_value) AS len FROM wp_options ORDER BY len DESC LIMIT 10;
—— 查出最大的几条记录，重点关注_transient_、_site_transient_、wp_statistics_等前缀 - 若发现某条
option_value> 1MB，且autoload = 'yes'，这就是隐患：每次 WordPress 初始化都会把它加载进内存
通过 phpMyAdmin 安全清理高危 option 记录
别直接 DELETE FROM wp_options WHERE option_name LIKE '_transient_%'——这会清掉所有瞬态，可能让部分功能短暂异常；更不能删 rewrite_rules 或 active_plugins 这类核心项。
优先处理明确可删的：
- 清空已过期的 transient：
DELETE FROM wp_options WHERE option_name LIKE '_transient_timeout_%' AND option_value
- 把大 transient 改为不自动加载：
UPDATE wp_options SET autoload = 'no' WHERE option_name LIKE '_transient_%' AND LENGTH(option_value) > 50000;
- 删掉确定无用的巨型记录（例如备份插件残留）：
DELETE FROM wp_options WHERE option_name = 'really_big_backup_data_2024';
每次删/改后，点 phpMyAdmin 右上角 Flush privileges（非必须），并立刻在 WordPress 后台「设置 → 固定链接」点一次保存，重建 rewrite 规则。
phpMyAdmin 无法解决的内存根源，必须改 PHP 配置或代码
phpMyAdmin 只能帮你定位和缓解症状。如果清理完 wp_options 仍频繁报内存耗尽，说明问题在 PHP 层：
- 检查
wp-config.php是否硬编码了过小内存：define('WP_MEMORY_LIMIT', '40M');→ 改成'96M'或'128M'（需服务器允许） - 禁用可疑插件后，在
wp-config.php开头加：ini_set('memory_limit', '256M');—— 这比 .htaccess 或 php.ini 更直接生效 - 某些主题用
get_posts()无分页拉取全部文章，或插件在admin_init钩子中遍历全站 postmeta，这种代码必须改——phpMyAdmin 查不到，得看 error_log
真正棘手的是：MySQL 表结构损坏（如 wp_posts 的 guid 字段被写入超长 URL 导致行溢出）可能触发底层存储引擎异常，这时 phpMyAdmin 显示 Table is marked as crashed，就得用 REPAIR TABLE wp_posts;，但这和 PHP 内存无关——别混淆这两类“崩溃”。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
