批量插入时别直接套用 INSERT INTO ... VALUES (...)
单条循环
MySQL 在执行单条
INSERT时，每条都会触发日志写入、索引更新和事务开销。1000 条循环调用
INSERT，性能可能比批量写入慢 5–10 倍。
实操建议：
改用一条INSERT INTO t(col1,col2) VALUES (v1,v2), (v3,v4), ..., (vn,vm)，单语句最多塞 1000 行（受
max_allowed_packet限制，通常默认 4MB，约支持 500–1000 行普通字段） 显式开启事务：
BEGIN; INSERT ... ; INSERT ... ; COMMIT;，避免每条自动提交 临时关闭唯一键/外键检查（仅限可信数据）：
SET unique_checks=0; SET foreign_key_checks=0;，导入后再恢复
LOAD DATA INFILE
是批量导入的隐藏王者
当数据已存在本地文件（如 CSV），
LOAD DATA INFILE比任何
INSERT批量都快，通常快 5–20 倍，因为它绕过 SQL 解析层，直写存储引擎。
注意点：
文件必须在 MySQL 服务端磁盘上（不是客户端），路径需绝对，且 MySQL 进程有读权限 若用LOCAL版本（
LOAD DATA LOCAL INFILE），需服务端开启
local_infile=ON，且客户端连接时启用
allowLocalInfile=true（JDBC）或
--local-infile（mysql client） 字段分隔符、行结束符要对齐，例如：
FIELDS TERMINATED BY ',' LINES TERMINATED BY '\n'可配合
IGNORE或
REPLACE处理主键冲突，但会带来额外判断开销
函数滥用是批量操作的隐形瓶颈
在
UPDATE或
WHERE中大量使用运行时函数（如
DATE(created_at)、
UPPER(name)、
CONCAT(a,b)）会导致索引失效，全表扫描不可避免。
优化方向：
把计算逻辑提到应用层：比如查「今天创建的用户」，不要写WHERE DATE(created_at) = CURDATE()，改用
WHERE created_at >= '2024-06-15 00:00:00' AND created_at对固定转换场景建生成列 + 索引：如需频繁按月份聚合，可加
month_created DATE AS (DATE(created_at)) STORED并在该列建索引 避免在批量
UPDATE的
SET子句中调用子查询或自定义函数，尤其涉及多表关联时——先用
JOIN或临时表预计算好值再更新
批量更新/删除前务必加 LIMIT
和执行计划验证
没加
LIMIT的
UPDATE或
DELETE在大表上极易锁表、拖垮主从延迟，甚至触发 OOM kill。
安全做法：
先用EXPLAIN看执行计划，确认走了预期索引，
rows评估量级是否合理 分批操作：例如
UPDATE t SET status=1 WHERE status=0 AND id BETWEEN 10000 AND 20000 LIMIT 1000，配合 while 循环推进 避免
ORDER BY RAND()类操作参与批量更新，它强制全表扫描+临时表排序 如果用
IN (subquery)，确保子查询结果集小；否则换
JOIN写法，MySQL 8.0+ 对
IN的优化仍不稳定 实际批量操作中最容易被跳过的，是确认
autocommit状态和检查
innodb_buffer_pool_size是否撑得住——前者导致意外长事务，后者决定缓冲区能否缓存索引页，直接影响磁盘 I/O 次数。
