写入比读取慢，因写需持久化（如刷盘redo/undo日志）、维护多结构（索引分裂、约束检查）、加锁并发控制及触发后台任务，而读常走内存缓存、路径短且多快照读无需锁。
写入比读取慢，核心原因在于写操作需要更多保障：它必须确保数据持久、一致、可恢复，而读操作只需安全地访问已有状态。
写入要刷盘，读取常走内存
多数数据库默认开启持久化（如 MySQL 的 innodb_flush_log_at_trx_commit=1），每次事务提交都需将日志写入磁盘。磁盘写入速度远低于内存读取——机械盘随机写可能仅 100 IOPS，SSD 也才几万；而内存读取是纳秒级。读操作若命中 Buffer Pool 或系统页缓存，根本不用碰磁盘。
写入要维护多个结构，读取只查索引+数据
一次 INSERT 要做：写 redo log（保证崩溃可恢复）、写 undo log（支持回滚和 MVCC）、更新 Buffer Pool 中的数据页、可能触发索引分裂（B+树插入）、还要检查唯一约束和外键。读操作通常只需按索引定位、从缓存中拷贝数据行，路径短、分支少。
写入有锁和并发控制开销
为保证一致性，写操作常需加行锁、间隙锁或表级锁（如 INSERT … SELECT）。InnoDB 还要维护隐藏字段（DB_TRX_ID、DB_ROLL_PTR）和版本链。读操作在 RC 或 RR 隔离级别下多用快照读（不加锁），除非显式加 SELECT … FOR UPDATE。
写入可能触发后台动作
批量写入时容易触发：Buffer Pool 脏页刷盘（由 innodb_max_dirty_pages_pct 控制）、redo log 切换与 checkpoint、二级索引合并（如 InnoDB 的 Change Buffer 合并）、甚至自动扩展数据文件。这些后台任务会争抢 I/O 和 CPU，进一步拖慢写响应。
不复杂但容易忽略：调优写入性能，关键不是“禁用日志”，而是合理权衡——比如批量提交、调整刷盘策略、优化索引数量、避免频繁更新主键或二级索引列。
