sql_safe_updates=1可拦截无WHERE或无索引WHERE的UPDATE，要求WHERE含主键/唯一索引字段或带LIMIT；启用后执行SET sql_safe_updates=1并查SELECT @@sql_safe_updates确认返回1。
MySQL UPDATE带LIMIT会触发安全模式报错
当 SQL_SAFE_UPDATES=1（默认开启）时，MySQL 要求 UPDATE 必须满足：WHERE 条件含主键/索引列，或显式带 LIMIT。否则直接报错 ERROR 1175 (HY000): You are using safe update mode...。
这不是语法错误，而是客户端级防护。临时绕过可用：SET SQL_SAFE_UPDATES = 0;，但执行完务必设回 1 —— 否则后续无 WHERE 的误操作不会被拦截。
更稳妥的做法是：不关安全模式，而是补上 LIMIT 或确保 WHERE 中的字段有索引（哪怕只是加个 WHERE id > 0 再配 LIMIT）。
UPDATE LIMIT 不保证更新“第N行”，只取物理扫描前N行
UPDATE ... LIMIT 5 的含义是“最多更新扫描到的前5行”，不是“跳过前N行再更新”。LIMIT 1,1 在 UPDATE 中非法，会报语法错误。
想精确更新第2行？不能靠 LIMIT 偏移，得用子查询 + 衍生表绕过 MySQL 的“不能自查自改”限制：
UPDATE table_info
SET name = 'test1'
WHERE name IN (
SELECT Name FROM (
SELECT name AS Name FROM table_info ORDER BY id LIMIT 1, 1
) AS tmp
);
注意两点：ORDER BY 必须显式写，否则顺序不可控；内层子查询必须套一层别名（如 AS tmp），否则报错。
主从不一致风险：UPDATE + LIMIT 缺少 ORDER BY
在主从架构中，UPDATE ... WHERE status = 'pending' LIMIT 100 若没加 ORDER BY，主库和从库因存储引擎实现或数据分布差异，可能选中不同行，导致主从数据错位。
正确做法是绑定排序依据，优先用主键或唯一索引列：
UPDATE orders SET status = 'processing' WHERE status = 'pending' ORDER BY id ASC LIMIT 100- 避免用非索引字段排序（如
ORDER BY created_at），否则全表扫描+文件排序，性能差且锁更久
批量任务若需稳定分片，建议用主键范围切分（如 WHERE id BETWEEN 1000 AND 2000），比 LIMIT 更可控。
无索引字段 + LIMIT 仍可能锁全表
如果 WHERE 条件字段没索引，即使加了 LIMIT 1，MySQL 仍要走主键索引逐行扫描，过程中对**所有遍历过的行加行锁**。这意味着：
- 事务未提交前，其他事务更新这些已扫描行会被阻塞
- 虽然最终只改1行，但锁住的行数可能接近全表（尤其匹配行在末尾时）
-
INSERT不受影响，但对已锁行的UPDATE会卡住
所以，LIMIT 不是锁优化手段，索引才是。先确认 WHERE 字段是否命中索引（用 EXPLAIN 看 type 是否为 range 或 ref），再考虑加 LIMIT 作为兜底。
