InnoDB是实时写入场景唯一可行选择，因其行级锁+MVCC避免读写互阻，而MyISAM整表锁且INSERT DELAYED已废弃；COUNT(*)性能差异主因查询写法与索引使用，并非引擎本质缺陷。
实时写入频繁时，InnoDB 是唯一可行选择
MyISAM 在并发 INSERT/UPDATE 场景下会整表锁，哪怕只是插入一行，其他读写全得排队。真实业务中只要每秒有 5+ 行写入，或存在多线程/多应用同时写，MyISAM 就会迅速出现 Waiting for table metadata lock 或长时间查询阻塞。
InnoDB 默认行级锁 + MVCC，写操作基本不阻塞读（除非加了 SELECT ... FOR UPDATE），这是实时分析能“跑起来”的底线。
- MyISAM 的
INSERT DELAYED已被 MySQL 5.6+ 废弃，别指望靠它缓解压力 - InnoDB 的
autocommit=1下单条 INSERT 也是事务，但开销可控；若批量写入，显式用BEGIN; INSERT ...; COMMIT;能显著提升吞吐 - MyISAM 的全文索引不支持事务一致性，而实时分析常需“刚写入的数据立刻可查”，这点 InnoDB 的
FULLTEXT（5.6+）更可靠
COUNT(*) 全表统计慢？别怪引擎，先看查询写法
很多人抱怨 “InnoDB 的 COUNT(*) 比 MyISAM 慢十倍”，其实问题不在引擎本身，而在是否走了索引、是否加了 WHERE 条件、有没有 MVCC 版本链遍历。
MyISAM 快是因为它在内存里缓存了行数，但这个值在崩溃或非正常关闭后可能不准；InnoDB 每次算都准，代价是真扫——但你很少需要真扫。
- 如果只是要近似总数，用
SHOW TABLE STATUS LIKE 't'查Rows字段（InnoDB 是估算值，误差通常 - 带条件的
COUNT(*)，确保 WHERE 字段上有索引，否则 InnoDB 和 MyISAM 都得全表扫 - 避免
COUNT(column)且该列允许 NULL —— 它会额外判断非空，比COUNT(*)多一步，尤其对大表敏感
全文检索与实时性冲突？优先确认分词和更新延迟
InnoDB 的 FULLTEXT 索引从 5.6 开始支持，但默认使用 ngram 分词器（中文需显式指定 WITH PARSER ngram），且索引更新不是实时的：INSERT 后最多等 1 秒（由 innodb_ft_cache_size 和 innodb_ft_result_cache_limit 控制）才合并进主索引。
MyISAM 的全文索引虽快，但不支持事务，一旦写入中途失败，索引和数据就可能不一致——这对实时分析是硬伤。
- 强制刷新全文缓存可用
OPTIMIZE TABLE t，但它是锁表操作，别在高峰期跑 - 更稳妥的做法是：把搜索逻辑和写入逻辑解耦，用
INSERT ... ON DUPLICATE KEY UPDATE保证主键唯一，再用异步任务（如轻量脚本轮询INFORMATION_SCHEMA.INNODB_FT_INDEX_CACHE）补漏 - 如果对搜索延迟要求严苛（Elasticsearch 或
ClickHouse做前置接入
磁盘空间和崩溃恢复：MyISAM 看似省，实则更脆弱
MyISAM 表文件（.MYD + .MYI）看起来比 InnoDB 的 ibdata1 或独立表空间小，但这只是表数据没算索引冗余、没算 MVCC 回滚段、也没算 WAL 日志。真实场景中，InnoDB 的 innodb_file_per_table=ON + innodb_log_file_size 合理配置，空间利用率并不差。
真正致命的是崩溃恢复：MyISAM 崩溃后靠 myisamchk 修复，但可能丢数据、索引错位；InnoDB 依赖 redo log 和 undo log 自动前滚+回滚，只要日志没丢，重启就能回到一致状态。
- MyISAM 的
REPAIR TABLE在大数据量下可能耗时数小时，期间表不可用 - InnoDB 的
innodb_fast_shutdown=1（默认）会在关机时刷脏页，加速重启；设为0更安全但慢，实时分析系统建议保持默认 - 别为了省空间关掉
innodb_doublewrite——它防的是页写入一半断电，这种损坏 MyISAM 完全无法自愈
实时数据分析不是只看“查得快”，而是“写不断、查得准、崩了还能自己站起来”。InnoDB 的机制设计就是围绕这三点展开的；MyISAM 的轻量，本质是把复杂性甩给了运维和业务代码去兜底。
