auto commit

notes/数据库系统原理.md

@@ -100,7 +100,7 @@ T<sub>1</sub> 读入某个数据，T<sub>2</sub> 对该数据做了修改，如
 
 ## 可串行化（SERIALIXABLE）
 
-强制事务串行执行，避免幻行的出现。
+强制事务串行执行，避免幻读。
 
 # 可串行化调度
 
@@ -108,7 +108,7 @@ T<sub>1</sub> 读入某个数据，T<sub>2</sub> 对该数据做了修改，如
 
 # 封锁类型
 
-排它锁 (X 锁 )，共享锁 (S 锁 )
+排它锁 (X 锁），共享锁 (S 锁）
 
 一个事务 T 对数据对象 A 加了 X 锁，T 就可以对 A 进行读取和更新。加锁期间其它事务不能对数据对象 A 加任何其它锁；
 
@@ -124,26 +124,26 @@ T<sub>1</sub> 读入某个数据，T<sub>2</sub> 对该数据做了修改，如
 
 ## 三级封锁协议
 
-(1) 1 级封锁协议
+<div align="center"> <img src="../pics//785806ed-c46b-4dca-b756-cebe7bf8ac3a.jpg"/> </div><br>
+
+**1 级封锁协议** 
 
 事务 T 要修改数据 A 时必须加 X 锁，直到事务结束才释放锁。
 
 可以解决丢失修改问题；
 
-(2) 2 级封锁协议
+**2 级封锁协议** 
 
 在 1 级的基础上，要求读取数据 A 时必须加 S 锁，读取完马上释放 S 锁。
 
 可以解决读脏数据问题，因为如果一个事务在对数据 A 进行修改，根据 1 级封锁协议，会加 X 锁，那么就不能再加 S 锁了，也就是不会读入数据。
 
-(3) 3 级封锁协议
+**3 级封锁协议** 
 
 在 2 级的基础上，要求读取数据 A 时必须加 S 锁，直到事务结束了才能释放 S 锁。
 
 可以解决不可重复读的问题，因为读 A 时，其它事务不能对 A 加 X 锁，从而避免了在读的期间数据发生改变。
 
-<div align="center"> <img src="../pics//785806ed-c46b-4dca-b756-cebe7bf8ac3a.jpg"/> </div><br>
-
 ## 两段锁协议
 
 加锁和解锁分为两个阶段进行。两段锁是并行事务可串行化的充分条件，但不是必要条件。
@@ -164,7 +164,7 @@ Java synchronized 就属于悲观锁的一种实现，每次线程要修改数
 
 假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性。
 
-Java JUC 中的 atomic 包就是乐观锁的一种实现，AtomicInteger 通过 CAS（Compare And Set）操作实现线程安全的自增。
+Java JUC 中的 Atomic 包就是乐观锁的一种实现，AtomicInteger 通过 CAS（Compare And Set）操作实现线程安全的自增操作。
 
 乐观锁有两种实现方式，数据版本和时间戳。它们都需要在数据库表中增加一个字段，使用这个字段来判断数据是否过期。例如，数据版本实现方式中，需要在数据库表中增加一个数字类型的 version 字段，当读取数据时，将 version 字段的值一同读出。随后数据每更新一次，对此 version 值加 1。当提交更新的时候，判断读出的 version 和数据库表中的 version 是否一致，如果一致，则予以更新；否则认为是过期数据。
 
@@ -174,7 +174,7 @@ MySQL InnoDB 采用的是两阶段锁协议。在事务执行过程中，随时
 
 另外，InnoDB 也支持通过特定的语句进行显示锁定，这些语句不属于 SQL 规范：
 
-- ELECT ... LOCK IN SHARE MODE
+- SELECT ... LOCK IN SHARE MODE
 - SELECT ... FOR UPDATE
 
 # 范式