phpEnv MySQL表碎片率过高解决 phpEnv数据库性能恢复-php教程-PHP中文网

mysql表碎片率过高导致查询变慢、磁盘虚高，主因是频繁delete/update产生的页空洞；innodb需alter table engine=innodb释放空间，myisam可optimize但须禁用myisam_recover避免启动卡住。

phpenv mysql表碎片率过高解决 phpenv数据库性能恢复

MySQL 表碎片率过高会导致查询变慢、磁盘空间虚高、OPTIMIZE TABLE 失败或卡住——根本原因不是数据量大，而是频繁 DELETE/UPDATE 造成的页空洞；phpEnv 环境下默认用 MyISAM 或 InnoDB，修复方式和风险完全不同。

怎么确认哪个表碎片率高（phpEnv + MySQL 5.7/8.0）

phpEnv 自带的 phpMyAdmin 只显示“数据长度”，不直接显示碎片率。得手动查 information_schema.tables：

SELECT 
  table_name,
  engine,
  round((data_length + index_length) / 1024 / 1024, 2) AS size_mb,
  round(data_free / 1024 / 1024, 2) AS free_mb,
  round((data_free / (data_length + index_length + data_free)) * 100, 2) AS frag_pct
FROM information_schema.tables 
WHERE table_schema = 'your_db_name' 
  AND data_free > 0 
ORDER BY frag_pct DESC;

重点看 frag_pct > 20% 的表，尤其是 engine = 'InnoDB' 却有大量 data_free 的情况——这说明是 InnoDB 表空间未收缩，不是 MyISAM 那种“文件级碎片”。

MyISAM 表直接 OPTIMIZE，但 phpEnv 下要关掉 repair_on_startup

MyISAM 对 OPTIMIZE TABLE 响应快，但 phpEnv 的 MySQL 配置里常含 myisam_recover_options = BACKUP,FORCE 或 myisam_recover = FORCE，这会让 OPTIMIZE 在启动时自动触发修复，反而阻塞操作。

btpanel phpsite 宝塔面板PHP网站

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

先检查 my.ini（phpEnv 的 MySQL 配置路径通常是 D:\phpEnv\phpEnv\MySQL\my.ini）里是否含 myisam_recover 相关项，临时注释掉
执行 OPTIMIZE TABLE your_table_name;，成功后会看到 Msg_text: OK
重启 MySQL 前别忘了把配置改回去，否则下次启动可能卡在“repairing”状态

InnoDB 表不能只靠 OPTIMIZE，必须配合 innodb_file_per_table 和 ALTER TABLE ENGINE

phpEnv 默认开启 innodb_file_per_table = ON（可查 SHOW VARIABLES LIKE 'innodb_file_per_table';），这是关键前提。否则 OPTIMIZE TABLE 对 InnoDB 只是重建索引，不释放 .ibd 文件空间。

确认 innodb_file_per_table = ON，否则先改配置并重启 MySQL
对碎片率高的 InnoDB 表，运行 ALTER TABLE your_table_name ENGINE=InnoDB; ——这会真正重建表、释放空页、压缩 .ibd 文件
如果表太大（比如 > 1GB），phpEnv 的默认 wait_timeout=28800 和 max_allowed_packet=64M 可能导致中断，建议临时调大：SET GLOBAL wait_timeout = 36000;、SET GLOBAL max_allowed_packet = 268435456;
执行期间表会被锁（DML 阻塞），避开业务高峰；phpEnv 是本地开发环境，影响小，但别在跑自动化脚本时顺手执行

碎片预防：phpEnv 开发场景下最容易被忽略的三件事

phpEnv 虽然是本地环境，但长期用它做测试、导入导出、反复 install/uninstall CMS（如 WordPress、Discuz），碎片积累极快。以下三点不改，一个月后又得重来：

禁用 WordPress 的 wp_postmeta 自动清理插件（如 WP-Optimize），它们用 DELETE 清理，却不 VACUUM —— InnoDB 不回收空间，只留空洞
phpEnv 的 MySQL 日志（slow_query_log、general_log）默认可能开着，日志表（如 mysql.slow_log）用的是 MyISAM，定期清空后务必 OPTIMIZE TABLE mysql.slow_log;
用 phpMyAdmin 导入 SQL 时，勾选“启用延迟键写入”（Delayed inserts）会加剧 MyISAM 碎片；InnoDB 表则避免用 “快速插入” 模式，它跳过部分一致性检查，容易产生隐式空洞

碎片不是“坏了才修”，而是“用了就该管”。phpEnv 没有运维团队兜底，每个 DELETE、每次 INSERT ... SELECT，都在悄悄涨 data_free。盯紧 frag_pct，比等慢了再查慢查询日志更省时间。