高并发写入场景下，SQL性能瓶颈往往集中在单条INSERT的开销、行锁/表锁争用、以及事务提交频率上。批量写入和锁优化不是互斥手段，而是需要协同设计的两个关键方向。
批量写入：减少网络与事务开销
单条INSERT在高并发时会放大网络往返、日志刷盘、索引维护等成本。改用批量方式可显著降低单位数据的写入开销。
- 使用INSERT INTO ... VALUES (...), (...), (...)一次插入多行（如50–500行/批），避免逐条执行；
- MySQL中启用LOAD DATA INFILE（本地文件导入）或REPLACE INTO ... SELECT替代高频小批量INSERT；
- 应用层控制批大小：过大会导致事务过长、锁持有时间增加、内存压力上升；过小则起不到聚合效果；建议从100行起步压测调整；
- PostgreSQL可结合COPY命令或INSERT ... ON CONFLICT DO NOTHING批量UPSERT；
锁粒度与事务控制：避免写阻塞
写入冲突常源于锁等待，尤其在主键/唯一索引冲突、间隙锁（Gap Lock）或自增主键竞争时。优化重点是缩短锁持有时间、缩小锁范围。
- 确保写入语句走索引：无索引的WHERE或ON条件可能触发全表扫描+表级锁（如MySQL MyISAM）或大量间隙锁（InnoDB）；
- 避免长事务：批量写入尽量在单个事务内完成，但总行数不宜超万级；拆分大批次时，用独立小事务代替一个超长事务；
- 合理设置隔离级别：读已提交（READ COMMITTED）可减少间隙锁，适用于多数写多读少场景；
- 自增主键写入热点问题：若大量INSERT都集中在最新ID附近（如时间戳+自增），可能引发页分裂和锁竞争；可考虑UUID_SHORT()、雪花ID或分段预分配策略分散写入位置；
索引与表结构配合优化
写入性能直接受索引数量和宽度影响。每多一个索引，INSERT就要多维护一份B+树。
- 写入密集型表，精简非必要索引；唯一索引需保留，但普通查询索引可延迟创建或用覆盖索引替代；
- 避免在VARCHAR(2000)字段上建索引；长文本字段优先用前缀索引（如INDEX(col(64))）；
- 考虑分区表（如按时间分区）：将写入压力分散到不同物理段，同时便于冷热数据分离和快速归档；
- 对于日志类、流水类表，可启用innodb_flush_log_at_trx_commit=2（MySQL）提升吞吐，牺牲极小概率的崩溃丢失风险；
应用层协同策略
数据库只是链路一环，应用设计不当会让优化事倍功半。
- 异步化写入：将非强一致性要求的数据先写入消息队列（如Kafka/RocketMQ），由消费者线程批量落库；
- 写合并：同一业务实体短时间内多次变更，可在内存中聚合为最终状态再写入，减少重复更新；
- 错峰与限流：对突发流量做客户端或网关层限流（如令牌桶），防止数据库瞬间被打满；
- 监控关键指标：重点关注Innodb_row_lock_waits、Threads_running、慢查询中带“Waiting for table metadata lock”或“Sending data”的写语句；
