不是必须，但不加事务几乎一定会出错；例如100条更新中第50条失败，前49条已提交，破坏原子性，因此批量更新需显式开启事务确保全成功或全回滚。
MySQL批量更新必须用事务包裹吗？
不是必须，但不加事务几乎一定会出错。比如 100 条更新中第 50 条因主键冲突失败，前面 49 条已提交，后面 50 条没执行——这通常不是你想要的语义。
Go 的 database/sql 默认自动提交（autocommit），Exec 单条 SQL 就直接落盘。批量更新要“全成功或全回滚”，必须显式开启事务：
tx, err := db.Begin()
if err != nil {
return err
}
defer tx.Rollback() // 注意：仅占位，实际需按逻辑决定是否 Commit
_, err = tx.Exec("UPDATE users SET name = ? WHERE id = ?", "a", 1)
if err != nil {
return err // 不 return 的话，下面 Commit 会执行，导致脏数据
}
return tx.Commit() // 成功后才提交
- 别在
defer tx.Rollback()后直接写业务逻辑——defer 是函数退出时才执行，中间出错不阻断后续语句 - 事务生命周期应尽量短；长事务会持锁、拖慢其他查询
- 如果批量量极大（如 10 万行），别一股脑塞进一个事务——可能触发 MySQL
innodb_log_file_size限制或 OOM
用 VALUES + ON DUPLICATE KEY UPDATE 实现高效批量 Upsert
当目标是“存在则更新，不存在则插入”，INSERT ... ON DUPLICATE KEY UPDATE 比先查再判再更新快得多，且天然原子。
注意点：
立即学习“go语言免费学习笔记（深入）”；
- 表必须有
UNIQUE或PRIMARY KEY约束，否则ON DUPLICATE KEY不生效 - 占位符数量需严格匹配：每行 3 列，100 行就得拼出 300 个
?，不能复用参数 - MySQL 8.0.19+ 支持
VALUES(col_name)引用当前行值，避免重复写列名
示例（更新 name 和 age，冲突时用新值覆盖）：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
sql := `INSERT INTO users (id, name, age) VALUES (?, ?, ?), (?, ?, ?), (?, ?, ?)
ON DUPLICATE KEY UPDATE name = VALUES(name), age = VALUES(age)`
_, err := db.Exec(sql, 1, "x", 20, 2, "y", 22, 3, "z", 25)
动态拼接时务必校验参数总数，否则 sql.ErrInvalidArgCount 会在执行时报错，而非编译期。
批量更新用 Exec 还是 Prepare + Stmt.Exec？
用 Prepare + 复用 Stmt。尤其在循环中多次执行同类 SQL 时，能省掉 MySQL 端预处理开销和 Go 端语法解析成本。
- 单次批量（如一次传 500 行）用
db.Exec足够，代码更直白 - 高频小批量（如每秒几百次 10 行更新），必须
db.Prepare，否则连接池压力大、CPU 消耗明显上升 -
Stmt不是并发安全的，多 goroutine 共用需加锁，或每个 goroutine 自己Prepare
典型误用：
// ❌ 错误：每次循环都 Prepare，泄漏 stmt 资源且低效
for _, u := range users {
stmt, _ := db.Prepare("UPDATE users SET name=? WHERE id=?")
stmt.Exec(u.Name, u.ID)
stmt.Close() // 忘关也会 leak
}
// ✅ 正确：复用 stmt
stmt, _ := db.Prepare("UPDATE users SET name=? WHERE id=?")
defer stmt.Close()
for _, u := range users {
stmt.Exec(u.Name, u.ID)
}
WHERE IN 批量更新的参数长度限制怎么破？
MySQL 默认 max_allowed_packet 限制单次请求大小（通常 4MB），拼超长 WHERE id IN (?,?,...,?) 很容易触顶，报错 MySQL server has gone away 或 packet for query is too large。
- 硬拆分：把 10000 个 ID 拆成每批 500 个，循环执行 —— 简单可靠，适合离线任务
- 临时表：先
CREATE TEMPORARY TABLE tmp_ids(id BIGINT)，批量 INSERT ID，再UPDATE ... JOIN tmp_ids—— 适合超大批量且对延迟不敏感 - 别用字符串拼接 ID 列表（如
"IN (1,2,3)"）：SQL 注入风险，且无法复用预处理
临时表方案示例：
_, _ = db.Exec("CREATE TEMPORARY TABLE tmp_ids(id BIGINT PRIMARY KEY)")
// 批量插入 ID（同样注意 max_allowed_packet，需分片）
_, _ = db.Exec("INSERT INTO tmp_ids VALUES (?), (?)", ids...)
_, _ = db.Exec("UPDATE users u JOIN tmp_ids t ON u.id = t.id SET u.name = ? WHERE t.id = ?", "new", 0)
临时表只在当前连接可见，连接断开自动销毁，无需手动清理。
事务的边界、SQL 构造方式、参数分片策略——这三个地方任一选错，都会让“批量更新”变成线上事故的温床。特别是把业务逻辑塞进事务里做 HTTP 请求或文件读写，锁住数据库的同时还放大了失败面。
