徐州做网站最好的公司,网站在线制作软件,企业网站建设公司 宣武,wordpress 产品展示 插件前言#xff1a;希望通过本文#xff0c;使MySQL5.7.18的使用者知晓分区表使用中存在的陷阱#xff0c;避免在该版本上继续踩坑。同时通过对源码的分享#xff0c;升级MySQL5.7.18时分区表性能下降的根本原因#xff0c;向MySQL源码爱好者展示分区表实现中锁的运用。问题描…前言希望通过本文使MySQL5.7.18的使用者知晓分区表使用中存在的陷阱避免在该版本上继续踩坑。同时通过对源码的分享升级MySQL5.7.18时分区表性能下降的根本原因向MySQL源码爱好者展示分区表实现中锁的运用。问题描述MySQL 5.7版本中性能相关的改进非常多。包括临时表相关的性能改进连接建立速度的优化和复制分发相关的性能改进等等。基本上不需要做配置修改只需要升级到5.7版本就能带来不少性能的提升。我们在测试环境把数据库升级到5.7.18版本验证MySQL 5.7.18版本是否符合我们的预期。观察运行了一段时间有开发反馈数据库的性能比之前的5.6.21版本有下降。主要的表现特征是遇到比较多的锁超时情况。开发另外反馈性能下降相关的表都是分区表。更新走的都是主键。这个反馈引起了我们重视。我们做了如下尝试数据库的版本为5.7.18, 保留分区表性能会下降。数据库版本为5.7.18把表调整为非分区表性能正常。把数据库的版本回退到5.6.21版本保留分区表性能也是正常通过上述测试我们大致判定这个性能下降和MySQL5.7版本升级有关。问题重现测试环境的数据库表结构比较多并且调用关系也比较复杂。为了进一步分析并定位问题我们抽丝剥茧构建了如下一个简单的重现过程// 创建一个测试分区表t2:CREATE TABLE t2(id INT(11) NOT NULL,dt DATETIME NOT NULL,data VARCHAR(10) DEFAULT NULL,PRIMARYKEY (id,dt),KEYidx_dt(dt)) ENGINEINNODB DEFAULTCHARSETlatin1/*!50100 PARTITION BY RANGE (to_days(dt))(PARTITION p20170218 VALUES LESS THAN (736744)ENGINE InnoDB,PARTITIONp20170219 VALUES LESS THAN (736745) ENGINE InnoDB,PARTITIONpMax VALUES LESS THAN MAXVALUE ENGINE InnoDB) */// 插入测试数据INSERT INTO t2 VALUES (1, NOW(), 1);INSERT INTO t2 VALUES (2, NOW(), 2);INSERT INTO t2 VALUES (3, NOW(), 3);// SESSION 1 对id 1的 记录 做一个更新操作事务先不提交。BEGIN;UPDATE t2 SET DATA 12 WHERE id 1;// SESSION 2 对id 2 的记录做一个更新。BEGIN;UPDATE t2 SET DATA 21 WHERE id 2;在SESSION 2我们发现这个更新操作一直在等待。ID是主键按道理主键id 1 的记录更新不至于影响到主键id 2的记录更新。查询information_schema下的innodb_locks这张表。这张表是用于记录InnoDB事务尝试申请但还未获取的锁以及阻塞其他事务的事务所拥有的锁。有两条记录观察此时的innodb_locks表事务id40021锁住第3页的第2行记录导致事务id40022无法进行下去。我们把数据库回退到5.6.21版本则不能重现上述场景。进一步分析根据innodb_locks表提供的信息我们知道问题在于InnoDB锁定了不恰当的行。该表是memory存储引擎。我们在memory 存储引擎的插入接口设置断点得到如下堆栈信息。确定是红框部分将锁信息写入到innodb_locks表中。并在函数fill_innodb_locks_from_cache中得以确认每次写入行的数据都是从如下代码中Cache对象中获取的。我们知道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上锁时对分区表数目相同的行数进行上锁。这个是根本原因。验证结论根据之前的分析每次单条记录的update操作会对分区表数目相同的行数进行上锁。我们尝试验证我们的发现。新增如下两条记录INSERT INTO t2 VALUES (4, NOW(), 4);INSERT INTO t2 VALUES (5, NOW(), 5);// SESSION 1 对id 1的 记录 做一个更新操作事务先不提交。BEGIN;UPDATE t2 SET DATA 12 WHERE id 1;// SESSION 2 现在对id 4 的记录做一个更新。BEGIN;UPDATE t2 SET DATA 44 WHERE id 4;我们发现对id 4的更新可以正常进行。不会受到id 1 的更新影响。这是因为id4的记录超过了测试案例的分区个数不会被锁住。在实际应用中分区表所定义分区数不会如测试用例中的只有3个而是数十个乃至数百个。这样进行上锁的结果将加剧更新情况下的锁冲突导致事务处于锁等待状态。如下图所示每个事务都上N个行锁那么这些上锁记录互相覆盖的可能性就极大的提高也就导致并发下降效率降低。结论通过上述分析我们非常确认这个应该是MySQL 5.7版本的一个regression。我们提交了一个Bug到开源社区。Oracle确认是一个问题需进一步分析调查这个Bug。点关注不迷路好了各位以上就是这篇文章的全部内容了能看到这里的人呀都是人才。之前说过PHP方面的技术点很多也是因为太多了实在是写不过来写过来了大家也不会看的太多所以我这里把它整理成了PDF和文档如果有需要的可以以上内容希望帮助到大家很多PHPer在进阶的时候总会遇到一些问题和瓶颈业务代码写多了没有方向感不知道该从那里入手去提升对此我整理了一些资料包括但不限于分布式架构、高可扩展、高性能、高并发、服务器性能调优、TP6laravelYII2RedisSwoole、Swoft、Kafka、Mysql优化、shell脚本、Docker、微服务、Nginx等多个知识点高级进阶干货需要的可以免费分享给大家需要的可以加入我的