南大通用GBase 8s数据库（gbase database）解决事务并发问题，锁机制用于协调并发访问，防止多个事务同时操作数据导致的数据不一致。

对写锁而言，只要是写操作无论如何都一定是会上锁的，而对于读锁，则要通过隔离级别的来进行控制。

对读锁的使用，在并行操作时会出现以下三个问题：

• 脏读：读取未提交的数据。事务 T1 修改了数据但尚未提交，事务 T2 读取了这些未提交的数据。如果 T1 随后回滚，T2 读取到的数据就成为无效的“脏”数据。
• 幻读：结果集记录数变化事务 T2 按照特定条件检索数据。在 T2 未结束前，事务 T1 插入了符合 T2 查询条件的新记录，导致 T2 再次查询时结果集中出现新增。
• 不可重复读：事务内读取结果不一致在同一事务 T2 中，第一次读取某数据后，事务 T1 修改并提交了该数据。结果是，事务 T2 再次读取该数据时，得到的结果与之前不同。

隔离级别就是为了明确哪些问题是被允许的，它代表的是数据库对不同并发异常的容忍程度，并且对应着不同的读锁的使用策略。

GBase 8s 提供的隔离级别

dirty read 脏读

脏读是最低的数据库隔离级别，允许事务读取其他事务尚未提交的数据，可能导致数据不一致。上面提到的三个并发问题都存在，所以在实际的应用场景中，很少直接使用脏读隔离级别，通常只在对数据一致性要求极低、只读事务或内部系统维护时考虑。

而对它的加锁机制，脏读隔离级别通常不使用任何显式的共享锁来防止脏读发生。读取时无锁，写入时排他锁不阻止其他事务读取。

大多数实际应用中，应选择读已提交、可重复读或串行化等更高级别的隔离级别，以确保数据的正确性。

committed read 读已提交

事务只能读取已提交的数据，不会读取到其他事务尚未提交的数据。这种隔离级别避免了脏读问题，保证读取数据的有效性，提高数据可靠性。但是存在不可重复读和幻读问题，可能导致事务内多次读取数据的不一致。适用于对数据一致性要求不高但需避免脏读的业务场景。

而它的加锁机制是，读取数据时只做锁检测，不加锁，更新数据时加行锁，事务提交后立即释放锁。

last committed read 读最后提交（GBase 8s 特有）

读最后提交是 GBase 8s 的一种隔离级别，读最后提交主要就是为了解决读操作被写操作阻塞的问题，也就是上面展示的锁超时以及死锁。事务会读取到已经提交的数据，若该行数据已经上锁，则会通过逻辑日志来读取上一版本的数据。需要注意的是它与 MVCC 版本控制是有区别的，它提供的并不是一个长时间保留的版本，只是通过逻辑日志去读取上一个版本，如果当前的事务提交，然后另一个事务又对数据进行修改时，那么刚才提交的数据就会成为上一个版本。

这种隔离级别适用于对数据一致性要求不高，但对并发性能要求较高的场景，如报表查询、数据分析等。

在读最后提交隔离级别下，同读已提交一样，读取数据时制作人锁检测，不施加任何锁，从而最大限度地提高并发性能。且该隔离级别只支持行级锁。

repeatable read 可重复读

Repeatable Read 隔离级别，确保事务执行期间多次读取同一数据时，看到一致的数据版本，避免数据不一致。适用于对数据一致性要求高的场景，如财务、订单处理系统，避免数据错误和逻辑混乱。

共享锁机制：读取数据时获取共享锁，允许多个事务读取，但禁止修改或删除，直至事务结束。

排他锁机制：更新或删除数据时获取排他锁，阻止其他事务读取或修改，保证数据操作的原子性。

锁的持续时间：在整个事务期间持有共享锁，确保事务期间数据不被其他事务修改。