安溪县住房和城乡规划建设局网站ftp网站模板

张

张建站

2026/4/19 8:37:31

10分钟阅读

安溪县住房和城乡规划建设局网站,ftp网站模板,做技术网站赚钱吗,网站正能量晚上在线观看MySQL 悲观锁 (Pessimistic Locking) 是数据库并发控制中的“重武器”。与乐观锁的“先斩后奏”#xff08;假设无冲突#xff0c;提交时检查#xff09;不同#xff0c;悲观锁的哲学是#xff1a;“假设冲突一定会发生#xff0c;所以在操作数据之前#xff0c;先把资…MySQL 悲观锁 (Pessimistic Locking)是数据库并发控制中的“重武器”。与乐观锁的“先斩后奏”假设无冲突提交时检查不同悲观锁的哲学是“假设冲突一定会发生所以在操作数据之前先把资源锁死谁也别想碰。”它直接依赖数据库底层InnoDB 引擎的锁机制通过SELECT ... FOR UPDATE等语句实现。在金融转账、高热点库存扣减等强一致性、高冲突场景下它是保障数据安全的最后一道防线。一、核心原理独占与阻塞1. 工作机制加锁事务在执行SELECT ... FOR UPDATE时InnoDB 会立即对查询到的行加上排他锁 (X 锁)。阻塞其他事务如果试图对这些行进行SELECT ... FOR UPDATE、UPDATE、DELETE操作会被强制阻塞 (Block)进入等待队列直到持有锁的事务提交 (Commit) 或回滚 (Rollback)。释放锁只在事务结束时释放。2. 前提条件必须开启事务START TRANSACTION或设置autocommit0。否则语句执行完立即提交锁瞬间释放毫无意义。必须走索引InnoDB 的行锁是加在索引记录上的。如果查询条件没有用到索引行锁会退化为表锁导致整个表被锁死性能灾难。核心洞察悲观锁的本质是**“串行化”**。它牺牲了并发度吞吐量换取了绝对的數據安全性和逻辑简单性无需重试。二、锁的粒度与类型不仅仅是行锁InnoDB 的悲观锁体系非常精细理解它们能避免很多坑。1. 记录锁 (Record Lock)定义锁定索引记录本身。场景SELECT * FROM t WHERE id 1 FOR UPDATE;效果其他事务不能修改或删除id1的记录。2. 间隙锁 (Gap Lock)定义锁定索引记录之间的间隙不包含记录本身。目的防止幻读 (Phantom Read)。即在同一个事务中禁止其他事务在当前锁定的范围内插入新数据。场景SELECT * FROM t WHERE id 10 AND id 20 FOR UPDATE;效果不仅锁住 11-19 的现有记录还锁住 (10, 20) 这个区间别人插不进id15的新数据。3. 临键锁 (Next-Key Lock)定义记录锁间隙锁的组合。锁定一个范围并且锁定记录本身。默认行为在RR (可重复读)隔离级别下InnoDB 的FOR UPDATE默认使用临键锁。风险如果范围很大或者索引区分度低可能锁住大量无关数据导致严重阻塞。4. 意向锁 (Intention Lock)定义表级锁表示“我马上要在这一行加锁了”。作用快速判断表是否可用无需遍历所有行。开发者通常无感知。三、PHP 实战代码库存扣减与转账场景 A高热点商品库存扣减 (秒杀)当冲突概率极高50%时乐观锁会导致大量重试消耗 CPU此时悲观锁更优。classStockService{private$pdo;publicfunctiondeductStockPessimistic($productId,$quantity){try{// 1. 开启事务$this-pdo-beginTransaction();// 2. 查询并加锁 (关键步骤)// 注意product_id 必须有索引否则会锁全表$stmt$this-pdo-prepare( SELECT stock FROM products WHERE id ? FOR UPDATE );$stmt-execute([$productId]);$row$stmt-fetch(PDO::FETCH_ASSOC);if(!$row){thrownewException(商品不存在);}if($row[stock]$quantity){thrownewException(库存不足);}// 3. 执行更新 (此时只有当前事务能操作该行绝对安全)$updateStmt$this-pdo-prepare( UPDATE products SET stock stock - ? WHERE id ? );$updateStmt-execute([$quantity,$productId]);// 4. 提交事务 (释放锁)$this-pdo-commit();returntrue;}catch(Exception$e){// 5. 异常回滚 (释放锁)if($this-pdo-inTransaction()){$this-pdo-rollBack();}throw$e;}}}场景 B银行转账 (A 转给 B)必须同时锁住两行防止死锁见下文。publicfunctiontransfer($fromId,$toId,$amount){$this-pdo-beginTransaction();try{// 关键按照 ID 从小到大顺序加锁避免死锁$ids[$fromId,$toId];sort($ids);// 一次性锁定两行$placeholdersimplode(,,array_fill(0,count($ids),?));$stmt$this-pdo-prepare( SELECT balance FROM accounts WHERE id IN ($placeholders) FOR UPDATE );$stmt-execute($ids);// ... 检查余额 ...// ... 执行 update ...$this-pdo-commit();}catch(Exception$e){$this-pdo-rollBack();throw$e;}}四、致命陷阱死锁 (Deadlock)悲观锁最大的敌人是死锁事务 A 持有资源 1 等待资源 2事务 B 持有资源 2 等待资源 1双方僵持。1. 经典死锁场景事务 A锁定id1- 尝试锁定id2。事务 B锁定id2- 尝试锁定id1。结果MySQL 检测到死锁强制回滚其中一个事务报错Deadlock found when trying to get lock。2. 解决方案固定顺序加锁如上例所示无论业务逻辑如何永远按照id从小到大或字典序的顺序获取锁。这是消除死锁最有效的方法。大事务拆小尽快提交事务减少持锁时间。降低隔离级别切换到RC (Read Committed)。在 RC 级别下InnoDB不使用间隙锁 (Gap Lock)只锁记录本身。这能大幅减少锁冲突和死锁概率互联网大厂常用策略。代价可能出现幻读但在大多数业务中可接受。3. 超时机制配置innodb_lock_wait_timeout默认 50 秒。如果等待超过该时间事务自动回滚避免无限期阻塞。建议在高并发系统中将此值调小如 3-5 秒让失败快速反馈以便应用层重试或降级。五、深度对比悲观锁 vs 乐观锁 vs Redis维度悲观锁 (FOR UPDATE)乐观锁 (Version)Redis 分布式锁/原子扣减核心机制数据库行锁 (阻塞)CAS 版本号 (重试)内存原子操作/Lua并发性能低(串行锁竞争)高(无锁但重试耗 CPU)极高(微秒级)适用场景写多读少冲突率 50%读多写少冲突率 10%超高并发(秒杀)抗流量冲击死锁风险有(需小心设计)无无 (需注意死键)实现复杂度低 (SQL 层面解决)中 (需代码重试逻辑)高 (需维护 Redis 集群/一致性)数据一致性强 (CP)强 (需重试成功)最终一致 (AP/CP 取决于配置) 选型指南普通业务后台管理、低频修改直接用悲观锁简单省心。一般并发商品详情页修改、用户信息用乐观锁性能好。超高并发双 11 秒杀、抢红包Redis 预扣减异步落库。千万别直接用 MySQL 悲观锁数据库会瞬间被打挂。六、避坑指南与最佳实践索引索引索引再次强调WHERE条件必须命中索引。错误示例SELECT * FROM orders WHERE status pending FOR UPDATE;(如果status没索引全表锁死)。正确示例SELECT * FROM orders WHERE id ? FOR UPDATE;避免长事务在BEGIN和COMMIT之间严禁调用外部 API、发送短信、处理复杂文件。这些操作会延长锁持有时间导致后续请求大面积超时。模式先查库加锁 - 计算 - 更新 - 提交 - (事务外) 发送通知。尽量缩小锁范围能锁一行别锁多行。能锁具体 ID别锁范围 (BETWEEN,)。范围锁极易触发间隙锁扩大锁定范围。监控死锁日志定期查看SHOW ENGINE INNODB STATUS中的LATEST DETECTED DEADLOCK部分。分析死锁原因调整 SQL 顺序或索引。读写分离注意事项悲观锁只能在主库执行。如果在读写分离架构中务必强制路由到 Master否则在 From 库加锁无效且可能报错。总结MySQL 悲观锁全景图维度核心要点行动指南本质独占与阻塞使用SELECT ... FOR UPDATE强行串行化前提事务索引无事务不锁无索引锁表风险死锁性能下降固定加锁顺序调小lock_wait_timeout优化RC 隔离级别考虑关闭间隙锁减少锁范围适用高冲突、强一致金融转账、热点账户修改、低频高价值库存终极心法悲观锁是数据库的“核威慑”。它威力巨大能保证绝对的安全但一旦滥用会造成系统的“核冬天”全面停滞。使用悲观锁的最高境界不是学会怎么写FOR UPDATE而是知道什么时候不写它。只有在冲突不可避免、数据价值极高、且无法承受重试成本的场景下才请出这尊大神。记住锁的范围越小持有时间越短系统的生命力就越旺盛。对于绝大多数互联网高并发场景请把悲观锁留给 Redis让 MySQL 专注于持久化和复杂查询。行动指令审查代码搜索项目中所有的FOR UPDATE检查是否走了索引事务内是否有耗时操作。调整顺序检查涉及多行更新的逻辑确保按固定顺序如 ID 升序加锁。评估隔离级别如果死锁频繁评估是否可以将核心表的隔离级别调整为READ COMMITTED。设置超时将innodb_lock_wait_timeout设置为合理值如 5-10 秒避免长时阻塞。压测演练模拟高并发冲突观察死锁日志和超时情况验证系统的自愈能力。这就是 MySQL 悲观锁以独占守底线以顺序避死锁于阻塞中求安稳于谨慎中见真章。