4.3 重点是该SQL为什么运行时间这么久呢？我们通过运行SQL获取执行计划和我们采用perf top+top -H的方式来看看内部的函数调用。发现如下：
- 结合资源占用情况可以看到占用cpu资源最大的函数是：JOIN_CACHE：：read_record_field
- 结合执行计划看sub_part、tsf、cat使用了临时表和join_buffer，试图分析i_s.files无果，该试图中大多是数据字典，无法访问。
- 这可能和我们系统中存在大量ibd文件有关。肯定很多同学会问，为什么会有这么多ibd，因为我们大量使用分库、分表、分区。
我们知道join cache 一般用在两表join连接，被驱动表没有索引的情况下，将驱动表的数据放到join cache中，当join cache满了以后驱动一次被驱动表，以此来减少被驱动表全表扫描的次数，进而提高性能。
其次我们需要知道的MySQL虽然某一个线程负载高但是，一个线程只能使用CPU核心，我们监控监控的是整体的CPU，因此虽然一个CPU已经达到99%的高负载，但是整体平均下来也不那么明显，这是我行以后监控需要持续改进的地方。
5. checking permissions的疑惑
很明显上面的分析我们发现语句实际已经执行了，但是为什么处于checking permissions状态呢？为了解开这个疑惑，我们需要将断点放到THD::enter_stage和JOIN_CACHE::read_record_field上，当然这部分我们没有深入的研究，只看debug状态，debug 什么呢，只要证明状态 executing 后进入了checking permissions状态且在checking permissions状态下执行了JOIN_CACHE::read_record_field即可如下：
这里证明了语句已经进入了执行阶段，但是每次读取一行join cache的记录转换一次状态为checking permissions，栈如下：
我们来看红色函数的注释如下：
INFORMATION_SCHEMA picks metadata from new DD using system views.
显然这里和访问information_schema中的数据有关，因为这里涉及到information_schema和数据字典的实现，过于庞大，我们不做研究了。
但是我们得出一个结论，对于访问字典视图，出现比较奇怪的状态，我们应该用perf top或者pstack获取信息，而不能停留在常规的认知上。
6. 探索优化思路
- 肯定有同学想问mysqldump为什么要执行上面这个SQL呢？这个还需要备份厂商来解释了，该SQL在备份中还不能短时间改善，银行是非常注重备份，不可能等厂商改，所以我们放弃该思路
- 既然厂商无法调整，那我们就从数据库本身着手，SQL属于内部试图，我等源码基础也不好，无奈啊！只能从执行计划和占用高资源得函数着手，既然join_cache这么高，且执行计划中提示使用了join_buffer和临时表，那么我们来试图调整join_buffer_size,当前默认是2M，将join_buffer_size调整后再次执行SQL，SQL运行1min7s，效果明显。
至此，我们已经找到优化思路，调整数据库join_buffer_size来解决，肯定有同学问，这个也不能随便调整啊，因为这是一个session级别的参数，可能导致MySQLD使用内存大幅增加。但是，我们架构中设计的这个库是专门用于全备的，没有任何应用连接，所以可以调整该参数。再次发起数据库备份，观察几天时间，该问题不再发现。透过事物看本质发现，mysql中在有大量的表或分区情况下，在通过内部试图、数据字典读取操作系统中文件时可能会存在有各种性能问题，对于某些查询操作我们可以在备库进行，尽量减少对主库的冲击。
7. 补充：关于几个timeout参数生效点
接下来我们也研究了几个timeout参数， 如果出现超时遇到了日志是Got timeout reading communication packets，而不是Got an error reading communication packets。实际上几个timeout 参数都是通过poll的timeout参数实现的，我们稍微总结了一下如下：
- 连接进行握手，连接时poll的timeout受到connect_timout影响
- loop 进入死循环
- wait_timeout/interactive_timeout 参数设置poll timeout参数
- 堵塞等待命令来到
- 命令来到退出堵塞。
- 命令执行期间读写更改poll的参数，受net_read_timout和net_write_timeout参数影响
- 命令执行
- 命令执行完成后，再次做wait_timeout/interactive_timeout参数检查并且恢复
- goto loop
因此总结一下：
- Got timeout reading communication packets：可能和参数connect_timout，net_read_timout，wait_timeout/interactive_timeout 有关
- Got timeout writing communication packets：可能和参数net_write_timeout有关
</div>
