myisam在实时分析场景中已无实际索引优势，其所谓“快”仅适用于纯静态只读表；一旦有写入操作，便面临文件不同步、锁表修复、全文索引不一致、全表锁并发差及索引结构导致的io性能瓶颈等问题，且innodb自5.6.4起已全面支持fulltext，配合合理配置与数据分层架构，myisam适用场景已近乎消失。
不存在。MyISAM 在实时分析场景中已无实际索引优势，反而会引入一致性、并发和运维风险。
MyISAM 的“快”只在纯静态只读表里成立
所谓 MyISAM 索引快，本质是省去了事务开销、行锁管理、redo log 刷盘和 MVCC 版本链维护。但这仅对真正不动的表有效——比如归档十年以上、从不写入的销售日报表。一旦表被写入过（哪怕只是凌晨跑一次 INSERT INTO ... SELECT），.MYD 和 .MYI 文件就可能不同步，CHECK TABLE 常报 error: 134（记录头损坏），必须 REPAIR TABLE，而该操作锁表，直接中断实时报表服务。
全文索引不是优势，而是遗留包袱
- MyISAM 的
FULLTEXT索引不支持事务：INSERT回滚后，索引可能已部分更新，导致MATCH AGAINST结果缺失或重复 - 每次写入都触发全表锁，高并发下
SHOW PROCESSLIST中大量连接卡在Locked状态 - 停用词表修改需重启 MySQL（
ft_stopword_file），InnoDB 支持运行时SET GLOBAL innodb_ft_server_stopword_table - MySQL 5.6.4 起 InnoDB 已完整支持
FULLTEXT，旧系统迁移前只需确认版本 ≥5.6.4 并启用配置
索引结构差异在实时写入下反而成短板
MyISAM 所有索引都是非聚簇，叶子节点存数据行地址；InnoDB 是聚簇索引，主键索引即数据本身。这意味着：
- MyISAM 的
SELECT COUNT(*)虽快（直接读 .MYI 文件头），但这是以牺牲一致性为代价——崩溃后计数可能错，且无法用于带条件的聚合分析 - MyISAM 只缓存索引（
key_buffer_size），不缓存数据；当实时分析查询涉及多列字段时，频繁读 .MYD 触发随机 IO，QPS 反低于配置合理的innodb_buffer_pool_size - InnoDB 的 B+Tree 索引在写入时虽有页分裂开销，但可通过合理设置
innodb_page_cleaners、innodb_io_capacity控制后台刷脏节奏，适配实时写入负载
真正影响实时分析性能的，从来不是“引擎选 MyISAM 还是 InnoDB”，而是数据分层是否合理：明细进 InnoDB，聚合宽表走 ClickHouse 或 Doris，历史归档用 Parquet + Trino。MyISAM 的适用边界，如今已窄到只剩离线备份恢复后的临时校验表——连这个场景，都在被 mysqldump --tab + LOAD DATA INFILE 配合校验脚本逐步替代。
