MySQL 8.0 的 NOWAIT 立即报错（ERROR 3572），不等待锁释放；SKIP LOCKED 则跳过被锁行，两者均用于 SELECT ... FOR UPDATE/SHARE，仅作用于行锁，适用于秒杀、任务分配等需快速失败或跳过的高并发场景。
NOWAIT 会直接报错，不是超时才报
MySQL 8.0 的 NOWAIT 不是把锁等待时间调短，而是彻底取消等待——只要目标行已被其他事务加锁（FOR UPDATE 或 FOR SHARE），当前语句立刻失败，返回错误码 ERROR 3572 (HY000)，而不是等几秒后抛 Lock wait timeout exceeded。这对高并发、低延迟敏感的业务（比如秒杀下单、库存预占）很关键：你宁可快速失败重试或降级，也不愿卡在数据库连接里干等。
-
NOWAIT只能用在锁定读语句末尾，例如SELECT ... FOR UPDATE NOWAIT或SELECT ... FOR SHARE NOWAIT - 必须显式开启事务（
START TRANSACTION或SET autocommit = 0），否则NOWAIT无效且不报错，但行为退化为普通非锁定读 - 错误信息固定为
ERROR 3572 (HY000): Statement aborted because lock(s) could not be acquired immediately and NOWAIT is set，应用层应明确捕获该错误码，而非泛化处理所有 SQL 错误 - 它只作用于行锁（record lock），对间隙锁（gap lock）或 next-key 锁无影响；若因 gap lock 导致无法插入/更新，
NOWAIT不起作用
什么时候该用 NOWAIT 而不是调小 innodb_lock_wait_timeout
调小 innodb_lock_wait_timeout（默认 50 秒）只是让等待更快结束，本质仍是阻塞；而 NOWAIT 是非阻塞设计。二者适用场景完全不同：
- 用
innodb_lock_wait_timeout：你确定冲突是偶发的、短暂的，且愿意为一次重试付出最多 N 秒的延迟（比如后台批处理） - 用
NOWAIT：你要求“立刻知道是否能抢到”，比如抢优惠券、分配任务 ID、生成唯一流水号——失败即刻走 fallback 流程（如返回“已抢完”、写入待调度队列），不能卡住请求线程 - 注意：
NOWAIT和innodb_lock_wait_timeout不互斥，但前者优先级更高；设了NOWAIT后，超时参数完全不生效
常见误用：在子查询或非锁定读里加 NOWAIT
NOWAIT 只对显式的锁定读生效。下面这些写法都无效：
kashen-mysql DDLtoExcel
下载
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
-
SELECT * FROM t1 WHERE id IN (SELECT id FROM t2 FOR UPDATE NOWAIT)—— 子查询里的NOWAIT不会传导到外层，且外层没加锁，整个语句不触发行锁 -
SELECT * FROM t1 WHERE id = 123 NOWAIT—— 缺少FOR UPDATE或FOR SHARE，NOWAIT被忽略（语法不报错，但无意义） -
UPDATE t1 SET status = 'done' WHERE id = 123 NOWAIT——NOWAIT不能用于UPDATE/DELETE，只支持SELECT ... FOR UPDATE/SHARE
真实响应率提升的关键不在语法，而在重试逻辑
光加 NOWAIT 不解决根本问题。真正提升响应率的是配套的快速失败 + 业务重试策略：
- 捕获
ERROR 3572后，不要简单重抛异常，而应立即尝试备选路径（如查缓存、走异步队列、返回兜底数据） - 避免“原样重试同一 SQL”——如果行还被锁着，重试只会再报一次 3572；要结合业务做退避（如随机延时）或换行（如用
SKIP LOCKED扫描可用记录） - 监控
ERROR 3572出现频次：持续高频说明热点行设计不合理（比如单行库存），该拆分数据粒度了
容易被忽略的一点：NOWAIT 的价值高度依赖事务边界。如果业务代码在捕获 3572 后没及时 rollback，而是继续执行其他语句，可能造成事务长期持有无关锁，反而加剧阻塞。务必保证失败分支能 clean up 当前事务。
