去国外做赌钱网站定制网站制作费用

去国外做赌钱网站,定制网站制作费用,太原做手机网站,wordpress 目录别名MySQL 事务的原理#xff08;ACID#xff09;关键词#xff1a;ACID、redo log、undo log、锁、MVCC、隔离级别。 目标#xff1a;搞清楚“事务是什么、为什么能回滚、为什么能隔离”。一、什么是事务#xff1f; 在 MySQL#xff08;主要指 InnoDB 引擎#xff09;中ACID关键词ACID、redo log、undo log、锁、MVCC、隔离级别。目标搞清楚“事务是什么、为什么能回滚、为什么能隔离”。一、什么是事务在 MySQL主要指 InnoDB 引擎中**事务Transaction**就是一组要么全部成功、要么全部失败的操作。典型例子转账A 给 B 转 100 元 1A 账户减 100 2B 账户加 100这两个更新必须要么都成功要么都不生效否则就会出现“钱凭空出现或消失”的情况。事务就是为了保证这类操作的整体性和安全性。数据库里对事务的要求就是那 4 个字母ACID。二、ACID 四大特性概览ACID 是事务必须满足的四个特性原子性Atomicity一致性Consistency隔离性Isolation持久性Durability下面分别说是什么 MySQLInnoDB是怎么做到的。三、A原子性Atomicity3.1 概念原子性 事务中的操作要么全部成功要么全部失败。不存在“只执行了一半”的状态对外可见。转账例子A 减了 100B 没加 100 ⇒ 不允许A 没减B 加了 100 ⇒ 也不允许要么两个操作都成功要么都回滚。3.2 InnoDB 如何实现原子性—— 依靠 undo logInnoDB 在执行更新前会先记录一份“之前的数据”到undo log回滚日志如果事务回滚就根据 undo log 把数据恢复到修改前的样子。举个简单例子原始A 1000 事务中UPDATE account SET balance balance - 100 WHERE id A;内部分两部分把 A 从 1000 改成 900在 undo log 里记录一条信息A 的 balance 从 1000 改成 900可以还原为 1000。如果事务失败 / 回滚通过 undo log 把 balance 从 900 改回 1000对外看起来就像这个事务从来没发生过一样。小结undo log 是实现事务回滚的关键有了 undo log才能保证“要么全做要么全不做”的原子性。四、C一致性Consistency4.1 概念一致性 事务前后数据库从一种合法状态转换到另一种合法状态。“合法状态”通常指满足各种约束主键约束、唯一约束、外键约束、检查约束等满足业务规则比如总资产 各账户余额之和不允许负数账户等。一致性是一个结果属性它依赖于原子性、隔离性、持久性 应用自身的业务逻辑一起保障。常见例子转账过程中的中间状态比如 A 已减、B 未加是不会对外暴露的事务提交成功后数据必须满足各种约束条件否则会回滚。4.2 约束失败导致事务回滚比如CREATETABLEuser(idINTPRIMARYKEY,nameVARCHAR(20)UNIQUE);如果事务中插入了两个相同 name 的用户STARTTRANSACTION;INSERTINTOuser(id,name)VALUES(1,Tom);INSERTINTOuser(id,name)VALUES(2,Tom);-- 冲突COMMIT;-- 提交时发现唯一约束冲突这个事务会失败并回滚不一致的数据不会被提交。小结一致性更多依赖于数据库的各种约束 应用层逻辑 事务本身的 A / I / D。MySQL 负责在约束被破坏时让事务提交失败从而保证最终一致性。五、I隔离性Isolation5.1 概念隔离性 并发执行的多个事务之间在一定程度上互相“隔离”互不干扰。理想情况多个事务并发执行的结果应该等价于某种顺序串行执行的结果。这就是所谓的“可串行化Serializable”。但完全串行执行会让性能掉死所以数据库提供了多个隔离级别在“性能”和“隔离性”之间做平衡。5.2 隔离级别四种SQL 标准定义了 4 个隔离级别MySQL InnoDB 全支持READ UNCOMMITTED读未提交READ COMMITTED读已提交REPEATABLE READ可重复读——MySQL InnoDB 默认SERIALIZABLE串行化5.2.1 读未提交READ UNCOMMITTED问题可能出现脏读Dirty Read读到别的事务还没提交的修改。一般不开这个级别。5.2.2 读已提交READ COMMITTED特点只能读到已经提交的数据避免了脏读。问题可能出现不可重复读Non-Repeatable Read同一个事务中两次查询同一行数据结果可能不一样。5.2.3 可重复读REPEATABLE READ——InnoDB 默认特点同一个事务里多次读取同一行数据结果保持一致避免了脏读 不可重复读。问题仍然可能出现幻读Phantom Read同一个事务中多次按条件查询行数可能不一样有新插入的数据“凭空出现”。InnoDB 在这个级别下通过MVCC 间隙锁Next-Key Lock组合手段来“解决/缓解”幻读问题。5.2.4 串行化SERIALIZABLE特点强制所有事务串行执行或者在读写时加上更严格的锁隔离性最好但并发能力最差一般只在对数据一致性要求极端严格且并发不高时使用。5.3 InnoDB 如何实现隔离—— MVCC 锁隔离性背后有两套核心机制MVCC多版本并发控制锁行锁、间隙锁、意向锁等5.3.1 MVCC多版本并发控制MVCC 的目标在大多数“读”的场景下让读操作不阻塞写写操作也尽量不阻塞读。做法每行记录有多个版本通过undo log隐藏列来实现每个事务在开始时会拿到一个“事务 ID”并创建一致性视图Read View读数据时根据事务 ID 行的版本信息找到对当前事务可见的版本。通俗理解写数据时会产生新版本旧版本保留在 undo log 中读数据时如果当前最新版本对该事务不可见就去看更早的版本“读已提交 / 可重复读”的区别就是“视图”是每次查询新建还是事务开始时固定。5.3.2 锁简单按粒度分行锁锁某一行记录间隙锁Gap Lock锁一个范围间隙防止插入Next-Key Lock行锁 间隙锁锁[前一个值, 当前值]区间表锁锁整张表InnoDB 也有但事务中一般用的是行锁间隙锁。按用途分共享锁S 锁读锁可多事务共享排他锁X 锁写锁互斥。InnoDB 默认是行级锁 MVCC查询时尽量通过 MVCC 读取“历史版本”避免加锁修改时才会加行锁 / 间隙锁保证并发修改不会乱。小结MVCC 负责“读写互不挡”锁负责“写写不乱 控制插入/删除范围”两者配合实现各种隔离级别。六、D持久性Durability6.1 概念持久性 一旦事务提交它对数据库所做的修改就是永久性的即使发生故障也不会丢失。比如事务提交成功 → 服务器立刻宕机 → 重启后已提交的数据仍然存在。6.2 InnoDB 如何实现持久性—— redo log binlog主要依赖两类日志redo log重做日志—— InnoDB 引擎级别binlog二进制日志—— MySQL Server 层级别6.2.1 redo log物理日志保证崩溃恢复记录的是“对某个数据页做了怎样的物理改动”写入顺序追加I/O 顺序性较好在事务提交前相关的 redo log 必须刷到磁盘或根据参数控制刷盘策略。简化流程事务执行期间修改内存中的数据页Buffer Pool生成 redo log 写入 redo 日志缓冲区事务提交时至少要保证 redo log 已经刷新到磁盘取决于innodb_flush_log_at_trx_commit设置崩溃恢复重启时读取 redo log根据其内容重新把“已经提交但尚未写入磁盘的数据页”恢复出来。有 redo log在“先改内存、后刷磁盘”的情况下仍能保证事务一旦提交就不会丢。6.2.2 binlog逻辑日志主从复制 恢复用记录的是“SQL 语句或行级别的逻辑变更”是 MySQL Server 层的日志不只 InnoDB 使用常用于主从复制、数据恢复如mysqlbinlog回放。6.2.3 redo log binlog 两阶段提交为保证事务提交后既不会丢依赖 redo log又能被正确复制到从库/用于恢复依赖 binlogInnoDB 使用两阶段提交机制协调 redo log 和 binlog大致过程写入 redo log标记为prepare状态写入 binlog将 redo log 标记为commit状态这样崩溃恢复时如果 redo 是 prepare 而 binlog 不完整可以回滚如果 redo 是 commit说明 binlog 也已经写好了可以重放。小结redo log保证“崩溃恢复”级别的持久性binlog保证“复制 / 审计 / 逻辑恢复”两者配合 两阶段提交确保事务提交后既不丢又能被正确复制与恢复。七、ACID 与 MySQL 关键机制的对应关系可以简单打个表特性主要依赖的机制原子性 Aundo log回滚日志、崩溃恢复流程一致性 C约束PK/UK/FK 等 应用逻辑 A/I/D 综合效果隔离性 I锁行锁、间隙锁 MVCC 隔离级别持久性 Dredo log binlog 刷盘策略 两阶段提交注意一致性并不是由某一个内部机制直接保证而是 ACID 四个特性 业务规则共同保证。八、总结从“表面行为”到“内部原理”事务是什么一组操作的逻辑整体要么全部成功、要么全部失败。为什么能回滚因为有undo log记录了修改前的值。为什么不会互相乱改因为有锁控制并发写有MVCC让读尽量不用加锁又能看到一致视图。为什么断电后数据还在因为有redo log刷盘重启时可以根据 redo 把已经提交的数据恢复出来。为什么叫 ACIDAundo log 支撑回滚 → 原子性C约束 逻辑 A/I/D 综合保证一致性I锁 MVCC 隔离级别控制并发可见性Dredo log binlog 两阶段提交保证持久性。理解 ACID 背后的这些“日志 锁 版本”的组合拳你基本就把 MySQL 事务的核心原理拿下来了。