批量插入性能优化的核心是减少开销，通过合并多行INSERT、使用事务、调整日志刷新策略、利用LOAD DATA INFILE及管理索引实现高效导入。
优化MySQL批量插入性能，核心在于减少单行操作的开销，这包括降低网络往返、SQL解析、事务日志写入以及索引更新的频率。简单来说，就是把多个小操作打包成一个大操作，让数据库能更高效地处理。
解决方案
要提升MySQL批量插入的性能，可以从几个关键点入手：
最直接有效的方法就是将多行数据合并到一条 INSERT
语句中。而不是每行一个
INSERT语句，我们应该用
INSERT INTO table (col1, col2) VALUES (v1, v2), (v3, v4), ...;这种语法。这样能显著减少客户端与服务器之间的网络往返次数，也降低了SQL解析和优化的开销。
其次，利用事务。把一系列批量插入操作包裹在一个事务里，即
START TRANSACTION; ... COMMIT;。这样，所有的修改操作会先在内存中进行，只在
COMMIT时才将日志刷新到磁盘，大大减少了磁盘I/O的频率。如果中间有任何一步出错，也可以
ROLLBACK，保证数据一致性。同时，记得在批量插入前禁用
autocommit，
SET autocommit=0;，然后在操作完成后再重新开启或手动
COMMIT。
再来，调整 innodb_flush_log_at_trx_commit
参数。这个参数直接关系到数据持久性和写入性能的平衡。默认值是1，表示每次事务提交时都会将日志同步刷新到磁盘，最安全但最慢。如果对数据丢失有一定容忍度（比如可以从源头重新导入），可以临时将其设置为0（每秒刷新一次日志）或2（每次提交时写入日志文件，但由操作系统决定何时刷新到磁盘）。操作完成后，务必将其改回默认值1。
对于极大规模的数据导入，LOAD DATA INFILE
是终极武器。它允许MySQL服务器直接从指定文件读取数据并导入，完全绕过了客户端-服务器的SQL语句传输开销，效率远超
INSERT语句。
最后，考虑索引的影响。尤其对于非唯一性二级索引，每次插入都会导致索引的更新。如果表上有大量二级索引，并且要插入的数据量非常庞大，可以考虑在导入前暂时禁用这些索引（对于InnoDB表，这通常意味着删除并重建，或者在
LOAD DATA INFILE配合
ALTER TABLE ... DISABLE KEYS/
ENABLE KEYS使用，但后者主要对MyISAM有效），导入完成后再重建。不过，对于InnoDB来说，通常优化批量插入本身的效果会更明显。
为什么批量插入通常比多次单行插入更高效？
这事儿说起来，其实就是“积少成多”的道理，但背后牵扯到的技术细节还挺多的。当我们一次性插入一行数据时，数据库需要做一系列固定的动作：比如，客户端得把SQL语句发给服务器（网络开销），服务器收到后得解析这条SQL，优化执行计划，然后检查权限，接着执行插入操作，这过程中还要更新日志文件（redo log、binlog），如果涉及事务，还得处理事务提交的逻辑，最后再给客户端返回结果。这一整套流程，每插入一行就得走一遍。
你想想看，如果我要插入一万行数据，用一万条单行
INSERT语句，那这些固定开销就得重复一万次。网络往返一万次，SQL解析一万次，事务日志刷新（如果
autocommit开启）也可能是一万次。这简直就是把时间都浪费在“路上”了。
但如果我把一万行数据打包成一条大的
INSERT ... VALUES (), (), ...语句，或者干脆用
LOAD DATA INFILE，那情况就完全不一样了。网络往返可能就几次，SQL解析也只有一次，事务日志的写入和刷新次数也会大大减少。数据库内部在处理这种批量操作时，它能更聪明地安排资源，比如一次性分配更大的内存缓冲区来处理数据，或者更高效地更新索引结构。这就像你寄快递，寄一个包裹和一次性寄一百个包裹，虽然东西多了，但去一趟快递站的成本是固定的，一次性寄肯定更划算。
如何平衡数据完整性与批量插入性能？
这事儿就得两头顾，性能固然重要，但数据要是错了或者丢了，那可就得不偿失了。平衡点主要落在事务管理和日志刷新策略上。
首先，事务是保障数据完整性的基石。批量插入时，务必使用
START TRANSACTION; ... COMMIT;将所有操作包裹起来。这样，即使在插入过程中某一行数据因为违反了唯一约束或其他原因导致失败，整个事务也可以回滚（
ROLLBACK），确保数据库回到操作前的状态，避免部分数据插入成功、部分失败的尴尬局面。这在业务逻辑上是极其重要的，可以防止脏数据或不完整的数据进入系统。
其次，就是前面提到的
innodb_flush_log_at_trx_commit参数。把它设置为0或2确实能提升性能，因为它减少了磁盘同步刷新的频率。但代价是，如果MySQL服务器或操作系统在日志没有完全写入磁盘前崩溃，那么最近几秒的数据更改就可能丢失。所以，在使用这个参数时，你得评估一下业务对数据丢失的容忍度。例如，如果你的批量数据是从一个可以重复生成或重新导入的源头来的，那么短时间的数据丢失风险可能可以接受。但如果是核心业务数据，比如金融交易，那哪怕一秒的数据丢失都不能接受，这时候就得老老实实地用默认值1，牺牲一点性能换取绝对的安全。
此外，错误处理机制也很关键。在应用层面，你需要有能力捕获批量插入可能产生的错误（比如重复键错误），并决定是跳过错误行继续插入，还是回滚整个批次。
INSERT IGNORE或
ON DUPLICATE KEY UPDATE语句可以在一定程度上帮助处理重复键冲突，但它们改变了默认的错误行为，使用时要清楚其副作用。
说到底，这个平衡点没有标准答案，它取决于你的具体业务场景、数据的重要性以及对性能和风险的权衡。
LOAD DATA INFILE
真的比 INSERT
语句快吗？什么时候用它？
答案是肯定的，LOAD DATA INFILE
在绝大多数情况下，尤其是在处理大量数据时，比 INSERT
语句快得多，通常是几个数量级的提升。
它之所以快，主要原因有几个：
-
绕过客户端-服务器通信开销： 当你使用
INSERT
语句时，每一条SQL语句（或每一批VALUES）都需要通过网络从客户端发送到服务器。这个过程涉及网络延迟、数据包的封装与解封装等。而LOAD DATA INFILE
允许MySQL服务器直接从它能访问的文件系统读取数据文件。这意味着数据传输发生在服务器内部，几乎没有网络开销。即使你使用LOAD DATA LOCAL INFILE
（客户端发送文件内容到服务器），这种传输也是高度优化的，并且服务器端解析文件内容的效率远高于解析多条SQL语句。 -
优化解析和处理：
LOAD DATA INFILE
是专门为高效导入结构化文件（如CSV、TSV）而设计的。它有专门的解析器，可以一次性读取大块数据，并以最快的速度将其转换为内部格式，然后插入到表中。相比之下，解析多条INSERT
语句的开销要大得多。 - 批量操作的优化： 它在内部也执行了类似的批量操作优化，比如一次性写入日志、更高效地更新索引等。
那么，什么时候应该使用 LOAD DATA INFILE
呢？
-
处理极大规模的数据导入： 如果你需要导入数百万甚至上亿行数据，
LOAD DATA INFILE
几乎是唯一能接受的方案。 -
数据源已经是文件： 当你的数据已经以CSV、TSV或其他文本文件格式存在时，使用
LOAD DATA INFILE
是最自然、最直接的方式。 -
对性能有极致要求： 在数据仓库、日志分析等场景，数据导入的速度直接影响到后续的数据处理和分析效率，这时
LOAD DATA INFILE
就显得尤为重要。 -
数据相对“干净”： 尽管
LOAD DATA INFILE
有IGNORE
选项来处理一些错误，但它最适合导入格式规范、数据质量较高的文件。如果文件格式混乱或数据有很多需要复杂处理的逻辑，可能还是需要通过应用程序先预处理。
不过，使用
LOAD DATA INFILE也有一些需要注意的地方：比如文件路径、权限问题（尤其是非
LOCAL模式下文件必须在服务器端）、字符集匹配、以及错误处理的灵活性相对较低。但总的来说，对于大批量数据导入，它的性能优势是无可比拟的。
