13518219792
MySQL8.x 中新增了一个轻量级的备份锁，它允许在 online 备份的时候进行 DML 操作，同时可防止快照不一致。这个锁禁止的操作很少，它禁止的操作包括：
创新互联公司成都网站建设定制网站开发，是成都网站营销推广公司,为成都石牌坊提供网站建设服务,有成熟的网站定制合作流程，提供网站定制设计服务：原型图制作、网站创意设计、前端HTML5制作、后台程序开发等。成都网站营销推广热线：028-86922220
文件的创建、删除、改名
账户的管理
REPAIR TABLE
TRUNCATE TABLE
OPTIMIZE TABLE
备份锁由 lock instance for backup 和 unlock instance 语法组成。使用这些语句需要 BACKUP_ADMIN 权限。
1、确定mysql有锁表的情况则使用以下命令查看锁表进程
2、杀掉查询结果中已经锁表的trx_mysql_thread_id
扩展：
1、查看锁的事务
2、查看等待锁的事务
3、查询是否锁表：
4、查询进程
for update 的作用是在查询的时候为行加上排它锁，当一个事务的操作未完成时候，其他事务可以读取但是不能写入或更新。
它的典型使用场景是 高并发并且对于数据的准确性有很高要求 ，比如金钱、库存等，一般这种操作都是很长一串并且开启事务的，假如现在要对库存进行操作，在刚开始读的时候是1，然后马上另外一个进程将库存更新为0了，但事务还没结束，会一直用1进行后续的逻辑，就会有问题，所以需要用for upate 加锁防止出错。
行锁的具体实现算法有三种：record lock、gap lock以及next-key lock。
只在可重复读或以上隔离级别下的特定操作才会取得 gap lock 或 next-key lock，在 Select、Update 和 Delete 时，除了基于唯一索引的查询之外，其它索引查询时都会获取 gap lock 或 next-key lock，即锁住其扫描的范围。主键索引也属于唯一索引，所以主键索引是不会使用 gap lock 或 next-key lock
for update 仅适用于InnoDB，并且必须开启事务，在begin与commit之间才生效。
select 语句默认不获取任何锁，所以是可以读被其它事务持有排它锁的数据的！
InnoDB 既实现了行锁，也实现了表锁。
当有明确指定的主键/索引时候，是行级锁，否则是表级锁
假设表 user，存在有id跟name字段，id是主键，有5条数据。
明确指定主键，并且有此记录，行级锁
无主键/索引，表级锁
主键/索引不明确，表级锁
明确指定主键/索引，若查无此记录，无锁
参考博文：
以下五种方法可以快速定位全局锁的位置，仅供参考。
方法1：利用 metadata_locks 视图
此方法仅适用于 MySQL 5.7 以上版本，该版本 performance_schema 新增了 metadata_locks，如果上锁前启用了元数据锁的探针（默认是未启用的），可以比较容易的定位全局锁会话。
方法2：利用 events_statements_history 视图此方法适用于 MySQL 5.6 以上版本，启用 performance_schema.eventsstatements_history（5.6 默认未启用，5.7 默认启用），该表会 SQL 历史记录执行，如果请求太多，会自动清理早期的信息，有可能将上锁会话的信息清理掉。
方法3：利用 gdb 工具如果上述两种都用不了或者没来得及启用，可以尝试第三种方法。利用 gdb 找到所有线程信息，查看每个线程中持有全局锁对象，输出对应的会话 ID，为了便于快速定位，我写成了脚本形式。也可以使用 gdb 交互模式，但 attach mysql 进程后 mysql 会完全 hang 住，读请求也会受到影响，不建议使用交互模式。
方法4：show processlist
如果备份程序使用的特定用户执行备份，如果是 root 用户备份，那 time 值越大的是持锁会话的概率越大，如果业务也用 root 访问，重点是 state 和 info 为空的，这里有个小技巧可以快速筛选，筛选后尝试 kill 对应 ID，再观察是否还有 wait global read lock 状态的会话。
方法5：重启试试！
