单条 SQL 插入慢，通常不是语句本身的问题，而是背后隐藏的数据库机制、配置或环境因素在拖慢速度。核心原因集中在事务开销、索引维护、日志写入、锁竞争和硬件响应这几个环节。
事务与日志写入开销大
每条 INSERT 默认是一个独立事务（尤其在自动提交模式下），MySQL/PostgreSQL 等会强制将变更写入 redo log / WAL，并刷盘（fsync）以保证持久性。即使数据量小，每次都要等磁盘 I/O 完成，I/O 延迟直接成为瓶颈。
- 检查是否启用了 innodb_flush_log_at_trx_commit = 1（MySQL）或 synchronous_commit = on（PostgreSQL）——这是最常见原因
- 批量插入时可临时调为 0 或 off（牺牲部分安全性换性能），但单条插入无法规避该开销
- SSD 可缓解，但无法消除顺序写 log 的等待
索引更新频繁且复杂
每插一行，所有二级索引都要同步更新 B+ 树结构。若表有 5 个索引，实际写入远不止 1 行数据，还涉及页分裂、缓冲区淘汰、排序插入等额外操作。
- 字段类型过大（如长 TEXT、JSON）、索引列含前缀（INDEX(col(255))）会加剧页碎片和写放大
- 唯一索引还需做重复值校验，可能触发全索引扫描（尤其无合适索引支持 WHERE 条件时）
- 插入热点值（如自增 ID 后缀集中）易引发索引页争用，降低并发吞吐
锁与并发等待明显
单条插入看似简单，但在高并发场景下仍可能被阻塞：
- InnoDB 对插入意向锁（Insert Intention Lock）和间隙锁（Gap Lock）的处理，在 RR 隔离级别下易引发等待
- 主键或唯一键冲突检测需加锁读，若存在大量重复尝试（如幂等插入逻辑），会堆积锁等待
- 表级元数据锁（MDL）在 DDL 进行中会阻塞所有 INSERT，需检查是否有长事务或未提交的 ALTER 操作
客户端与网络链路不可忽视
看似是数据库问题，实则可能是外部因素拉长了“感知延迟”：
- 应用层使用短连接，每次 INSERT 都要经历 TCP 握手 + SSL 协商 + 认证授权，耗时可能超 SQL 执行本身
- 驱动未启用 pipeline 或 prepare-statement 复用，导致解析、权限检查重复执行
- 跨机房或高延迟网络（>10ms RTT）会让 round-trip 时间显著抬高单条耗时
