select ... for update 会阻塞其他事务，因其在innodb中加排他锁且未提交前不释放；应确保走主键/唯一索引、及时提交、避免在phpmyadmin中长时间持有锁。
SELECT ... FOR UPDATE 为什么会阻塞其他事务
在 InnoDB 中，SELECT ... FOR UPDATE 不是“读操作”，而是显式加排他锁（X锁）的写前准备动作。它会锁定扫描到的索引记录（或间隙、临键锁），只要事务未提交，这些锁就一直持有。其他事务若尝试对同一行做 UPDATE、DELETE 或再次 FOR UPDATE，就会被挂起等待——这就是阻塞的根源。
常见误判是认为“我只是查一下”，但加了 FOR UPDATE 就等于占着资源说“我要改”，数据库必须保障隔离性，不会让别人动。
- RR（可重复读）隔离级别下，默认用
Next-Key Lock，可能锁住记录+间隙，范围比预期更大 - 没走索引的
FOR UPDATE会升级为全表扫描+全表加锁，阻塞面极广 - 长事务中迟迟不
COMMIT，等于长期霸占锁，下游所有依赖该行的操作都会排队
怎么写 FOR UPDATE 才不容易拖垮别人
核心原则：锁得少、锁得准、放得快。不是不用 FOR UPDATE，而是让它只做它该做的事。
- 确保 WHERE 条件命中**主键或唯一索引**，避免全表扫描；执行前用
EXPLAIN确认type是const或eq_ref - 只 SELECT 必需字段，不要
SELECT *——虽然不影响锁范围，但减少网络和内存开销，间接缩短事务时间 - 紧跟
FOR UPDATE后立刻做 UPDATE/DELETE，然后马上COMMIT；不要在中间穿插 HTTP 请求、日志打印、远程调用等耗时操作 - 如果只是防并发读取旧值（比如查余额后扣减），且业务允许短暂不一致，可改用
SELECT ... LOCK IN SHARE MODE+ 应用层 CAS 逻辑，降低冲突概率
phpMyAdmin 里执行带锁语句的实操红线
phpMyAdmin 本身不提供事务自动提交开关，所有 SQL 都在默认 autocommit=1 下单条执行——但这恰恰是陷阱：你手动输 BEGIN; SELECT ... FOR UPDATE; 后，如果不主动点「提交」按钮或输 COMMIT，事务就一直开着，锁就一直挂着。
- 别依赖 phpMyAdmin 的「刷新页面」来结束事务：页面刷新不等于 COMMIT，锁还在
- 执行
FOR UPDATE前，先在 SQL 标签页里跑一遍SELECT确认数据存在且符合预期，避免因条件不匹配导致空锁或误锁 - 生产环境严禁在 phpMyAdmin 里执行带锁语句后离开；临时调试务必配
SET innodb_lock_wait_timeout = 3;缩短等待上限，防止无限卡死 - 如需批量处理，绝不要写循环
FOR UPDATE → UPDATE → COMMIT；应合并为单条UPDATE ... WHERE id IN (...)，由 MySQL 内部优化锁粒度
真要高并发防超卖，别只靠 FOR UPDATE
单靠 FOR UPDATE 在秒杀类场景下极易成为瓶颈：锁竞争激烈、事务排队、响应延迟飙升。它适合低频、强一致性要求的场景（如银行转账），不适合高频写入。
- 优先考虑应用层预扣减（Redis 计数器）+ 最终一致性校验，把压力从 DB 搬到缓存
- 数据库侧可用「乐观锁」：加
version字段，UPDATE ... SET stock = stock - 1, version = version + 1 WHERE id = ? AND version = ?，失败则重试 - 极端情况用「分段库存」：把一个商品拆成 10 个逻辑子库存，分散锁竞争，再由应用聚合最终结果
真正容易被忽略的是：FOR UPDATE 的阻塞往往不是语句本身写错了，而是它嵌套在了一个本不该由 phpMyAdmin 承担的业务流程里——比如把订单创建、库存扣减、日志落库全压在一个手动事务里。这种操作在生产环境里，相当于拿手术刀给核反应堆调参数。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
