本文向大家展示我对数据库中锁的理解。以下图示是本文主要内容。
什么是锁？
数据库锁是一种用于控制对数据库资源的并发访问的机制。当多个用户或事务同时访问数据库中的数据时，锁可以确保数据的一致性和完整性。锁可以防止不同的事务同时对同一数据进行修改，或者防止一个事务在读取数据时被另一个事务修改。
为什么需要锁？
出于三个目的：
1、 保证数据一致性 在并发环境下，如果没有锁机制，多个事务可能同时对同一数据进行修改，导致数据不一致。例如，一个事务正在读取数据，另一个事务同时修改了该数据，那么第一个事务读取到的数据就可能是不正确的。
2、实现并发控制
数据库锁可以控制多个事务对数据库资源的并发访问，确保事务之间的隔离性和有序性。通过合理地使用锁，可以提高数据库的并发性能，同时保证数据的正确性。
3、防止死锁和活锁
死锁和活锁是并发环境下可能出现的问题。死锁是指两个或多个事务相互等待对方释放锁，从而导致所有事务都无法继续执行。活锁是指事务不断地重试，但由于其他事务的干扰，始终无法获得所需的资源。数据库锁机制可以通过检测和解决死锁、避免活锁的发生，保证数据库系统的正常运行。
锁都有哪些
什么是全局锁
全局锁就是在数据库上直接上锁，让锁住的库只读。 这就很搞，只适合在全库逻辑备份上用。 全库备份是啥？就是把每个表select出来，保存为文本。 咋全局加锁，用flush tables with read lock。(FTWRL) 咱整个库只读时，其他线程的数据更新语句（数据的增删改）、数据定义语句（包括建表、修改表结构等）和更新类事务的提交语句。都会阻塞。 整个库只读坏处
库只读实现方式
后者不用原因
- 一是，在有些系统中，readonly 的值会被用来做其他逻辑，比如用来判断一个库是主库还是备库。因此，修改 global 变量的方式影响面更大，我不建议你使用。
- 二是，在异常处理机制上有差异。如果执行 FTWRL 命令之后由于客户端发生异常断开，那么 MySQL 会自动释放这个全局锁，整个库回到可以正常更新的状态。而将整个库设置为 readonly 之后，如果客户端发生异常，则数据库就会一直保持 readonly 状态，这样会导致整个库长时间处于不可写状态，风险较高。
备份时，不加全局锁咋样？
备份系统备份的得到的库不是一个逻辑时间点，这个视图是逻辑不一致的。
如何拿到一致性的视图？
在可重复读的隔离级别开启一个事务
官方自带的逻辑备份工具是 mysqldump。当 mysqldump 使用参数–single-transaction 的时候，导数据之前就会启动一个事务，来确保拿到一致性视图。而由于 MVCC 的支持，这个过程中数据是可以正常更新的。
那还需要FTWRL 干啥？
这个时用于不支持事务的引擎的更新。
表级锁
表锁和表级锁是一个东西吗？
不是，表锁是表级锁的一种
表锁的语法是 lock tables 表名 read/write。 unlock tables 主动释放锁，也可以在客户端断开的时候自动释放。
lock tables 语法除了会限制别的线程的读写外，也限定了本线程接下来的操作对象。
元数据锁MDL。这个不需要咱们去指定，访问表时会自动加上。
那这有啥用呢？就是保证读写正确性。
在 MySQL 5.5 版本中引入了 MDL，当对一个表做增删改查操作的时候，加 MDL 读锁；当要对表做结构变更操作的时候，加 MDL 写锁。
- 读锁之间不互斥，因此你可以有多个线程同时对一张表增删改查。
- 读写锁之间、写锁之间是互斥的，用来保证变更表结构操作的安全性。因此，如果有两个线程要同时给一个表加字段，其中一个要等另一个执行完才能开始执行。
如何安全地给小表加字段？
首先我们要解决长事务，事务不提交，就会一直占着 MDL 锁。在 MySQL 的 information_schema 库的 innodb_trx 表中，你可以查到当前执行中的事务。如果你要做 DDL 变更的表刚好有长事务在执行，要考虑先暂停 DDL，或者 kill 掉这个长事务。
但考虑一下这个场景。如果你要变更的表是一个热点表，虽然数据量不大，但是上面的请求很频繁，而你不得不加个字段，你该怎么做呢？
这时候 kill 可能未必管用，因为新的请求马上就来了。比较理想的机制是，在 alter table 语句里面设定等待时间，如果在这个指定的等待时间里面能够拿到 MDL 写锁最好，拿不到也不要阻塞后面的业务语句，先放弃。之后开发人员或者 DBA 再通过重试命令重复这个过程。
行锁
行锁是啥？
就是针对咱们数据表中行记录的锁。
那行锁咋指定呢？
这东西不用去指定， 行锁是在引擎层由各个引擎自己实现的。
咱这行锁是所有引擎共有的吗？
innodb支持，myisam不支持。
咱并发的数据库锁指的就是行锁，但这个并发度不高，咱咋通过减少锁冲突提高业务并发度呢？
这涉及到两阶段锁和死锁以及检测
在 InnoDB 事务中，行锁是在需要的时候才加上的，但并不是不需要了就立刻 释放，而是要等到事务结束时才释放。这个就是两阶段锁协议
如果你的事务中需要锁多个行， 要把最可能造成锁冲突、最可能影响并发度的锁尽量往后放。
老师给了个案例，就是A去影院B买票这涉及几个操作
1、A账户扣钱
2、B账户增加钱
3、记录交易日志
这三顺序咋放，123可以，但是2的话别的事务可能也会有，这时候咱把顺序调整为132，312都可以减少锁冲突。
锁的应用场景是什么？
（一）高并发环境下的数据一致性
在高并发环境下，多个事务可能同时对同一数据进行修改。为了保证数据的一致性，可以使用排它锁来防止其他事务对数据进行修改。例如，在银行系统中，当一个用户进行转账操作时，需要对账户余额进行修改。为了防止其他用户同时对该账户进行操作，可以在修改账户余额时加排它锁。
（二）数据的读取和写入分离
在一些应用场景中，需要将数据的读取和写入操作分离，以提高系统的并发性能。可以使用共享锁来允许多个事务同时读取数据，而使用排它锁来防止其他事务在读取数据时对数据进行修改。
（三）防止数据的重复插入
在一些应用场景中，需要防止数据的重复插入。可以使用排它锁来防止其他事务在插入数据时对同一数据进行插入操作。例如，在用户注册系统中，需要防止用户重复注册。可以在用户注册时对用户表加排它锁，以防止其他用户在同一时间注册相同的用户名。
死锁和死锁检测
当并发系统中不同线程出现循环资源依赖，涉及的线程都在等待别的线程释放资源时，就会 导致这几个线程都进入无限等待的状态，称为死锁。
当出现死锁以 后，有两种策略：一种策略是，直接进入等待，直到超时。这个超时时间可以通过参数 innodb_lock_wait_timeout 来设置。 另一种策略是，发起死锁检测，发现死锁后，主动回滚死锁链条中的某一个事务，让其他 事务得以继续执行。将参数 innodb_deadlock_detect 设置为 on，表示开启这个逻辑
在 InnoDB 中，innodb_lock_wait_timeout 的默认值是 50s，意味着如果采用第一个策 略，当出现死锁以后，第一个被锁住的线程要过 50s 才会超时退出，然后其他线程才有可 能继续执行。对于在线服务来说，这个等待时间往往是无法接受的。 但是，我们又不可能直接把这个时间设置成一个很小的值，比如 1s。这样当出现死锁的时 候，确实很快就可以解开，但如果不是死锁，而是简单的锁等待呢？所以，超时时间设置太 短的话，会出现很多误伤。
所以，正常情况下我们还是要采用第二种策略，即：主动死锁检测，而且 innodb_deadlock_detect 的默认值本身就是 on。主动死锁检测在发生死锁的时候，是能 够快速发现并进行处理的，但是它也是有额外负担的。
那如果是我们上面说到的所有事务都要更新同一行的场景呢？
每个新来的被堵住的线程，都要判断会不会由于自己的加入导致了死锁，这是一个时间复杂 度是 O(n) 的操作。假设有 1000 个并发线程要同时更新同一行，那么死锁检测操作就是 100 万这个量级的。虽然最终检测的结果是没有死锁，但是这期间要消耗大量的 CPU 资 源。因此，你就会看到 CPU 利用率很高，但是每秒却执行不了几个事务。
怎么解决由这种热点行更新导致的性能问题呢？
问题的 症结在于，死锁检测要耗费大量的 CPU 资源。 一种头痛医头的方法，就是如果你能确保这个业务一定不会出现死锁，可以临时把死锁检测 关掉。但是这种操作本身带有一定的风险，因为业务设计的时候一般不会把死锁当做一个严 重错误，毕竟出现死锁了，就回滚，然后通过业务重试一般就没问题了，这是业务无损的。 而关掉死锁检测意味着可能会出现大量的超时，这是业务有损的。 另一个思路是控制并发度。根据上面的分析，你会发现如果并发能够控制住，比如同一行同 时最多只有 10 个线程在更新，那么死锁检测的成本很低，就不会出现这个问题。一个直接 的想法就是，在客户端做并发控制。但是，你会很快发现这个方法不太可行，因为客户端很 多。我见过一个应用，有 600 个客户端，这样即使每个客户端控制到只有 5 个并发线程， 汇总到数据库服务端以后，峰值并发数也可能要达到 3000。 因此，这个并发控制要做在数据库服务端。如果你有中间件，可以考虑在中间件实现；如果 你的团队有能修改 MySQL 源码的人，也可以做在 MySQL 里面。基本思路就是，对于相 同行的更新，在进入引擎之前排队。这样在 InnoDB 内部就不会有大量的死锁检测工作了。
如果团队里暂时没有数据库方面的专家，不能实现这样的方案，能不能从设计 上优化这个问题呢？
可以考虑通过将一行改成逻辑上的多行来减少锁冲突。还是以影院账户为例，可以考虑放 在多条记录上，比如 10 个记录，影院的账户总额等于这 10 个记录的值的总和。这样每次 要给影院账户加金额的时候，随机选其中一条记录来加。这样每次冲突概率变成原来的 1/10，可以减少锁等待个数，也就减少了死锁检测的 CPU 消耗。 这个方案看上去是无损的，但其实这类方案需要根据业务逻辑做详细设计。如果账户余额可 能会减少，比如退票逻辑，那么这时候就需要考虑当一部分行记录变成 0 的时候，代码要有特殊处理。
锁的实现原理
（一）锁的存储结构
数据库中的锁通常存储在内存中的锁表中。锁表记录了每个事务持有的锁以及等待获取锁的事务。当一个事务请求锁时，数据库系统会检查锁表，以确定是否可以授予该锁。如果可以授予锁，则将锁信息添加到锁表中；如果不能授予锁，则将该事务放入等待队列中。
（二）锁的获取和释放
- 锁的获取
当一个事务需要访问数据库中的数据时，它会向数据库系统请求相应的锁。数据库系统会根据锁的类型、粒度和当前的锁状态来决定是否授予该锁。如果可以授予锁，则事务可以继续执行；如果不能授予锁，则事务会被阻塞，直到它可以获得所需的锁。 - 锁的释放
当一个事务完成对数据的访问后，它会释放所持有的锁。数据库系统会将锁信息从锁表中删除，并通知等待队列中的事务，以便它们可以尝试获取锁。
（三）死锁的检测和解决
- 死锁的检测
数据库系统通常会定期检测死锁。检测死锁的方法有多种，其中一种常见的方法是使用等待图。等待图是一个有向图，其中节点表示事务，边表示事务之间的等待关系。如果等待图中存在循环，则表示存在死锁。 - 死锁的解决
当检测到死锁时，数据库系统需要采取措施来解决死锁。解决死锁的方法有多种，其中一种常见的方法是选择一个牺牲者事务，回滚该事务，并释放它所持有的锁，以便其他事务可以继续执行。选择牺牲者事务的策略可以根据事务的优先级、等待时间等因素来确定。
