myisampack压缩myisam表前必须停服或确保表无任何写入，否则会导致数据损坏或索引错乱；压缩后表变为永久只读，且必须执行myisamchk -rq重建索引才能正常使用。
myisampack 压缩前必须停服或确保表无写入
压缩 MyISAM 表不是在线操作，myisampack 运行时如果 mysqld 正在写入该表，会导致数据损坏或索引错乱。官方明确建议：在服务器停止状态下执行最安全；若无法停服，至少要确保目标表已无任何 INSERT/UPDATE/DELETE 操作（包括应用层和定时任务），且 mysqld 未启用 --skip-external-locking。
常见错误现象：myisampack 执行成功但后续 SELECT 报错 “Table is marked as crashed”，或返回空结果——大概率是压缩过程中表被并发修改了。
- Linux 下可临时禁用写入：
mysql -e "FLUSH TABLES WITH READ LOCK; SET GLOBAL read_only=ON;" - Windows 下更推荐直接停止服务：
net stop mysql - 压缩完成后必须重启服务或执行
UNLOCK TABLES+SET GLOBAL read_only=OFF
压缩命令和路径必须指向 .MYI 文件（不能只写表名）
myisampack 的参数不是表名，而是 .MYI 索引文件的路径（扩展名可省略，但路径必须准确）。很多人直接运行 myisampack mytable 失败，是因为当前目录不是数据库物理目录，或误传了 .frm 或 .MYD 文件。
正确做法：先定位表文件位置。例如数据库 sales 下的表 orders_202505，Linux 下通常在：/var/lib/mysql/sales/orders_202505.MYI；Windows 下类似：C:\ProgramData\MySQL\MySQL Server 8.0\Data\sales\orders_202505.MYI。
- 进入对应数据库目录后，运行：
myisampack orders_202505（自动识别.MYI） - 不进目录则必须带全路径：
/usr/bin/myisampack /var/lib/mysql/sales/orders_202505.MYI - 别用通配符如
myisampack *.MYI—— 若有多个表，myisampack会尝试合并它们（需结构完全一致），不是批量压缩
压缩后必须立即执行 myisamchk -rq 重建索引
压缩只改 .MYD 数据文件，.MYI 索引文件仍保留旧结构，直接启动 MySQL 会导致无法定位记录、查询卡死或报错 “Incorrect key file for table”。myisamchk -rq 是强制重建索引并修复表状态的唯一方式。
注意：-rq 中的 r 表示 repair，q 表示 quick（仅重算索引，不检查数据行）。它不校验数据完整性，所以必须在压缩前确认原表健康（可用 myisamchk -c 先检查）。
- 命令必须在相同目录下运行：
myisamchk -rq orders_202505 - 若提示 “Can't lock file”，说明
mysqld还在访问该表，务必先停服或FLUSH TABLES - 不要加
-o（覆盖模式）—— 它会生成.OLD备份，浪费空间；也不要用-f强制覆盖，除非你确认中间文件orders_202505.TMD是残留的
压缩后表彻底只读，且无法回退到可写状态
MyISAM 压缩表没有“解压”概念，myisamchk --unpack 只能恢复为未压缩的只读表（仍不可写），不是还原成原始可写表。一旦执行 myisampack，这张表就永久失去写能力——这不是 bug，是设计如此。
这意味着：如果你误压了本该继续写入的表（比如归档策略出错），唯一补救方式是用备份恢复，或从其他节点同步数据。别指望 ALTER TABLE ... ENGINE=MyISAM 或 OPTIMIZE TABLE 能让它变回可写。
- 验证是否只读：
INSERT INTO orders_202505 VALUES (...)会直接报错ERROR 1036 (HY000): Table 'orders_202505' is read only - 压缩率因数据而异：含大量重复字符串、固定长度字段的表可达 70%，但全是随机 UUID 或加密字段的表可能只压 5%～10%
- 压缩后首次查询稍慢（需加载解压字典），之后性能持平甚至略优，因为 I/O 减少
