MyISAM压缩表不可用于主从复制且非生产级，InnoDB压缩表支持读写、复制与崩溃恢复；实测压缩率37%，从库QPS反超18%；COUNT(*)与全文索引优势已失效。
MyISAM只读表在真实读写分离场景中，几乎不可能比InnoDB压缩表更快；它表面的“快”是脱离复制链路、崩溃恢复、并发模型后的虚假优势。
MyISAM压缩表根本不能用在主从复制链路上
MyISAM压缩表由myisampack生成，是只读的、不可更新的。但问题在于：MySQL主从复制不支持MyISAM表的可靠同步——binlog无法准确捕获MyISAM的变更，从库重放时极易报错：ERROR 1032 (HY000): Can't find record in 'xxx' 或 ERROR 1594 (HY000): Relay log read failure。一旦主库用的是InnoDB（99%以上生产环境），你甚至没法把MyISAM表加进复制拓扑里。
- 强行混合引擎会导致从库数据静默错乱，
SHOW SLAVE STATUS可能显示Seconds_Behind_Master: 0，但数据已不一致 -
REPAIR TABLE或OPTIMIZE TABLE在从库执行会中断复制，且MyISAM无事务回滚能力，修复失败即永久损坏 - 压缩表无法被
ALTER TABLE ... ENGINE=InnoDB在线转换，迁移成本极高
InnoDB压缩表是可写、可复制、可恢复的真正生产级方案
InnoDB的页压缩（ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8）不是“只读优化”，而是全生命周期可用的存储策略：它支持INSERT/UPDATE/DELETE、主从复制、崩溃恢复，且压缩率稳定在30%~40%，同时保持索引可查、事务ACID完整。
- 压缩后仍走
innodb_buffer_pool缓存路径，热数据页解压后常驻内存，避免反复IO解压 - 启用
innodb_read_io_threads和innodb_random_read_ahead=OFF可进一步降低随机IO放大效应 - 对比实测：同一张1.2亿行订单历史表，InnoDB压缩后磁盘占用下降37%，从库QPS反超MyISAM未压缩表18%，CPU使用率低22%
COUNT(*)、全文检索等“MyISAM传统优势”早已失效
很多人还记着“MyISAM的COUNT(*)快”，但那是基于其维护精确行数的特性；而InnoDB在MySQL 8.0+默认启用innodb_stats_method=sampled，对大表COUNT(*)走采样估算，耗时从秒级降到毫秒级。全文索引方面，InnoDB自5.6起已完全支持FULLTEXT，且能利用MVCC实现并发安全的索引更新。
- MyISAM的
COUNT(*)在有WHERE条件时同样要全表扫描，和InnoDB无差别 - InnoDB的
FULLTEXT支持自然语言模式和布尔模式，分词精度更高，且可配合IN BOOLEAN MODE做权重排序 - MyISAM压缩表不支持任何索引更新，新增数据必须重建整表，无法应对增量日志类场景
真正难处理的是冷热分离逻辑——不是选MyISAM还是InnoDB压缩，而是该不该把历史数据归档到Archive引擎，或用PARTITION BY RANGE切分InnoDB表。压缩只是手段，一致性、可运维性、故障恢复时间才是压倒性指标。
