数据库七：索引的锁和闩

来源：互联网发布：基于单片机电子秤编辑：程序博客网时间：2024/05/01 15:44

索引的锁和闩(Locking & Latching)

索引的锁和闩

索引作用

一种能够加快数据检索速度的数据结构，但是会占用额外的读写维护操作和存储空间。

索引实现

B树系列、哈希表等等。

这些别的地方说的比较多，我就不多提了。

索引锁

对于之前疏文章中提到的那些并发控制、多版本控制等，我们知道了如何使用锁来保护数据库的数据。但是对于索引，我们需要用别的方式和方法来对待它。

尽管索引的物理结构会发生改变，但是只要索引在逻辑层次上保持一致，就能够被使用者和开发者所接受。

举个简单的例子，我们读取数据的时候，并不关心它存储的位置或者索引指向的位置是哪里，我们只需要能够读取到正确的数据即可，就算因为插入了多个其他的数据，导致索引结构的改变，我们还是可以得到正确的数据。

锁和闩

锁

高层次，抽象
保护索引的逻辑内容不受其他txns的影响，从逻辑层面保护索引。
以txn为单位被保持。
需要能够回滚更改。

插销

低层次，具体
保护索引内部数据结构的关键部分不受其他线程影响，从物理层面保护索引。
以operation为单位被保持。
不需要能够回滚更改（或者说是不能通过回滚修改，因为底层不知道操作了啥，底层只知道有操作，知道操作的具体内容是高层的事情）。

在没有锁的情况下，事务就不通过锁去访问修改数据库，而是直接通过latches进行并发控制。
在没有闩的情况下，我们可以使用类似shadow paging等技术使得指针可以对数据进行原子操作，比如compare_and_swap（用于对特定内存地址进行值确认，如果确认成功则用新值覆盖，否则不做操作），但是我们也要通过locks来进行事务的并发控制。

因此没有一个数据库可以同时缺少这两种锁。

闩的实现

Blocking OS Mutex

简单易懂；
不可扩展，速度慢，每次分配和取消锁需要大概25纳秒。

每次mutex分配锁和取消锁都不能直接操作，而是需要调用操作系统的内核函数，这就导致非常缓慢了。每次没有获得锁，则可以直接通过内核函数表明，该线程需要锁，则有schedule的内核函数会在锁空闲的时候再次请求锁。

std::mutex m; //pthread_mutex_t  futex⋮m.lock();// Do something special...m.unlock();

Test-and-Set Spinlock

快速，单个指令实现加锁减锁；
不可扩展；
对缓存不友好，假设我们有三个CPU，我们需要一直去访问一块内存地址，并将内存地址放到CPU内部的缓存中，但是因为我们每次都要请求可能变化的新值，所以我们不可能将之存储下来继续用。

typedef std::atomic<bool> atomic_flag //std::atomic<T>std::atomic_flag latch;⋮while (latch.test_and_set(…)) { // 请求锁，如果没有得到，则循环；得到结束循环// 让位? 放弃? 重试?// 因为在上一种方法，我们通过内核函数进行规划，所以它会自动请求锁// 而这里则需要我们自己去考虑如何去做}