高并发写入场景下，MySQL的写入性能瓶颈通常表现为写入延迟突增、连接数耗尽、CPU或磁盘IO使用率飙升，严重时会导致业务请求堆积甚至服务不可用。这类问题的成因复杂，需要从多层面进行针对性优化。
一、高并发写入瓶颈的常见成因
在优化之前，首先需要明确瓶颈的来源，常见的成因包括以下几类：
- 单表数据量过大，写入时索引维护成本高，且容易产生表锁竞争
- 数据库配置不合理，例如缓冲池过小、日志刷盘策略过于激进
- 写入逻辑设计缺陷，例如频繁的单条插入、无意义的索引冗余
- 硬件资源不足，磁盘IO性能差、CPU核心数不够支撑高并发请求
- 主从架构下，主库写入压力大，且从库同步延迟反向影响主库性能
二、架构层面的优化策略
1. 采用分库分表减少单库单表压力
当单表数据量超过千万级时，写入时的索引维护成本会显著上升，此时可以通过分库分表分散写入压力。常见的分表策略包括按时间范围分表、按业务ID哈希分表等。
以用户订单表为例，按月份进行分表的实现逻辑如下：
-- 创建2024年1月的订单分表 CREATE TABLE `order_202401` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `user_id` bigint(20) NOT NULL COMMENT '用户ID', `order_amount` decimal(10,2) NOT NULL COMMENT '订单金额', `create_time` datetime NOT NULL COMMENT '创建时间', PRIMARY KEY (`id`), KEY `idx_user_id` (`user_id`), KEY `idx_create_time` (`create_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='2024年1月订单表'; -- 写入时根据当前时间选择对应的分表，例如2024年1月写入order_202401表 INSERT INTO `order_202401` (`user_id`, `order_amount`, `create_time`) VALUES (1001, 199.99, '2024-01-15 10:30:00');
2. 引入读写分离与写入队列
如果业务读多写少，可以搭建一主多从架构，将读请求分流到从库，减轻主库的写入压力。对于瞬时流量极高的写入场景，还可以引入消息队列做写入削峰，将同步写入改为异步批量写入，降低数据库瞬时并发压力。
三、表结构与索引优化
1. 精简表结构减少写入开销
写入时每一行数据都需要维护所有索引，因此要避免不必要的索引。对于大字段如TEXT、BLOB类型，尽量拆分到单独的扩展表中，避免主表写入时携带大字段数据增加IO开销。同时尽量使用更小的数据类型，例如用INT代替BIGINT，用DATETIME代替TIMESTAMP（如果需要更大时间范围），减少单条数据的存储大小。
2. 合理设计主键
主键尽量选择自增的整数类型，避免使用UUID等随机字符串作为主键。因为InnoDB的聚簇索引是按照主键顺序存储的，随机主键会导致页分裂，增加写入时的IO开销和索引维护成本。
四、MySQL配置参数优化
调整核心配置参数可以显著提升写入性能，以下是一些关键的优化参数：
| 参数名称 | 建议值 | 参数说明 |
|---|---|---|
| innodb_buffer_pool_size | 物理内存的60%-80% | innodb缓冲池大小，用于缓存数据和索引，减少磁盘IO |
| innodb_log_file_size | 1G-2G | redo log单个文件大小，更大的文件可以减少日志切换频率 |
| innodb_flush_log_at_trx_commit | 2 | 控制redo log刷盘策略，2表示每次事务提交写入系统缓存，每秒刷盘一次，性能更高 |
| innodb_flush_method | O_DIRECT | 避免双缓存，直接写入磁盘，提升IO效率 |
| max_connections | 根据业务并发量调整，通常为1000-2000 | 最大连接数，避免连接数耗尽导致写入失败 |
五、写入逻辑优化
1. 批量写入代替单条写入
频繁的单条INSERT语句会产生大量的网络开销和事务开销，尽量将多条写入合并为批量写入。例如将10次单条插入合并为1次批量插入，性能可以提升数倍甚至数十倍。
-- 单条插入（不推荐）
INSERT INTO `user` (`name`, `age`) VALUES ('张三', 20);
INSERT INTO `user` (`name`, `age`) VALUES ('李四', 22);
-- 批量插入（推荐）
INSERT INTO `user` (`name`, `age`) VALUES ('张三', 20), ('李四', 22);
2. 控制事务粒度
尽量缩短事务的执行时间，避免长事务占用锁资源。如果不需要事务保证，可以将批量写入放在一个事务中提交，减少事务提交的次数。同时避免在大事务中执行耗时操作，例如远程调用、文件读写等。
3. 禁止无意义的查询
写入前如果不需要校验数据，就不要执行查询语句，减少不必要的数据库交互。如果必须校验，可以尽量通过缓存完成校验，避免直接查询数据库。
六、硬件与系统层面优化
如果经过上述优化后仍然有瓶颈，可以考虑升级硬件：优先选择SSD固态硬盘替换机械硬盘，提升磁盘IO性能；增加CPU核心数，支撑更高的并发请求；扩大内存容量，让更多的数据和索引可以缓存在内存中。同时系统层面可以调整Linux的磁盘调度算法为deadline或noop，优化磁盘IO调度效率。
所有优化策略都需要结合业务实际场景进行验证，避免盲目套用方案。优化后需要通过压测验证效果，同时监控数据库的CPU、IO、连接数等核心指标，确保优化达到预期效果。