高并发下 insert into payment_log 卡住主因是 repeatable read 隔离级别下 innodb 对插入间隙加锁，导致自增主键末尾锁竞争；推荐用 insert ignore + 唯一索引 out_trade_no、每批 ≤50 行、innodb_autoinc_lock_mode=2、innodb_flush_log_at_trx_commit=2（需业务确认容灾）。
为什么直接 INSERT INTO payment_log 在高并发下会卡住
因为默认事务隔离级别（REPEATABLE READ）下，InnoDB 对插入间隙加锁，大量并发 INSERT 会争抢同一索引间隙（尤其是自增主键末尾），导致锁等待甚至超时。常见现象是应用层报 Lock wait timeout exceeded，或响应时间从几毫秒飙到秒级。
这不是磁盘 I/O 瓶颈，而是锁竞争。哪怕表只有几十万行，只要写入集中在最新分区（比如按天分表但没拆分），问题一样明显。
- 避免用
SELECT ... FOR UPDATE或UPDATE预占记录再插入——这反而加重锁冲突 - 确认
innodb_autoinc_lock_mode设为2（交错模式），MySQL 5.6+ 默认已是，但老实例可能仍是1 - 不要在插入前查最大 ID 再手动拼
id——破坏自增机制，且引入新锁点
用 INSERT IGNORE 还是 ON DUPLICATE KEY UPDATE？
二者都依赖唯一索引去重，但行为差异直接影响幂等性和性能。支付流水必须防重复，但不能因去重逻辑拖慢主路径。
INSERT IGNORE 在遇到唯一键冲突时静默跳过，不报错；ON DUPLICATE KEY UPDATE 则会执行更新语句（哪怕只是 updated_at = NOW()）。后者多一次行查找 + 更新操作，在高并发下容易引发 secondary index 锁升级，尤其当唯一约束建在业务字段（如 out_trade_no）而非主键上时。
- 推荐用
INSERT IGNORE，只保证“不重复插入”，失败由上游重试或异步补偿处理 - 唯一索引必须建在
out_trade_no上，且类型要匹配（VARCHAR(64)就别用TEXT） - 如果业务强要求记录“最后一次尝试时间”，改用
INSERT ... SELECT+ 临时表兜底，避开ON DUPLICATE的锁开销
批量插入时，INSERT ... VALUES (...), (...), (...) 的安全上限是多少
没有固定数字，取决于单行数据大小、网络包限制（max_allowed_packet）、以及事务日志压力。实测中，超过 500 行/批常触发 Packets larger than max_allowed_packet，而超过 100 行/批在 1000 QPS 下就可能推高 InnoDB row lock time。
更关键的是：大批次插入会延长事务持有时间，阻塞其他写操作。支付流水这种低延迟敏感场景，宁可多发几次小批，也不要压成一个“巨批”。
- 控制每批 ≤ 50 行，
GROUP_CONCAT_MAX_LEN和max_allowed_packet至少设为32M - 用
LOAD DATA INFILE替代大批量INSERT？不行——它需要文件权限，且无法做唯一键冲突处理，线上支付系统基本不用 - 如果用 ORM（如 MyBatis），关掉
useGeneratedKeys，避免额外SELECT LAST_INSERT_ID()查询
要不要分表？payment_log_202409 这种按月分表真有用吗
有用，但只解决查询老化数据的性能，对写入吞吐提升微乎其微。InnoDB 的插入瓶颈在缓冲池和 redo log 刷盘，跟表数量无关。反倒是分表后，跨月统计类 SQL 变成 UNION ALL，运维成本陡增。
真正缓解写压的是：冷热分离 + 异步落库。把实时记账（核心账户余额变更）和流水归档（明细日志）拆成两个流程，后者走消息队列异步写入。
- 当前月表仍用单表，但加
shard_key字段（如MOD(user_id, 16)），后续水平拆分有平滑路径 - 禁止用
CREATE TABLE LIKE复制表结构——容易漏掉ROW_FORMAT=COMPRESSED或KEY_BLOCK_SIZE，导致新表空间暴涨 - 如果已用分表，确保所有分表的
auto_increment_offset和auto_increment_increment错开，避免主键冲突
最易被忽略的一点：没关 innodb_flush_log_at_trx_commit=1 就谈优化，等于在泥地踩油门。生产环境若能接受秒级数据丢失，把它调成 2，写入吞吐常能翻倍——但这得和业务方明确约定容灾边界。
