可用，但仅限单表UPDATE且必须带WHERE条件；多表UPDATE不支持LIMIT，强行使用会报错ERROR 1221；它仅控制最多影响行数，不能替代WHERE防误操作。
MySQL 8.0 中无法用 LIMIT 直接限制多表 UPDATE 的行数，单表 UPDATE ... LIMIT N 虽然语法合法，但**不能作为防误操作的可靠手段**——它不保证“安全”，只控制“最多改几行”，且在事务、并发、索引缺失等场景下行为难预测。
单表 UPDATE LIMIT 在 8.0 中是否可用？
可用，但有严格前提：
- 必须是纯单表语法，例如
UPDATE orders SET status = 'archived' WHERE created_at ；一旦出现 <code>JOIN、子查询（哪怕只是FROM子句）、别名表，LIMIT就会被忽略或报错ERROR 1221 (HY000): Incorrect usage of UPDATE and LIMIT - 不依赖索引时，
LIMIT仍会触发全表扫描——性能差，且“前 N 行”无业务意义（InnoDB 没有固定物理顺序） -
LIMIT不阻断语句执行，只截断影响行数。如果 WHERE 条件漏写或写错，它可能默默改掉 100 行“错误数据”，而非报错中止
真正防误更新的三道防线
靠 LIMIT 防全表更新是幻觉。实际应组合使用：
-
预查 + 行数校验：先执行
SELECT COUNT(*) FROM table WHERE ...，确认结果集大小合理（比如预期 10 行，结果返回 10 万行就立刻中止） -
显式事务 + 低隔离级别检查：用
BEGIN; SELECT ... FOR UPDATE;锁定目标行并观察数量，再执行UPDATE，出错可回滚 -
权限级硬隔离：对普通账号直接
REVOKE UPDATE ON db_name.table_name FROM 'user'@'host'，只授SELECT或通过存储过程封装写逻辑（强制审批/日志）
需要按条件取“最新 N 条”更新怎么办？
必须绕过原生 LIMIT，用 ROW_NUMBER() 子查询模拟，但要注意：
- 排序字段必须有索引，否则
ROW_NUMBER() OVER (ORDER BY updated_at DESC)会全表扫描+临时表，慢且锁表 - 不能直接
UPDATE同一子查询中的表，必须套两层：外层UPDATE ... JOIN (SELECT id FROM (...)) t2 ON ... - 示例（更新最近 5 条 pending 订单）：
UPDATE orders o JOIN ( SELECT id FROM ( SELECT id, ROW_NUMBER() OVER (ORDER BY created_at DESC) AS rn FROM orders WHERE status = 'pending' ) t WHERE rn <= 5 ) t2 ON o.id = t2.id SET o.status = 'processing';
为什么别信“加个 LIMIT 就安全了”
因为 MySQL 的 LIMIT 是执行器层面的截断，不是优化器层面的过滤。它不参与执行计划生成，不触发统计信息校验，也不做权限上下文检查。一个没写 WHERE 的 UPDATE ... LIMIT 1 仍会扫描全表找第一行——这行可能是任意数据，且过程中已加锁、已写 binlog、已触发触发器。真正的防护点永远在事前（权限、预查、事务）和事后（审计日志、只读从库验证），不在那个看似可控的数字上。
