锁是计算机协调多个进程或线程并发访问某一资源的机制，在数据库中，除传统的计算资源（CPU、RAM、I/O）争用外，数据也是一种供许多用户共享的资源，如何保证数据并发访问的一致性，有效性是所有数据库必须解决的一个问题，锁冲突也是影响数据库并发访问性能的一个重要因素，从这个角度来说，锁对数据库而言是尤其重要，也更加复杂。MySQL中的锁，按照锁的粒度分为:1、全局锁，就锁定数据库中的所有表。2、表级锁，每次 *** 作锁住整张表。3、行级锁，每次 *** 作锁住对应的行数据。
全局锁就是对整个数据库实例加锁，加锁后整个实例就处于只读状态，后续的DML的写语句，DDL语句，已经更新 *** 作的事务提交语句都将阻塞。其典型的使用场景就是做全库的逻辑备份，对所有的表进行锁定，从而获取一致性视图，保证数据的完整性。但是对数据库加全局锁是有弊端的，如在主库上备份，那么在备份期间都不能执行更新，业务会受影响，第二如果是在从库上备份，那么在备份期间从库不能执行主库同步过来的二进制日志，会导致主从延迟。
解决办法是在innodb引擎中，备份时加上--single-transaction参数来完成不加锁的一致性数据备份。
添加全局锁: flush tables with read lock解锁 unlock tables。
表级锁,每次 *** 作会锁住整张表.锁定粒度大,发送锁冲突的概率最高,并发读最低,应用在myisam、innodb、BOB等存储引擎中。表级锁分为: 表锁、元数据锁(meta data lock, MDL)和意向锁。
表锁又分为: 表共享读锁 read lock、表独占写锁write lock
语法: 1、加锁 lock tables 表名 ... read/write
2、释放锁 unlock tables 或者关闭客户端连接
注意: 读锁不会阻塞其它客户端的读，但是会阻塞其它客户端的写，写锁既会阻塞其它客户端的读，又会阻塞其它客户端的写。大家可以拿一张表来测试看看。
元数据锁,在加锁过程中是系统自动控制的，无需显示使用，在访问一张表的时候会自动加上，MDL锁主要作用是维护表元数据的数据一致性，在表上有活动事务的时候，不可以对元数据进行写入 *** 作。为了避免DML和DDL冲突，保证读写的正确性。
在MySQL5.5中引入了MDL，当对一张表进行增删改查的时候，加MDL读锁(共享)；当对表结构进行变更 *** 作时，加MDL写锁(排他).
查看元数据锁:
select object_type,object_schema,object_name,lock_type,lock_duration from performance_schema_metadata_locks
意向锁，为了避免DML在执行时，加的行锁与表锁的冲突，在innodb中引入了意向锁，使得表锁不用检查每行数据是否加锁，使用意向锁来减少表锁的检查。意向锁分为,意向共享锁is由语句select ... lock in share mode添加。意向排他锁ix,由insert，update，delete，select。。。for update 添加。
select object_schema,object_name,index_name,lock_type,lock_mode,lock_data from performance_schema.data_lock
行级锁，每次 *** 作锁住对应的行数据，锁定粒度最小，发生锁冲突的概率最高，并发读最高，应用在innodb存储引擎中。
innodb的数据是基于索引组织的，行锁是通过对索引上的索引项加锁来实现的，而不是对记录加的锁，对于行级锁，主要分为以下三类:
1、行锁或者叫record lock记录锁，锁定单个行记录的锁，防止其他事物对次行进行update和delete *** 作，在RC,RR隔离级别下都支持。
2、间隙锁Gap lock,锁定索引记录间隙(不含该记录)，确保索引记录间隙不变，防止其他事物在这个间隙进行insert *** 作，产生幻读，在RR隔离级别下都支持。
3、临键锁Next-key-lock,行锁和间隙锁组合，同时锁住数据，并锁住数据前面的间隙Gap,在RR隔离级别下支持。
innodb实现了以下两种类型的行锁
1、共享锁 S: 允许一个事务去读一行，阻止其他事务获得相同数据集的排他锁。
2、排他锁 X: 允许获取排他锁的事务更新数据，阻止其他事务获得相同数据集的共享锁和排他锁。
insert 语句 排他锁 自动添加的
update语句 排他锁 自动添加
delete 语句 排他锁 自动添加
select 正常查询语句 不加锁 。。。
select 。。。lock in share mode 共享锁 需要手动在select 之后加lock in share mode
select 。。。for update 排他锁 需要手动在select之后添加for update
默认情况下，innodb在repeatable read事务隔离级别运行，innodb使用next-key锁进行搜索和索引扫描，以防止幻读。
间隙锁唯一目的是防止其它事务插入间隙，间隙锁可以共存，一个事务采用的间隙锁不会阻止另一个事务在同一间隙上采用的间隙锁。
1.查看表是否被锁：
（1）直接在mysql命令行执行:showengineinnodbstatus\G。
（2）查看造成死锁的sql语句，分析索引情况，然后优化sql。
（3）然后showprocesslist,查看造成死锁占用时间长的sql语句。
（4）showstatuslike‘%lock%。
2.查看表被锁状态和结束死锁步骤：
（1）查看表被锁状态：showOPENTABLESwhereIn_use>0这个语句记录当前锁表状态。
（2）查询进程：showprocesslist查询表被锁进程；查询到相应进程killid。
（3）分析锁表的SQL：分析相应SQL，给表加索引，常用字段加索引，表关联字段加索引。
（4）查看正在锁的事物：SELECT*FROMINFORMATION_SCHEMA.INNODB_LOCKS。
（5）查看等待锁的事物：SELECT*FROMINFORMATION_SCHEMA.INNODB_LOCK_WAITS。
扩展资料
MySQL锁定状态查看命令：
Checkingtable：正在检查数据表（这是自动的）。
Closingtables：正在将表中修改的数据刷新到磁盘中，同时正在关闭已经用完的表。这是一个很快的 *** 作，如果不是这样的话，就应该确认磁盘空间是否已经满了或者磁盘是否正处于重负中。
ConnectOut：复制从服务器正在连接主服务器。
Copyingtotmptableondisk：由于临时结果集大于tmp_table_size，正在将临时表从内存存储转为磁盘存储以此节省内存。
Creatingtmptable：正在创建临时表以存放部分查询结果。
deletingfrommaintable：服务器正在执行多表删除中的第一部分，刚删除第一个表。
deletingfromreferencetables：服务器正在执行多表删除中的第二部分，正在删除其他表的记录。
Flushingtables：正在执行FLUSHTABLES，等待其他线程关闭数据表。
Killed：发送了一个kill请求给某线程，那么这个线程将会检查kill标志位，同时会放弃下一个kill请求。MySQL会在每次的主循环中检查kill标志位，不过有些情况下该线程可能会过一小段才能死掉。如果该线程程被其他线程锁住了，那么kill请求会在锁释放时马上生效。
Locked：被其他查询锁住了。
Sendingdata：正在处理SELECT查询的记录，同时正在把结果发送给客户端。
Sortingforgroup：正在为GROUPBY做排序。
Sortingfororder：正在为ORDERBY做排序。
Openingtables：这个过程应该会很快，除非受到其他因素的干扰。例如，在执ALTERTABLE或LOCKTABLE语句行完以前，数据表无法被其他线程打开。正尝试打开一个表。
Removingduplicates：正在执行一个SELECTDISTINCT方式的查询，但是MySQL无法在前一个阶段优化掉那些重复的记录。因此，MySQL需要再次去掉重复的记录，然后再把结果发送给客户端。
Reopentable：获得了对一个表的锁，但是必须在表结构修改之后才能获得这个锁。已经释放锁，关闭数据表，正尝试重新打开数据表。
Repairbysorting：修复指令正在排序以创建索引。
Repairwithkeycache：修复指令正在利用索引缓存一个一个地创建新索引。它会比Repairbysorting慢些。
Searchingrowsforupdate：正在讲符合条件的记录找出来以备更新。它必须在UPDATE要修改相关的记录之前就完成了。
Sleeping：正在等待客户端发送新请求。
Systemlock：正在等待取得一个外部的系统锁。如果当前没有运行多个mysqld服务器同时请求同一个表，那么可以通过增加--skip-external-locking参数来禁止外部系统锁。
Upgradinglock：INSERTDELAYED正在尝试取得一个锁表以插入新记录。
Updating：正在搜索匹配的记录，并且修改它们。
UserLock：正在等待GET_LOCK()。
Waitingfortables：该线程得到通知，数据表结构已经被修改了，需要重新打开数据表以取得新的结构。然后，为了能的重新打开数据表，必须等到所有其他线程关闭这个表。
waitingforhandlerinsert：INSERTDELAYED已经处理完了所有待处理的插入 *** 作，正在等待新的请求。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）