myisam仅在单线程、无索引、无事务、纯顺序插入的苛刻条件下写入略快；真实iot场景中innodb更稳定可控，主键设计（如auto_increment）和批量事务是其高性能关键。
MyISAM 在纯写入吞吐（无事务、无并发更新、无索引维护压力）的简单 IoT 场景下，单线程顺序插入可能略快；但真实 IoT 场景中 InnoDB 的写入吞吐更稳定、更可控、更可扩展——尤其当有并发写入、需要事务保障或后续要查数据时，MyISAM 反而会掉队甚至崩。
MyISAM 写入快的条件非常苛刻
MyISAM 的“写入快”只在以下组合成立时才明显：
- 单线程、批量 INSERT（如
INSERT INTO t VALUES (...), (...), (...)） - 表无任何索引（或只有极少数、不频繁更新的索引）
- 不涉及事务、不需崩溃恢复、不关心断电丢数据
- 写完就扔，几乎不读、不更新、不分页、不 JOIN
一旦加入一个 UPDATE 或一条 SELECT COUNT(*)，MyISAM 就要锁整张表，吞吐断崖下跌。IoT 设备上报常伴随状态轮询或心跳校验，这种混合读写会让 MyISAM 实际吞吐远低于理论值。
InnoDB 的写入瓶颈不在引擎本身，而在主键设计
InnoDB 写入慢，90% 是因为主键没选对。真实 IoT 场景下，常见错误包括：
- 用
UUID或设备 MAC 地址作主键 → 插入随机，引发大量页分裂和缓冲池刷脏 - 没设
AUTO_INCREMENT，又没定义NOT NULL UNIQUE索引 → InnoDB 退化为用隐藏ROW_ID，高并发下冲突概率上升，INSERT延迟抖动明显 - 批量插入没包在
START TRANSACTION里 → 每条语句单独提交，fsync次数爆炸
只要把主键设成 id BIGINT PRIMARY KEY AUTO_INCREMENT，并用批量 + 显式事务写入，InnoDB 在千级并发设备持续上报下，QPS 能稳在 8k–12k（SSD + 合理 buffer pool），且延迟 P99
MyISAM 在 IoT 场景下容易 silently 失效
IoT 数据流不是静态日志，它隐含业务语义：
- 设备离线重传 → 需要幂等写入或去重，MyISAM 没事务，
REPLACE INTO或INSERT IGNORE会锁表，吞吐归零 - 按时间范围查最新 100 条 → 若没建合适索引，MyISAM 全表扫描，CPU 打满，写入被阻塞
- 数据要同步到数仓或做实时计算 → MyISAM 不支持
binlog ROW格式，无法被 Flink / Debezium 捕获变更
这些不是“写不进去”，而是“写进去了，但系统其他环节卡死”，最终表现为整体写入管道吞吐坍塌。InnoDB 原生支持 binlog、MVCC 读写不互斥、辅助索引叶子存主键值（避免回表），让写入和下游消费能解耦运行。
真正要注意的不是“选哪个引擎”，而是：IoT 表是否定义了 AUTO_INCREMENT 主键、是否关闭了 innodb_flush_log_at_trx_commit=2（牺牲一点持久性换吞吐）、是否用 LOAD DATA INFILE 替代 INSERT 批量导入。这些配置的影响，远大于引擎切换本身。
