InnoDB是实时大屏更优选择，因其行级锁+MVCC保障读写不互斥，避免MyISAM表级锁导致的“Waiting for table metadata lock”阻塞；COUNT(*)应带时间条件并建索引，非全表扫描。
InnoDB 是实时大屏项目中延迟更低、更可靠的选择，MyISAM 在写入并发稍高时就会因表级锁导致查询阻塞，实际延迟反而更高。
为什么 MyISAM 在实时场景下“快”是假象
MyISAM 的 COUNT(*) 看似快，是因为它缓存了行数，但这个值在崩溃、非正常关闭或 OPTIMIZE TABLE 后可能不准；更重要的是，它的“快”只存在于纯读、无写、单线程的测试环境。真实大屏场景中：
– 每秒有 5+ 行写入（如订单、点击、曝光日志）时，INSERT 就会触发整表锁；
– 同一时刻若有 SELECT 查询在执行，会被卡在 Waiting for table metadata lock；
– 即使只更新一行，其他所有读写请求都得排队——这直接把端到端延迟拉到秒级甚至更高。
InnoDB 如何保障真实低延迟
延迟低不等于“绝对快”，而是“可预期、不抖动、不雪崩”。InnoDB 做到这点靠三件事：
– 行级锁 + MVCC：写某一行不影响其他行的读，大屏常用的 SELECT COUNT(*) WHERE created_at > DATE_SUB(NOW(), INTERVAL 1 MINUTE) 不会被写入阻塞；
– 自动提交可控：单条 INSERT 默认是事务，开销小；批量写入时用 BEGIN; INSERT ...; COMMIT; 可减少日志刷盘频次；
– autocommit=1 下仍能保证刚写入的数据立刻被 SELECT 查到（隔离级别为 REPEATABLE READ 或 READ COMMITTED 时），这对“秒级刷新”的大屏至关重要。
别让 COUNT(*) 成为性能瓶颈
很多人抱怨 InnoDB 的 COUNT(*) 慢，其实问题不在引擎本身：
– 全表 COUNT(*) 确实要遍历聚簇索引，但大屏几乎从不需要真全表统计；
– 应该用带时间范围的条件，例如 COUNT(*) WHERE event_time >= '2026-10-02 19:50:00'，并确保 event_time 有索引；
– 避免 COUNT(id) 或 COUNT(column)（尤其该列允许 NULL），它比 COUNT(*) 多一次非空判断；
– 如果只要近似值，查 SHOW TABLE STATUS LIKE 't_event' 的 Rows 字段（注意：这是估算值，误差通常 < 10%，但够大屏趋势展示用）。
全文检索或高维聚合？别强撑 MySQL
如果大屏需要“最近1小时含‘优惠券’的用户评论TOP10”，且评论量超百万，InnoDB 的 FULLTEXT 虽支持中文（需 WITH PARSER ngram），但索引更新有最多 1 秒延迟，且 MATCH ... AGAINST 在大数据量下性能不可控。
同理，多维度 GROUP BY + HAVING + 时间窗口聚合，在千万级数据上 MySQL 延迟必然破秒——这不是引擎选错的问题，而是 MySQL 本身不是为这类 OLAP 场景设计的。
这时候该考虑把明细数据同步到 Doris 或 ClickHouse，MySQL 只做写入和简单关联查询。
InnoDB 的稳定性不是靠参数调优堆出来的，是它的并发模型决定的——这点容易被忽略，但恰恰是实时大屏能不能“每秒刷新”的分水岭。 
