能，MySQL UPDATE ... WHERE 语句在 WHERE 条件命中唯一索引或主键时加行级 record lock；否则可能升级为 gap lock、next-key lock 或锁表。应确保条件字段建唯一索引、避免函数导致索引失效、用 EXPLAIN 验证执行计划，并采用原子 UPDATE + stock > 0 判断影响行数来防止超扣。
MySQL UPDATE ... WHERE 语句真能锁住要更新的行吗？
能，但前提是 WHERE 条件命中了**唯一索引或主键**。如果用 WHERE prize_id = 123，而 prize_id 是主键或有唯一索引，InnoDB 会加 **record lock**（单行记录锁）；如果条件走的是非唯一索引、或者没索引，可能升级为 gap lock 或 next-key lock，甚至全表扫描+锁表，反而拖垮并发。
实操建议：
- 确保扣减奖品的查询字段（如
id或prize_code）建了唯一索引，别依赖业务层“以为它唯一” - 避免在
WHERE中用函数，比如WHERE MD5(prize_code) = 'xxx'—— 索引失效，锁范围失控 - 执行前用
EXPLAIN看执行计划，确认type是const或eq_ref，key显示用了哪个索引
为什么不能先 SELECT 再 UPDATE？
因为 SELECT 默认不加锁（即使加了 FOR UPDATE，也得在事务里且隔离级别配合），中间存在时间窗口：两个请求同时查到“剩余 1 个”，都判定可中奖，接着都去 UPDATE，最终库存变成 -1。
正确做法是跳过查询，直接用原子语句扣减并判断影响行数：
UPDATE prizes SET stock = stock - 1 WHERE id = 123 AND stock > 0;
然后检查 MySQL 返回的 affected_rows：
-
affected_rows == 1：扣减成功，可以发奖 -
affected_rows == 0：要么奖品不存在，要么stock ，不可中奖
这个语句本身带条件判断+更新，且因主键定位，只锁目标行，不阻塞其他奖品操作。
事务隔离级别选 READ COMMITTED 还是 REPEATABLE READ？
选 READ COMMITTED。在 REPEATABLE READ 下，同一事务内多次执行相同 SELECT ... FOR UPDATE 可能复用快照，导致幻读或重复加锁；而 READ COMMITTED 每次读都获取最新版本，配合行锁更干净。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
更重要的是：READ COMMITTED 下，InnoDB 的 next-key lock 行为被削弱，gap lock 更少，锁冲突概率下降 —— 对抽奖这种短事务、高并发场景更友好。
设置方式（连接级）：
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
注意：别在全局改，会影响其他业务模块。
超卖还是发生了，是不是锁没起作用？
大概率不是锁失效，而是应用层没正确处理返回值或事务没包住关键逻辑。常见坑点：
- 没检查
UPDATE的affected_rows，只看 SQL 是否报错 —— 库存不足时UPDATE不报错，只是不更新 - 事务开启后，先做了其他无关 DB 操作（比如写日志表），再执行扣减，拉长了锁持有时间
- 连接池配置不合理，一个连接被复用但事务没及时 commit/rollback，导致后续请求被意外阻塞
- 用 ORM（如 MyBatis、Sequelize）时，自动注入的动态 SQL 拼错了条件，导致
WHERE失效，锁了不该锁的行甚至全表
最稳妥的兜底是：在应用层对同一奖品 ID 做本地限流（比如 Guava RateLimiter + prize_id 为 key），不解决根本问题，但能快速压住突发流量下的误判尖峰。
行级锁不是银弹，它只保证“同一行不被两个事务同时改”，但库存是否够、要不要发奖、发奖失败怎么回滚——这些逻辑必须由原子 SQL 和严谨的返回值判断共同守住。漏掉任一环，锁就形同虚设。
