autocommit=1时单条UPDATE会隐式加行锁并立即释放；其本质是独立事务，锁仅存于语句执行期间，依赖索引加X锁，无索引则退化为表锁。
autocommit=1 时单条 UPDATE 自动加锁又自动释放
MySQL 默认开启自动提交（autocommit=1），此时每条 DML 语句（如 UPDATE、DELETE、INSERT）都会被当作一个独立事务执行：隐式开启 → 执行 → 隐式 COMMIT。锁确实产生了，但生命周期极短——只存在于语句执行期间，COMMIT 后立刻释放。所以你用 SHOW ENGINE INNODB STATUS 很难捕获，其他事务也基本感知不到。
容易踩的坑：
- 误以为“没写
BEGIN就没锁”，结果线上高并发下出现更新丢失或死锁，却查不到显式事务痕迹 - 在监控中看到锁等待，但
INFORMATION_SCHEMA.INNODB_TRX里查不到活跃事务，其实是锁已随自动提交消失 - 用 ORM（如 MyBatis）执行单条
updateById时，默认走的就是 autocommit 模式，锁来得快、去得更快
InnoDB 的行锁本质是“索引记录锁”，不是“语句开关”
行锁不是靠你写没写 FOR UPDATE 来决定要不要加，而是由 InnoDB 引擎根据操作类型和索引访问路径自动判断。只要语句修改了数据（UPDATE / DELETE），且 WHERE 条件命中了主键或唯一索引，InnoDB 就会对匹配的索引记录加排他锁（X 锁）——这个过程完全不依赖你是否手动 BEGIN。
关键点：
- 没索引？WHERE 条件走全表扫描 → 退化为锁所有行，效果接近表锁
- 走非唯一索引？可能加 Next-Key Lock（记录锁 + 间隙锁），范围比你想象的大
- 唯一索引等值更新（如
WHERE id = 123）→ 通常只锁单行，但仍是“隐式加锁”，你没写也存在
SELECT 不加锁，但 UPDATE 必然触发当前读和行锁
普通 SELECT 是快照读（Snapshot Read），走 MVCC，不加锁；而 UPDATE 是当前读（Current Read），必须读最新版本并加锁。这是隔离级别（默认 REPEATABLE READ）和引擎机制共同决定的，与你是否显式开启事务无关。
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
常见错误现象：
- 写了个“先
SELECT库存，再UPDATE扣减”的逻辑，以为两次语句是独立的 → 实际上SELECT不锁，UPDATE加锁但太晚，导致超卖 - 用
EXPLAIN看UPDATE走了索引，就认为“安全” → 忘了间隙锁也可能被触发（比如WHERE price > 99） - 在应用层加了分布式锁，却仍遇到数据库死锁 → 因为分布式锁只管业务入口，不管 InnoDB 内部的行锁竞争
如何验证“没 BEGIN 也有锁”？
最直接的方式是在两个会话中模拟并发更新，用 INFORMATION_SCHEMA.INNODB_LOCK_WAITS 和 INNODB_TRX 辅助观察（注意：autocommit 下锁释放太快，需用 SLEEP() 或长事务拉长时间窗口）：
-- 会话 A（开启事务，让锁停留更久） BEGIN; UPDATE product SET stock = stock - 1 WHERE id = 1; <p>-- 会话 B（autocommit=1，立即执行） UPDATE product SET stock = stock - 1 WHERE id = 1; -- 此时会被阻塞
这时查 INNODB_TRX，能看到会话 B 处于 LOCK WAIT 状态，而它的 trx_started 时间非常新——说明它虽未显式 BEGIN，但锁请求已被 InnoDB 接收并排队。
真正容易被忽略的，是 autocommit 模式下锁的“瞬时性”和“不可见性”：它真实存在，但像一次呼吸那样短，既难监控，又容易让人低估其并发影响。
