myisampack仅支持MyISAM表且必须停写——硬性前提，不可绕过；它直接读写.MYD/.MYI文件，跳过SQL层与事务，InnoDB表运行会静默失败或报错。
myisampack 只能用于 MyISAM 表，且必须停写 —— 这不是建议，是硬性前提。InnoDB 表用它会静默失败或报错，别试。
压缩前必须彻底停写，否则文件损坏风险极高
MyISAM 压缩不走 SQL 层，myisampack 直接读写 .MYD 和 .MYI 文件。只要表还在被 INSERT/UPDATE/DELETE，就可能写入一半就被覆盖。
- 推荐操作顺序：
FLUSH TABLES your_db.your_table WITH READ LOCK→ 切到数据目录 → 执行myisampack→myisamchk -rq→UNLOCK TABLES - 不要依赖
--wait或--force来“绕过”并发写入 —— 它们只处理临时文件冲突，不防数据损坏 - 如果用复制环境，主库停写期间从库延迟会累积，需提前评估业务容忍度
压缩后表自动变为只读，写操作不会报错但会导致后续损坏
MySQL 启动后对压缩表的写入（如 INSERT）看似成功，实际是跳过校验直接写入原始文件结构，重启后 check table 会立刻报 Size of datafile is: X Should be: Y 和 Corrupt。
- 压缩表无法通过
SET SESSION sql_log_bin = 0绕过只读限制 -
mysqldump导出再导入不能“解压”，因为 dump 出的是 SQL，而压缩后的.MYD是变长块编码格式，INSERT 会解析失败 - 唯一安全写入路径：先
myisamchk --unpack，再操作，之后可重新压缩
压缩率和性能影响取决于数据特征，不是所有表都值得压
重复字段多、字符串长、数值规律性强的表（如日志中的固定前缀 URL、状态码、用户代理）压缩率可达 60%–70%；纯随机整数或加密字段几乎不压。
- 压缩后每次
SELECT需实时解压数据块，CPU 开销上升，QPS 下降约 10%–25%，延迟毛刺更明显 - 索引文件（
.MYI）默认不压缩，可用myisamchk --analyze --sort-index优化顺序，但不改变只读属性 - 压缩不可逆 ——
myisamchk --unpack是唯一解包方式，不是简单改后缀或删文件
别碰分区表、别混引擎、别指望在线压缩
myisampack 不支持 MySQL 分区表，对 InnoDB 或 Memory 表运行会失败或无效果。它也不是“在线工具”，不存在后台压缩、热重载之类机制。
- 确认表引擎：
SELECT ENGINE FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA='your_db' AND TABLE_NAME='your_table';，必须是MyISAM - 压缩后
SHOW CREATE TABLE看不到任何压缩标记，只读属性在引擎层硬编码，无法 ALTER 修改 - 备份策略要同步更新：压缩表的
.MYD已不是明文，rsync备份没问题，但基于mysqldump的逻辑备份会失效
SELECT、DROP TABLE、RENAME TABLE，但不允许任何修改行内容的操作，哪怕 UPDATE col=col 这种空更新也不行。一旦越界，损坏就是确定性的。 
