UPDATE无WHERE时对全表所有行加X行锁，因InnoDB需聚簇索引全扫描逐行上锁，效果等同串行化访问；防误更新比防锁更重要。
UPDATE没WHERE时到底锁了什么
它不锁“全表”，但会锁“所有行”——准确说是对满足条件的每一行加X行锁。因为没WHERE，MySQL默认把整张表所有行都当作目标，逐行上锁再更新。InnoDB是行级锁引擎，不存在传统意义的“表锁”，但效果上等同于全表被串行化访问。
为什么不能只锁索引扫描范围内的行
没有WHERE子句，优化器无法利用索引做快速定位，只能走聚簇索引全扫描（即主键索引的完整B+树遍历）。这个过程会为每一条读到的记录加上X record lock。即使表有二级索引，也没法跳过主键查找——UPDATE最终必须定位到聚簇索引行才能改数据。
-
EXPLAIN FORMAT=tree可以看到执行计划里出现table_scan - 如果表用的是
MyISAM引擎，那确实是真·表锁，但那是另一回事 - InnoDB下，
SELECT * FROM t FOR UPDATE不加WHERE也会锁全表行，行为一致
LOW_PRIORITY 和 IGNORE 修饰符能缓解锁问题吗
不能。这两个修饰符不改变锁的粒度或范围：
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
-
LOW_PRIORITY只让UPDATE等待所有当前读操作完成，之后照样一行一行加锁更新 -
IGNORE是跳过报错行（比如唯一键冲突），但锁已经加了，且不影响其他行的锁定行为 - 它们都不减少锁数量，也不缩短持有时间
真正该防的不是“锁”，而是“误更新”
全表加锁只是副作用；更危险的是数据被批量覆写。线上执行前必须做三件事：
- 先跑
SELECT COUNT(*)确认影响行数是否符合预期 - 在事务里执行，用
START TRANSACTION+ROLLBACK预留撤回能力 - 对大表，考虑分批次更新，例如加
WHERE id BETWEEN ? AND ?配合循环
锁本身不可怕，可怕的是你根本没意识到自己正在锁并修改全部数据。
