1. 项目概述为什么“批量插入”不是一句口号而是MySQL写入性能的生死线你有没有遇到过这样的场景一个后台任务要往MySQL里塞50万条订单记录脚本跑起来后CPU占用率不高磁盘IO也不爆表但就是卡在那儿——一小时才插进去3万条你查SHOW PROCESSLIST发现全是Query状态State列写着Sending data或者Writing to net你开慢查询日志每条INSERT都稳稳超过1秒你甚至怀疑是不是服务器被谁偷偷限速了。其实问题很可能就出在最基础的操作上你用的是单条INSERT而不是批量插入。这不是优化技巧而是MySQL数据写入的底层逻辑决定的——每一次单条INSERT都意味着一次完整的客户端-服务端通信握手、一次SQL解析、一次事务日志redo log刷盘、一次缓冲池buffer pool页加载与脏页标记。当你要插10万行这些开销就被重复执行10万次。而批量插入的本质是把这10万次“小动作”压缩成一次“大动作”一次网络包传过去1000行数据一次解析覆盖1000条语句结构一次redo log写入包含1000行变更的LSN序列一次缓冲池操作批量加载多个数据页。我去年帮某电商公司做订单归档系统压测时原始单条插入耗时47分钟改用合理批量后降到2分18秒性能提升20倍以上。这不是玄学是InnoDB存储引擎的事务机制、日志刷盘策略和网络协议共同作用的结果。本文不讲抽象理论只聚焦实操什么样的批量才算“合理”INSERT INTO ... VALUES (),(),()到底能塞多少个括号为什么加了INSERT IGNORE反而更慢LOAD DATA INFILE在生产环境真能用吗以及最关键的——当你已经写了单条插入的代码怎么改最少的行数拿到最大的性能收益适合所有正在被写入速度拖慢交付节奏的开发者、DBA和数据工程师无论你用的是Python、Java还是Node.js核心逻辑完全通用。2. 批量插入的核心设计逻辑与方案选型深度拆解2.1 为什么不能无脑堆“越大越好”批量尺寸的黄金平衡点在哪里很多人第一次尝试批量插入第一反应就是“那我一次插10万行总比100行快吧”结果一试内存直接OOMMySQL报错Packet too large或者主从延迟飙升到几小时。这背后是三个硬性约束在起作用网络包大小限制、服务端内存压力、事务粒度风险。我们逐个拆解。首先是max_allowed_packet参数。这是MySQL服务端允许接收的最大单个网络包字节数默认值通常是4MB4194304字节。你构造一条INSERT INTO t(a,b,c) VALUES (1,2,3),(4,5,6),...语句每个括号里的值都会转换成字符串参与拼接。假设每行平均占100字节含逗号、括号、引号那么4MB最多容纳约4万行。但实际远达不到这个数因为SQL语句本身还有INSERT INTO ... VALUES这部分固定开销还有字段名、表名、空格等冗余字符。我实测过在字段不多、值较短的情况下安全上限通常在8000~12000行之间。一旦超限MySQL直接返回ERROR 1153 (08S01): Got a packet bigger than max_allowed_packet bytes整个批次失败。所以第一步必须查清你的数据库配置SELECT max_allowed_packet;然后按0.7 * max_allowed_packet / 单行平均字节数来估算安全批次大小。其次是服务端内存压力。InnoDB在执行一条大INSERT时会为这批数据在缓冲池中预分配内存页并维护临时的索引结构。如果一次塞进5万行且表上有3个二级索引InnoDB需要同时维护主键B树和3个二级索引B树的插入路径内存消耗呈非线性增长。某次我们给一个带5个索引的用户行为表做批量导入单批2万行时Innodb_buffer_pool_pages_dirty峰值飙升到12万页触发了频繁的flush list刷盘反而拖慢了整体速度。后来调整到单批3000行脏页峰值稳定在2万以内吞吐量反而提升了35%。这个数字不是拍脑袋定的它和你的innodb_buffer_pool_size、innodb_log_file_size强相关。经验公式是单批行数 ≤ (innodb_buffer_pool_size × 0.1) ÷ (单行数据大小 × 索引数量)。比如你的缓冲池是8GB单行平均200字节有4个索引那么理论安全上限是(8×1024×1024×1024×0.1) ÷ (200×4) ≈ 104万行——但这只是内存理论值实际还要受网络包限制所以最终取两者最小值。最后是事务粒度风险。大事务意味着长事务长事务会带来两个严重后果一是锁持有时间过长阻塞其他DML操作二是undo log持续增长可能撑爆ibdata1文件。尤其在高并发写入场景下一个5分钟没提交的大事务会让所有想更新同一张表的请求排队等待。我们曾在线上遇到过因批量导入未设COMMIT间隔导致information_schema.INNODB_TRX里挂了27个运行超10分钟的事务最终引发雪崩式锁等待。因此必须将大批次再切分为可提交的小事务单元。我的实践标准是单个事务控制在1000~5000行确保执行时间在1~3秒内。这样既规避了长事务风险又保留了批量带来的解析与日志开销摊薄优势。提示不要迷信“一次插越多越快”。我做过一组对比测试对一张10字段、无索引的测试表插入100万行分别用单批100/500/2000/10000行开启autocommit0并手动COMMIT。结果是100行批次耗时182秒500行124秒2000行98秒而10000行反而升到115秒。原因就是10000行批次触发了额外的内存管理开销和锁竞争。真正的性能拐点在2000~5000行区间之后边际效益急剧递减。2.2 三种主流批量方案的实战对比语法级、工具级与协议级市面上常见的批量插入方案主要有三类它们处于不同技术栈层级适用场景和改造成本差异巨大。很多团队踩坑就是因为没搞清自己该用哪一层。第一层SQL语法级批量INSERT ... VALUES (),(),()这是最基础、兼容性最强的方式。所有语言都能用字符串拼接实现无需额外依赖。它的核心优势是零学习成本、全版本兼容、调试直观。你SELECT出来的SQL可以直接在命令行里执行验证。但缺点也很明显拼接字符串易出错、大SQL难维护、无法利用预编译优势。比如Python里用str.join()拼接10万个元组生成的字符串对象会吃掉大量内存Java里StringBuilder扩容也可能引发GC停顿。更重要的是它绕过了数据库驱动的预编译缓存机制每次执行都要走完整的SQL解析流程。不过对于中小批量5000行或一次性ETL任务它依然是首选因为简单可靠。第二层驱动协议级批量JDBC Batch / PyMySQL executemany这是真正发挥批量价值的推荐方案。以JDBC为例PreparedStatement.addBatch()executeBatch()组合底层会将多条语句打包成一个网络包发送并复用预编译的执行计划。PyMySQL的executemany()同理。它的优势在于自动处理SQL注入防护、复用执行计划、驱动层做参数类型校验、内存占用可控。我对比过同一份10万行数据用字符串拼接INSERT耗时89秒用JDBC Batch耗时42秒性能翻倍。关键在于驱动层知道哪些参数是INT、哪些是VARCHAR能提前做类型转换和长度校验避免服务端二次解析。但要注意陷阱某些老版本MySQL Connector/J如5.1.x在rewriteBatchedStatementstrue未开启时executeBatch其实是循环执行单条毫无意义。必须确认连接URL里加了?rewriteBatchedStatementstrue否则等于白配。第三层文件协议级批量LOAD DATA INFILE这是性能天花板方案官方文档称其速度是INSERT的20倍。原理是跳过SQL解析层直接将格式化文本CSV/TSV按行解析后写入存储引擎。它要求数据文件在MySQL服务器本地或启用了local_infile1的客户端且对文件格式、字段分隔符、转义字符有严格要求。优势是极致性能、低CPU消耗、支持并行加载CONCURRENT。但劣势同样致命安全性风险高需FILE权限、生产环境常被禁用、错误处理粒度粗整文件失败或部分成功、无法触发触发器和外键检查除非显式开启。某次我们想用它导入用户画像数据结果因一行数据里多了个未转义的双引号导致后续所有行字段错位最终导入了10万条脏数据回滚花了3小时。所以我的建议是仅用于离线数据仓库初始化、测试环境造数生产环境的实时写入坚决不用LOAD DATA INFILE。注意别被“批量”二字迷惑。INSERT ... SELECT虽然也是批量但它本质是服务端内部操作不经过网络传输适用于表间复制但不解决“应用端写入慢”的问题。本文讨论的“批量插入”特指应用端向MySQL发起的、多行数据的写入请求优化。2.3 方案选型决策树根据你的技术栈和业务场景快速锁定最优解面对三种方案如何选择我画了一张极简决策树帮你5秒内定位你的场景是 ├─ 生产环境实时写入如API下单、日志上报 → 选【驱动协议级】 │ ├─ Java项目 → JDBC Batch rewriteBatchedStatementstrue │ ├─ Python项目 → PyMySQL/MySQLdb executemany() 或 SQLAlchemy bulk_insert_mappings() │ └─ Node.js项目 → mysql2模块的 execute() with array of values ├─ 一次性离线ETL如凌晨跑报表、数据迁移 → 选【SQL语法级】 │ ├─ 数据量 10万行 → 字符串拼接简单直接 │ ├─ 数据量 10万行 → 分片多线程每片≤5000行 │ └─ 表结构复杂含JSON/BLOB → 避免LOAD DATA用SQL语法更可控 └─ 测试/开发环境造数无安全顾虑 → 选【文件协议级】 ├─ 需要极速生成百万级测试数据 → LOAD DATA INFILE 生成规范CSV └─ 需要模拟真实业务逻辑如触发器 → 回退到SQL语法级这个决策树的核心逻辑是生产环境优先保安全、保可控、保可观测离线任务优先保效率、保简单测试环境可以激进但必须隔离。我见过太多团队为了追求“20倍性能”在支付核心链路里硬上LOAD DATA INFILE结果因权限配置失误导致数据写入失败整个支付通道中断47分钟。记住数据库写入的SLA永远排在性能指标之前。3. 核心细节解析与实操要点从参数调优到代码落地的完整链路3.1 MySQL服务端关键参数调优让批量插入真正“跑起来”再好的应用层批量遇上拧巴的MySQL配置效果也要打五折。以下四个参数是批量插入的“命门”必须逐个核对。innodb_flush_log_at_trx_commit这是影响写入性能最敏感的参数。它控制事务提交时redo log的刷盘策略1默认每次COMMIT都强制刷盘到磁盘。最安全但最慢。0每秒刷盘一次事务提交时不刷盘。性能最好但崩溃可能丢失1秒数据。2每次COMMIT刷盘到操作系统缓存由OS决定何时落盘。安全性和性能折中。批量插入场景下强烈建议设为2。理由很实在你本来就是把1000行打包成一个事务这个事务的ACID保障由InnoDB的崩溃恢复机制兜底不需要每毫秒都刷一次磁盘。设为2后我实测10万行插入耗时从63秒降到31秒。注意SET GLOBAL动态修改后已连接的客户端不会生效必须重连或在连接URL里指定?innodb_flush_log_at_trx_commit2。sync_binlog如果开启了binlog主从复制必需这个参数决定binlog的刷盘频率。sync_binlog1表示每次写入都刷盘sync_binlog0表示依赖OS缓存。批量插入时设为0或1000每1000次写入刷一次。设为0风险略高主从延迟增大但性能提升显著设为1000是更稳妥的选择。线上环境我通常配sync_binlog1000平衡安全与速度。innodb_buffer_pool_size缓冲池大小直接影响批量插入时的页加载效率。如果它太小大量数据页无法缓存频繁触发磁盘读取批量优势荡然无存。计算公式很简单专用数据库服务器设为物理内存的70%~80%混合部署DB应用设为物理内存的50%~60%。比如32GB内存的DB服务器innodb_buffer_pool_size24G。用SHOW ENGINE INNODB STATUS\G查看BUFFER POOL AND MEMORY部分重点关注Free buffers是否长期为0Database pages是否稳定在高位。innodb_log_file_sizeredo log文件大小决定了事务日志的循环写入效率。太小会导致频繁checkpoint拖慢写入太大则崩溃恢复时间长。批量插入时建议单个log file ≥ 1GB。计算依据是日志文件总大小应能容纳至少1小时的写入量。比如你业务峰值每秒写入10MB那么innodb_log_file_size × 2 ≥ 10×3600 36000MB即单个文件≥18GB。当然生产环境不必这么激进1GB~4GB是安全且高效的区间。修改此参数需停机步骤是停止MySQL → 删除旧log文件 → 修改配置 → 启动MySQL。实操心得参数调优不是“一劳永逸”。我习惯在批量任务前执行SELECT innodb_flush_log_at_trx_commit, sync_binlog, innodb_buffer_pool_size;确认当前值任务结束后再SET GLOBAL改回原值。用脚本自动化这个过程避免人为遗漏。3.2 应用层代码实操Java、Python、Node.js的批量插入范式JavaJDBC教科书级的正确写法// 关键连接URL必须带 rewriteBatchedStatementstrue String url jdbc:mysql://localhost:3306/test?useSSLfalseserverTimezoneUTCrewriteBatchedStatementstrue; Connection conn DriverManager.getConnection(url, user, pass); conn.setAutoCommit(false); // 关闭自动提交 String sql INSERT INTO user_order (order_id, user_id, amount, status) VALUES (?, ?, ?, ?); PreparedStatement ps conn.prepareStatement(sql); // 每500行提交一次 int batchSize 500; for (int i 0; i orderList.size(); i) { Order order orderList.get(i); ps.setString(1, order.getOrderId()); ps.setLong(2, order.getUserId()); ps.setBigDecimal(3, order.getAmount()); ps.setString(4, order.getStatus()); ps.addBatch(); // 添加到批处理队列 // 达到批次大小执行并提交 if ((i 1) % batchSize 0) { ps.executeBatch(); conn.commit(); ps.clearBatch(); // 清空批处理队列 } } // 处理剩余不足批次的数据 if (!ps.getBatchSize().isEmpty()) { ps.executeBatch(); conn.commit(); } ps.close(); conn.close();避坑点必须用PreparedStatement不能用Statement否则addBatch无效clearBatch()必须在commit()之后调用否则下次addBatch会累加历史数据如果executeBatch()抛异常记得conn.rollback()否则事务状态混乱。PythonPyMySQL简洁但易错的写法import pymysql conn pymysql.connect( hostlocalhost, useruser, passwordpass, databasetest, autocommitFalse, # 关键关闭自动提交 # 不需要rewriteBatchedStatementsPyMySQL原生支持 ) cursor conn.cursor() # 准备数据列表套元组 data [ (ORD001, 1001, 99.9, paid), (ORD002, 1002, 199.9, shipped), # ... 10万行 ] # 每2000行一批 batch_size 2000 for i in range(0, len(data), batch_size): batch data[i:ibatch_size] cursor.executemany( INSERT INTO user_order (order_id, user_id, amount, status) VALUES (%s, %s, %s, %s), batch ) conn.commit() # 显式提交 cursor.close() conn.close()避坑点executemany的第二个参数必须是list[tuple]不能是list[dict]否则报错PyMySQL默认不开启autocommit但显式设autocommitFalse更保险如果用SQLAlchemy优先用bulk_insert_mappings()而非session.add_all()后者仍是单条插入。Node.jsmysql2异步世界的批量艺术const mysql require(mysql2/promise); const pool mysql.createPool({ host: localhost, user: user, password: pass, database: test, waitForConnections: true, connectionLimit: 10, queueLimit: 0 }); async function batchInsert(orders) { const connection await pool.getConnection(); try { await connection.beginTransaction(); // 开启事务 const batchSize 1000; for (let i 0; i orders.length; i batchSize) { const batch orders.slice(i, i batchSize); // mysql2支持数组参数自动转为VALUES (),(),() await connection.execute( INSERT INTO user_order (order_id, user_id, amount, status) VALUES ?, [batch] // 注意这里必须是二维数组 ); } await connection.commit(); } catch (err) { await connection.rollback(); throw err; } finally { connection.release(); } }避坑点VALUES ?中的?是占位符[batch]必须是二维数组batch本身是[[v1,v2],[v3,v4]]mysql2的execute方法在传入数组时会自动展开为VALUES (v1,v2),(v3,v4)比手拼SQL安全得多务必用beginTransaction()commit()/rollback()autocommit:false在连接池里不生效。3.3 批量插入的“隐形杀手”索引、唯一约束与触发器的协同优化很多人以为“只要用了批量就万事大吉”结果上线后发现性能不升反降。罪魁祸首往往是表上的索引和约束。二级索引的写入代价InnoDB的聚簇索引主键写入是顺序的但二级索引如user_id索引是随机的。每插入一行就要在二级索引B树上找到对应位置可能触发页分裂。批量插入时这个代价被放大1000行数据如果user_id分布极散InnoDB要为每个user_id单独定位索引页IOPS飙升。解决方案有两个批量插入前临时删除非必要二级索引ALTER TABLE user_order DROP INDEX idx_user_id;插完再重建。重建索引比逐行维护快10倍。按索引字段排序后再插入比如按user_id升序排列数据让二级索引写入尽量顺序化。我实测过对一个有3个二级索引的表先ORDER BY user_id, status, create_time再批量插入比乱序插入快40%。唯一约束UNIQUE KEY的校验开销INSERT IGNORE或ON DUPLICATE KEY UPDATE看似方便但每行都要做唯一性校验。批量插入时这个校验是逐行进行的无法优化。如果你的业务允许“先插后去重”建议先用纯INSERT批量写入忽略重复错误再用DELETE或REPLACE清理重复数据。某次我们处理设备上报数据原始用INSERT IGNORE插10万行耗时156秒改为先INSERT允许报错再DELETE t1 FROM t1 INNER JOIN t2 ON t1.snt2.sn WHERE t1.id t2.id总耗时降到89秒。触发器TRIGGER的性能黑洞触发器是隐式执行的批量插入时BEFORE INSERT触发器会被调用N次N行数。如果触发器里有复杂计算或远程调用性能雪崩。生产环境批量插入必须禁用触发器SET OLD_SQL_MODESQL_MODE; SET SQL_MODENO_AUTO_VALUE_ON_ZERO; -- 执行你的批量INSERT SET SQL_MODEOLD_SQL_MODE;或者更彻底ALTER TABLE user_order DISABLE KEYS;仅对MyISAM有效InnoDB不支持所以还是用SET SQL_LOG_BIN0临时关闭binlog更通用。实操心得每次上线批量插入功能我必做三件事1.SHOW CREATE TABLE检查索引和约束2.EXPLAIN FORMATJSON分析INSERT语句的执行计划3. 在测试库用pt-query-digest抓取慢查询看是否有隐藏的UPDATE或DELETE被触发。这三步能避开80%的“明明批量了却更慢”的坑。4. 实操过程与核心环节实现从压测到上线的全流程详解4.1 压测方案设计用真实数据模拟线上流量洪峰批量插入的优化效果必须用压测说话。我设计了一套轻量但有效的压测流程不依赖JMeter等重型工具用Python脚本就能搞定。第一步构造符合业务特征的测试数据不能用UUID或随机数糊弄。比如订单表order_id要符合你的生成规则如时间戳机器码user_id要落在真实用户ID段内避免全表扫描amount要有合理分布大部分在10~200元少量大额。我用Faker库生成from faker import Faker fake Faker(zh_CN) orders [] for i in range(100000): orders.append(( fORD{fake.date_time_this_year().strftime(%Y%m%d%H%M%S)}{i%1000:03d}, fake.random_int(min100000, max9999999), round(fake.random_number(digits3) * 0.1, 2), fake.random_element([paid, shipped, cancelled]) ))第二步编写多线程压测脚本单线程压测没意义要模拟真实并发。用Python的concurrent.futures.ThreadPoolExecutorimport time from concurrent.futures import ThreadPoolExecutor, as_completed def insert_batch(batch_data): conn get_db_connection() # 复用之前的连接函数 start time.time() try: conn.executemany(sql, batch_data) conn.commit() finally: conn.close() return time.time() - start # 分片数据 batches [orders[i:i2000] for i in range(0, len(orders), 2000)] with ThreadPoolExecutor(max_workers8) as executor: futures {executor.submit(insert_batch, b): i for i, b in enumerate(batches)} total_time 0 for future in as_completed(futures): elapsed future.result() total_time elapsed print(f批次{futures[future]}耗时{elapsed:.2f}秒) print(f总计{len(orders)}行耗时{total_time:.2f}秒TPS{len(orders)/total_time:.0f})第三步监控关键指标压测时开着三个终端终端1mysqladmin -u root -p extended-status -r -i 1 | grep -E Com_insert|Innodb_buffer_pool_write_requests|Innodb_os_log_written看每秒写入量终端2iostat -x 1盯%util和await判断磁盘是否瓶颈终端3top看mysqld进程的CPU和内存占用。压测结论模板批次大小并发数总耗时(秒)TPSCPU峰值(%)磁盘await(ms)10082184588212.320008472127654.150008422380713.8100008492040898.7从表中一眼看出2000~5000行是最佳区间再大CPU和磁盘压力陡增得不偿失。4.2 上线前的 checklist一份不能跳过的生产环境核对清单批量插入上线不是改完代码就完事。我整理了一份血泪教训总结的checklist少一项都可能引发故障[ ]连接池配置确认最大连接数 ≥ 并发线程数 × 2避免连接等待。比如8线程连接池至少设20。[ ]事务超时设置在连接URL里加?connectTimeout30000socketTimeout60000防止网络抖动导致事务卡死。[ ]错误重试机制对Deadlock found或Lock wait timeout错误必须有指数退避重试最多3次不能直接抛异常。[ ]监控埋点在executeBatch前后打点记录批次大小、耗时、成功/失败行数接入Prometheus。[ ]回滚预案准备好DELETE FROM table WHERE create_time 2023-10-01 00:00:00的SQL放在应急文档里。[ ]灰度发布先对1%的流量开启批量观察5分钟无异常再逐步放量。[ ]备份验证上线前用mysqldump --single-transaction备份目标表确保能恢复。提示某次我们漏了“错误重试”线上遇到主从延迟突增INSERT因锁等待超时应用直接返回500导致上游重试形成雪球效应。后来加上重试逻辑同样的延迟场景系统自动重试2次后成功用户无感知。4.3 线上问题排查实录三个真实案例还原案例1为什么executemany比单条还慢现象Python脚本用executemany插1万行耗时120秒而单条execute只要95秒。排查用tcpdump抓包发现executemany发出的每个包只有2KB远低于网卡MTU1500字节。原来PyMySQL默认max_allowed_packet1024*10241MB但我们的数据单行平均150字节1万行需1.5MB超限后驱动自动降级为分片发送。解决连接时显式设置max_allowed_packet16*1024*1024耗时降至38秒。案例2LOAD DATA INFILE导入后SELECT COUNT(*)结果不准现象用LOAD DATA INFILE导入50万行SELECT COUNT(*)返回499998。排查SHOW WARNINGS发现两行Warning 1261 Field X doesnt have a default value。原来是数据文件里有空字段而表定义为NOT NULL且无默认值MySQL跳过了这两行。解决导入前用LOAD DATA INFILE ... IGNORE或先ALTER TABLE MODIFY COLUMN x VARCHAR(20) DEFAULT 。案例3批量插入后从库延迟飙升到2小时现象主库10万行2分钟插完从库Seconds_Behind_Master从0涨到7200。排查SHOW SLAVE STATUS\G看到Exec_Master_Log_Pos停滞Relay_Log_Space暴涨。用pt-heartbeat确认是SQL线程卡住。根因主库innodb_flush_log_at_trx_commit2从库sync_binlog1主库每秒刷一次log从库每条事务都刷盘IOPS跟不上。解决从库SET GLOBAL sync_binlog1000延迟立刻回落到10秒内。5. 常见问题与排查技巧实录一份来自战场的速查手册5.1 “批量插入”常见问题速查表问题现象可能原因排查命令解决方案Packet too large错误max_allowed_packet超限SELECT max_allowed_packet;调大该参数或减小批次大小插入速度忽快忽慢innodb_buffer_pool_size不足触发频繁刷盘SHOW ENGINE INNODB STATUS\G查BUFFER POOL部分增大缓冲池或降低批次大小主从延迟飙升从库sync_binlog1IOPS跟不上主库SHOW SLAVE STATUS\G查Seconds_Behind_Master从库设sync_binlog1000Deadlock found频繁报错批次过大锁范围太广SHOW ENGINE INNODB STATUS\G查LATEST DETECTED DEADLOCK减小批次按主键排序后插入INSERT IGNORE比普通INSERT慢唯一索引校验开销大EXPLAIN FORMATJSON分析执行计划改用先插后去重或临时删索引内存溢出OOM字符串拼接生成超大SQL对象top看Python/Java进程内存改用驱动协议级批量禁用字符串拼接5.2 独家排查技巧三招定位“看不见”的性能瓶颈技巧1用pt-query-digest抓取“幽灵查询”有时候慢的不是你的INSERT而是它触发的隐式操作。比如INSERT触发了BEFORE INSERT触发器触发器里又执行了UPDATE。用Percona Toolkit抓取pt-query-digest --filter $event-{arg} ~ m/^INSERT|^UPDATE/ /var/lib/mysql/slow.log看输出里是否有非你主动发起的UPDATE或DELETE它们就是性能黑洞。技巧2INFORMATION_SCHEMA.INNODB_TRX查长事务批量插入卡住先查是否有其他长事务在阻塞SELECT trx_id, trx_state, trx_started, trx_mysql_thread_id, TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) AS duration FROM INFORMATION_SCHEMA.IN
