批量插入应避免单条循环INSERT，改用多值INSERT、显式事务、禁用约束检查或LOAD DATA INFILE；UPDATE/WHERE中慎用运行时函数以防索引失效。
批量插入时别直接套用 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 次数。 
