在SESSION 2，我们发明，这个更新操作一向在等待。ID是主键，按事理，主键id = 1 的记录更新，不至于影响到主键id = 2的记录更新。

萌芽information_schema下的innodb_locks这张表。这张表是用于记录InnoDB事务测验测验申请但还未获取的锁，以及壅塞其他事务的事务所拥有的锁。有两笔记录：

不雅察此时的innodb_locks表，事务id=40021锁住第3页的第2行记录，导致事务id=40022无法进行下去。

我们把数据库回退到5.6.21版本，则不克不及重现上述场景。

媒介：欲望经由过程本文，使MySQL5.7.18的应用者知晓分区表应用中存在的陷阱，避免在该版本上持续踩坑。同时经由过程对源码的分享，进级MySQL5.7.18时分区表机能降低的根来源基本因，向MySQL源码爱好者展示分区表实现中锁的应用。

进一步分析

根据innodb_locks表供给的信息，我们知道问题在于InnoDB锁定了不恰当的行。该表是memory存储引擎。我们在memory 存储引擎的插入接口设置断点，获得如下客栈信息。肯定是红框部分，将锁信息写入到innodb_locks表中。

并在函数fill_innodb_locks_from_cache中得以确认，每次写入行的数据，都是大年夜如下代码中Cache对象中获取的。

根据之前的分析，每次单笔记录的update操作，会对分区表数量雷同的行数进行上锁。我们测验测验验证我们的发明。

51CTO诚邀您9月23号和秒拍/国美/美团元专家一路聊智能CDN的优化之路，抓紧时光哦！

我们知道Cache中保存了事务锁的信息，是以须要进一步查找Cache中的数据，是若何添加进去的。经由过程搜刮cache对象在innodb代码中出现的地位，找到函数add_lock_to_cache。在此函数设置断点进行调试后，发明其内容与填写innodb_locks表的数据一致。肯定该函数应用的lock对象，就是我们要找的锁对象。

针对lock_t 类型的应用地位进行排查。经由筛选和调试，发明函数RecLock::lock_add中，生成的行锁被参加到该锁地点的事务链表中。

RecLock::lock_add函数可以推出行锁的生成原因。是以，经由过程对该函数进行断点设置，查看函数客栈，在如下客栈内，定位到红框地位的函数：

针对Partition_helper::handle_ordered_index_scan的如下代码进行跟踪，根据该段代码的分析，m_part_spec.end_part 决定了进行上锁的最大年夜行数，此处即为非正常行锁生成的原因。

最终问题归结到m_part_spec.end_part 的生成原因。经由过程对end_part 应用处所进行排查，最终在get_partition_set函数中定位到该变量在应用前的初始设置值。大年夜代码中可以看出，每次单笔记录的update操作，在进行index scan上锁时，对分区表数量雷同的行数进行上锁。这个是根来源基本因。

验证结论

新增如下两笔记录：

INSERT INTO t2 VALUES (4, NOW(), '4'); 
 
INSERT INTO t2 VALUES (5, NOW(), '5');  
 
// SESSION 1 对id = 1的 记录 做一个更新操作，事务先不提交。 
 
	
			
 2/3   首页 上一页 1 2 3 下一页 尾页
	
			

　　推荐阅读
　　腾讯马化腾、商汤科技汤晓鸥等六位大佬深度解读人工智能的过去、现在和未来
            51CTO诚邀您9月23号和秒拍/国美/美团元专家一路聊智能CDN的优化之路，抓紧时光哦！
            科技，尤其是如今炙手可热的人工智能，会给生活、贸易、学术等带来多大年夜的影响？在近日由清华经管学院>>>详细阅读


本文标题：干货 | 一个MySQL 5.7分区表性能下降的案例分析
地址：http://www.17bianji.com/lsqh/37317.html
 1/2    1