中国手工活加工官方网站网站开发项目方案书

中国手工活加工官方网站,网站开发项目方案书,公司简介模板英语,简述网站主要流程并发事务 A/B 如何避免互相影响#xff08;UPDATE 有交集#xff09;一、核心机制当事务 A、B 的 UPDATE 操作涉及同一批数据时#xff0c;MySQL#xff08;InnoDB#xff09;主要靠三类机制保证“不会互相把数据写乱”#xff1a;锁#xff08;Locking#xff09; UPDATE 有交集一、核心机制当事务 A、B 的UPDATE操作涉及同一批数据时MySQLInnoDB主要靠三类机制保证“不会互相把数据写乱”锁Locking写操作对目标记录加排他锁 X 锁同一时间只允许一个事务改同一行。隔离级别Isolation常见默认是RR可重复读配合MVCC处理读一致性写冲突则靠锁串行化。事务原子性与提交ACID要么全部成功提交要么全部回滚锁通常在COMMIT/ROLLBACK才释放在事务语句块内。二、具体场景两个事务同时转账同一账户行发生交集2.1正确写法假设表CREATE TABLE account ( id BIGINT PRIMARY KEY, balance INT NOT NULL ) ENGINEInnoDB;场景 1直接 UPDATE推荐写法天然加 X 锁事务 A给 id1 扣 80START TRANSACTION; UPDATE account SET balance balance - 80 WHERE id 1; COMMIT;事务 B同时给 id1 扣 50START TRANSACTION; UPDATE account SET balance balance - 50 WHERE id 1; COMMIT;并发时会发生什么本质A 执行到UPDATE ... WHERE id1时InnoDB 会对id1 这一行加X 锁。B 也要更新 id1因此它也要拿 id1 的 X 锁但拿不到只能等待或超时失败。ACOMMIT后释放锁B 才能继续。结果不会出现“两个事务互相覆盖写”的问题。写入顺序被锁强制串行化。2.1“看似正确但会出错”的写法先 SELECT 再 UPDATE1错误的原因不加锁的 SELECT 只是快照读例子START TRANSACTION; SELECT balance FROM account WHERE id1; //加一个FOR UPDATE会实现加X锁 UPDATE account SET balance20 WHERE id1; COMMIT;问题在于如果SELECT balance ...不带FOR UPDATE/LOCK IN SHARE MODE它通常是MVCC 一致性读快照读不会对数据行加行锁读到的 balance 可能是一个“当时的版本”之后再UPDATE并不能保证你基于刚才读到的值做决策时中间没被别人改过典型错误丢失更新Lost Update/ 读-改-写竞争。2正确做法读前锁定SELECT ... FOR UPDATE把读改成加锁读START TRANSACTION; SELECT balance FROM account WHERE id1 FOR UPDATE; -- 基于 balance 做业务判断 UPDATE account SET balance balance - 80 WHERE id1; COMMIT;这时FOR UPDATE会对匹配行加X 锁更准确说对访问到的记录加锁其他事务想改同一行会被阻塞你后续的业务判断和更新是“在锁保护下完成”的三、一条sql语句执行时Mysql做了什么1默认行为通常 MySQL 默认autocommit1这意味着每条语句本身就是一个独立事务语句开始隐式BEGIN语句结束隐式COMMIT因此锁的生命周期一般是语句执行期间持有语句结束立即释放单条语句场景四、不显式开启事务只执行普通 SELECT会做什么Q1SELECT id FROM user_score WHERE score 60;最常见情况InnoDB RR 普通 SELECT一致性读MVCC/快照读不加行锁不会锁住score 60的范围不阻塞并发 UPDATE/INSERT一般也不被并发写阻塞仍然会加 MDL元数据锁读锁所有访问表的语句都会拿 MDL结构层面的锁防止你在读的时候别人ALTER TABLE改结构在 autocommit 下语句结束释放结论普通 SELECT 不会锁住 score60 的数据行范围。五、Q2UPDATE 范围条件时是“同时锁住所有行”还是“边扫边锁”锁是行级还是页级Q2UPDATE user_score SET level level 1 WHERE score 60;结论边扫描边加锁逐条/逐段更细的执行节奏通常是语句开始隐式事务开始利用idx_score假设存在定位到第一个满足score 60的索引位置锁住当前索引记录record/next-key根据索引项定位到聚簇索引记录对数据行加X 锁执行更新移动到下一条索引记录重复 3~4扫描结束语句结束隐式 COMMIT释放锁锁的粒度主要是行级/索引记录级不是粗糙页锁InnoDB 的核心是记录锁record lock、间隙锁gap lock、Next-Key 锁recordgap在 RR 隔离级别下范围更新通常会涉及Next-Key 锁来防止幻读尤其是基于二级索引的范围条件这不是“整页锁住”而是“对索引记录及其间隙做锁定”粒度依然是索引/记录层面六、补充两个 UPDATE 有交集时的典型风险与处理1死锁Deadlock如果 A 更新行顺序是先 id1 再 id2B 更新顺序是先 id2 再 id1就可能互相等待形成死锁。InnoDB 会检测并回滚其中一个事务。2实务建议仅整理不改你的结论风格对同一批行的更新尽量保持一致的访问顺序例如按主键升序“先读后改”的逻辑尽量用SELECT ... FOR UPDATE或直接用单条原子 UPDATE 表达父表被引用列通常设计为PRIMARY或UNIQUE