1.锁
锁是数据库系统区别于文件系统的一个关键特性。锁机制用于管理对共享资源的并发访问。 InnoDB存储引擎会在行级别上对表数据上锁,这固然不错。不过 InnoDB存储引擎也会在数据库内部其他多个地方使用锁,从而允许对多种不同资源提供并发访问。例如,操作缓冲池中的LRU列表,删除、添加、移动LRU列表中的元素,为了保证一致性,必须有锁的介入。数据库系统使用锁是为了支持对共享资源进行并发访问,提供数据的完整性和一致性。
另一点需要理解的是,虽然现在数据库系统做得越来越类似,但是有多少种数据库,就可能有多少种锁的实现方法。在SQL语法层面,因为SQL标准的存在,要熟悉多个关系数据库系统并不是一件难事。而对于锁,用户可能对某个特定的关系数据库系统的锁定模型有一定的经验,但这并不意味着知道其他数据库。
对于 MyISAM引擎,其锁是表锁设计。并发情况下的读没有问题,但是并发插入时的性能就要差一些了,若插入是在“底部”, MyISAM存储引擎还是可以有一定的并发写入操作。对于 Microsoft SQL Server数据库,在 Microsoft SQL Server2005版本之前其都是页锁的,相对表锁的 MyISAM引擎来说,并发性能有所提高。页锁容易实现,然而对于热点数据页的并发问题依然无能为力。到2005版本, Microsoft SQL Server开始支持乐观并发和悲观并发,在乐观并发下开始支持行级锁,但是其实现方式与 InnoDB存储引擎的实现方式完全不同。用户会发现在 Microsoft SQL Server下,锁是一种稀有的资源,锁越多开销就越大,因此它会有锁升级。在这种情况下,行锁会升级到表锁,这时并发的性能又回到了以前。
InnoDB存储引擎锁的实现和 Oracle数据库非常类似,提供一致性的非锁定读、行级锁支持。行级锁没有相关额外的开销,并可以同时得到并发性和一致性。
2.lock和latch
里还要区分锁中容易令人混淆的概念lock与 latch。在数据库中,lock与 latch都可以被称为“锁”。但是两者有着截然不同的含义,本章主要关注的是lock。
latch一般称为闩锁(轻量级的锁),因为其要求锁定的时间必须非常短。若持续的时间长,则应用的性能会非常差。在 InnoDB存储引擎中, latch又可以分为 mutex(互斥量)和 relock(读写锁)。其目的是用来保证并发线程操作临界资源的正确性,并且通常没有死锁检测的机制。
lock的对象是事务,用来锁定的是数据库中的对象,如表、页、行。并且一般lock的对象仅在事务 commit或 rollback后进行释放(不同事务隔离级别释放的时间可能不同)。此外,lock,正如在大多数数据库中一样,是有死锁机制的。下表显示了lock与latch的不同。
lock与 latch的比较
lock
latch
对象
事务
线程
保护
数据库内容
内存数据结构
持续时间
整个事务过程
临界资源
模式
行锁、表锁、意向锁
读写锁、互斥量
死锁
通过 waits-for graph、 time out等机制进行无死锁检测与处理机制。
无死锁检测与处理机制。仅通过应用程序加锁的顺序( lock leveling)保证无死锁的情况发生
存在于
Lock Manager的哈希表中
每个数据结构的对象中
对于 InnoDB存储引擎中的 latch,可以通过命令SHOW ENGINE INNODB MUTEX来进行查看。
mysql> show engine innodb mutex; +--------+-----------------------------+----------+ | Type | Name | Status | +--------+-----------------------------+----------+ | InnoDB | rwlock: dict0dict.cc:2685 | waits=1 | | InnoDB | rwlock: dict0dict.cc:1183 | waits=91 | | InnoDB | rwlock: fil0fil.cc:1381 | waits=1 | | InnoDB | rwlock: log0log.cc:838 | waits=81 | | InnoDB | rwlock: btr0sea.cc:195 | waits=1 | | InnoDB | sum rwlock: buf0buf.cc:1460 | waits=12 | +--------+-----------------------------+----------+ 6 rows in set (0.17 sec)
在 Debug版本下,通过命令SHOW ENGINE INNODB MUTEX可以看到 latch的更多信息,如图所示。
通过上述的例子可以看出,列Type显示的总是 InnoDB,列Name显示的是 latch的信息以及所在源码的位置(行数)。列 Status比较复杂,在 Debug模式下,除了显示 os_waits,还会显示 count、 spin_waits、 spin_rounds、 os_yields、 os_wait_times等信息。其具体含义见下表。
命令SHOW ENGINE INNODB MUTEX输出结果说明
名称
说明
count
mutex被请求的次数
spin_waits
spin lock(自旋锁)的次数,InnoDB存储引擎latch在不能获得锁时首先进行自旋,若自旋后还不能获得锁,则进入等待状态
spin_rounds
自旋内部循环的总次数,每次自旋的内部循环是一个随机数。 spin rounds/spain waits表示平均每次自旋所需的内部循环次数
os_waits
表示操作系统等待的次数。当 spin lock通过自旋还不能获得 latch时,则会进入操作系统等待状态,等待被唤醒
os_yields
进行 os_thread_yield唤醒操作的次数
os_wait_times
操作系统等待的时间,单位是ms
上述所有的这些信息都是比较底层的,一般仅供开发人员参考。但是用息还是可以通过这些参数进行调优。
相对于 latch的查看,lock信息就显得直观多了。用户可以通过命令 SHOW ENGINE INNODB STATUS及 information schema架构下的表 INNODB_TRX、 INNODB_LOCKS、INNODB_LOCK_WAITS来观察锁的信息。