向MySQL表插入少量传感器数据为何写入磁盘180kB？

嘿，这个问题其实戳中了InnoDB引擎的核心设计点——为了保证数据安全和事务特性，它的磁盘写入逻辑和你直接写CSV完全不一样，咱们来拆解下为啥会有这么大的“额外开销”：

核心原因拆解 #

• InnoDB的页级存储机制：InnoDB是以16KB大小的页为基本单位来管理数据的，哪怕你只插入12字节的记录，也得把对应的整个16KB页加载到内存、修改，之后再完整写回磁盘。这一下就从12字节变成了至少16KB的写入，但这还远不到180KB，继续往下看。
• 事务日志的强制刷盘：作为ACID兼容的引擎，InnoDB每次写操作都会先写入Redo Log（重做日志），默认配置下（innodb_flush_log_at_trx_commit=1），每次事务提交都会强制把Redo Log刷到磁盘——这是为了防止断电丢数据。Redo Log是以512字节的块为单位写入的，而且哪怕你的日志内容只有几十字节，也会占用一整个块。另外，为了支持回滚和MVCC（多版本并发控制），还会生成Undo Log，这些日志也需要写入磁盘，积少成多。
• 双写缓冲的安全开销：默认开启的**双写缓冲（Doublewrite Buffer）**是InnoDB防止“部分页写入”的保护机制——当修改后的页要写回数据文件时，会先把整个16KB的页写到双写缓冲区域，确认写入成功后，再写回原数据页。这又额外增加了16KB的磁盘写入。
• 后台线程的隐性操作：InnoDB还有不少后台线程在默默干活，比如清理Undo Log的Purge线程、定期把内存脏页刷到磁盘的Checkpoint操作。如果你刚好在统计磁盘写入时赶上了这些后台操作，它们产生的写入量也会被算进去，这可能就是180KB的主要来源。

和CSV写入的本质区别 #

你直接写CSV是追加式写入，操作系统可以直接把25字节的数据追加到文件末尾，没有任何额外的安全校验或事务机制开销，自然写入量极小。而InnoDB是为多进程访问、数据安全、事务支持设计的，这些“额外开销”都是为了保证数据库的可靠性和稳定性。

可以尝试的优化方向 #

如果想减少这种磁盘写入开销，你可以根据自己的业务容忍度调整配置：

• 调整Redo Log刷盘策略：把innodb_flush_log_at_trx_commit设为2，这样Redo Log会每秒刷盘一次，而不是每次事务提交都刷，能大幅减少写入次数，但要注意：最多可能丢失1秒内的数据。
• 关闭双写缓冲：如果你的存储设备（比如带电容的SSD）本身有断电保护，可以关闭innodb_doublewrite=0，省去双写的16KB开销。
• 增大Redo Log文件大小：调大innodb_log_file_size可以减少Checkpoint的触发频率，降低后台刷盘的次数。
• 合并事务：如果业务允许，不要每5分钟就提交一次单条记录的事务，可以攒多条记录后再批量提交（不过你的场景是每5分钟一次，可能不太适用，但可以试试把单次插入改成批量插入的形式）。

内容的提问来源于stack exchange，提问作者sweber