锁表一般是长时间占用表导致的,
成都创新互联公司是一家专业提供醴陵企业网站建设,专注与做网站、网站制作、H5页面制作、小程序制作等业务。10年已为醴陵众多企业、政府机构等服务。创新互联专业网站制作公司优惠进行中。
试着使SELECT语句运行得更快;你可能必须创建一些摘要(summary)表做到这点。
用--low-priority-updates启动mysqld。这将给所有更新(修改)一个表的语句以比SELECT语句低的优先级。在这种情况下,在先前情形的最后的SELECT语句将在INSERT语句前执行。
你可以用LOW_PRIORITY属性给与一个特定的INSERT、UPDATE或DELETE语句较低优先级。
为max_write_lock_count指定一个低值来启动mysqld使得在一定数量的WRITE锁定后给出READ锁定。
通过使用SQL命令:SET SQL_LOW_PRIORITY_UPDATES=1,你可从一个特定线程指定所有的更改应该由用低优先级完成
多线程开启事务处理。每个事务有多个update操作和一个insert操作(都在同一张表)。
默认隔离级别:Repeatable Read
只有hotel_id=2和hotel_id=11111的数据
逻辑删除原有数据
插入新的数据
根据现有数据情况,update的时候没有数据被更新
报了非常多一样的错
发现居然有死锁。
根据常识考虑,我每个线程(事务)更新的数据都不冲突,为什么会产生死锁?
带着这个问题,打印mysql最近一次的死锁信息
show engine innodb status
显示如下
发现事务1在等待一个锁
事务2也在等待一个锁
而且事物2持有了事物1需要的锁
关于锁的描述,出现了 lock_mode , gap before rec , insert intention 等字眼,看不懂说明了什么?说明我关于mysql的锁相关的知识储备还不够。那就开始调查mysql的锁相关知识。
通过搜索引擎,
锁的持有兼容程度如下表
那么再回到死锁日志,可以知道 :
事务1正在获取插入意向锁
事务2正在获取插入意向锁,持有排他gap锁
再看我们上面的锁兼容表格,可以知道, gap lock和insert intention lock是不兼容的
那么就可以推断出: 事务1持有gap lock,等待事务2的insert intention lock释放;事务2持有gap lock,等待事务1的insert intention lock释放,从而导致死锁。
那么新的问题就来了,事务1的intention lock 为什么会和事务2的gap lock 有交集,或者说,事务1要插入的数据的位置为什么会被事务2给锁住?
让我回顾一下gap lock的定义:
间隙锁,锁定一个范围,但不包括记录本身。GAP锁的目的,是为了防止同一事务的两次当前读,出现幻读的情况
那为什么是gap lock,gap lock到底是基于什么逻辑锁的记录?发现自己相关的知识储备还不够。那就开始调查。
调查后发现,当当前索引是一个 普通索引 的时候,会加一个gap lock来防止幻读, 此gap lock 会锁住一个左开右闭的区间。 假设索引为xx_idx(xx_id),数据分布为1,4,6,8,12,当更新xx_id=9的时候,这个时候gap lock的锁定记录区间就是(8,12],也就是锁住了xxid in (9,10,11,12)的数据,当有其他事务要插入xxid in (9,10,11,12)的数据时,就会处于等待获取锁的状态。
ps:当前索引不是普通索引,而且是唯一索引等其他情况,请参考下面资料
MySQL 加锁处理分析
回到我自己的案例中,重新屡一下事务1的执行过程:
因为普通索引
KEY hotel_date_idx ( hotel_id , rate_date )
的关系 这段sql会获取一个gap lock,范围(2,11111]
这段sql会获取一个insert intention lock (waiting)
再看事务2的执行过程
因为普通索引
KEY hotel_date_idx ( hotel_id , rate_date )
的关系 这段sql也会获取一个gap lock,范围也是(2,11111](根据前面的知识,gap lock之间会互相兼容,可以一起持有锁的)
这段sql也会获取一个insert intention lock (waiting)
看到这里,基本也就破案了。因为普通索引的关系,事务1和事务2的gap lock的覆盖范围太广,导致其他事务无法插入数据。
重新梳理一下:
所以从结果来看,一堆事务被回滚,只有10007数据被更新成功
gap lock 导致了并发处理的死锁
在mysql默认的事务隔离级别(repeatable read)下,无法避免这种情况。只能把并发处理改成同步处理。或者从业务层面做处理。
共享锁、排他锁、意向共享、意向排他
record lock、gap lock、next key lock、insert intention lock
show engine innodb status
这个是属于系统遗留问题,也就是一种系统的保护机制。就是为了避免出现这种在线修改系统的操作。
增加字段属于系统的修改操作。尽量不要在线操作,因为可能出现。未知的漏洞。一定要。离线。修改完毕,然后经过测试后。认为已经没有问题了。在。次日的凌晨发一个通知。停机维护。这样才能保证系统的正常运转。
如果在前期设置系统的时候就预留了。热升级的空间。这样才能达到在线操作的目的,而且系统的金融群总是一部分先升级。
很多情况下,你需要使用系统里边的工具集。在线修改表格。原理其实非常的简单,新建的和原表的表格结构。要一模一样。对这个表格进行修改,然后把结构变更的日期。插入进去。而且还建议您尽量在业务的低缝隙进行修改。避免发生不可控的未知状况。
使用说明:
1、如果是用 MySQL + Apache,使用的又是 FreeBSD 网络操作系统的话,安装时候你应按注意到FreeBSD的版本问题,在FreeBSD 的 3.0 以下版本来说,MySQL Source 内含的 MIT-pthread 运行是正常的,但在这版本以上,你必须使用 native threads。
2、如果在 COMPILE 过程中出了问题,请先检查你的 gcc版本是否在 2.81 版本以上,gmake 版本是否在3.75以上。
3、如果不是版本的问题,那可能是你的内存不足,请使用configure--with-low-memory 来加入。
4、如果要重新做你的configure,那么你可以键入rm config.cache和make clean来清除记录。
5、把 MySQL 安装在 /usr/local 目录下,这是缺省值,您也可以按照你的需要设定你所安装的目录。