经由过程以上“背书”，我们大年夜概懂得了一个SQL请求的履行过程，那到底慢在哪个阶段呢?

经由过程“慢SQL特点”的第4条知道，“数据库的slow log琅绫腔有记录这类SQL”，那慢SQL产生的阶段就可以清除了。

MySQL slow log是记录SQL履行过程花费的时光，记录的时光大年夜“SQL解析”到“存储引擎”返回数据全部过程，所以可以清除该SQL是慢在第二层和第三层，那么只能是把时光花费在第一层了?和线程相干?

结不雅： 很可能慢在MySQL线程治理上。

没有惹人Thread-Pool前，MySQL应用的是one thread per connection，一旦connection增长到必定程度，MySQL的机能将急剧降低甚至被压跨。惹人Thread-Pool后将会解决上述问题,同时会削减MySQL内部的线程数(节俭内存)及频繁创建线程的开销(节俭CPU)。

思路3： 是创建线程慢?thread cache不敷用，须要频繁的创建线程?

办法：查看当时数据库的状况值

可以看到，当时余暇的thread很多，监控图也没有颤抖，所以并没有频繁地创建线程。 慢SQL产生的时光点，余暇的thread很多，并没有进行大年夜量的线程创建。

那问题到底涌如今和线程相干的哪个环节呢? 先把所有和thread相干的参数列出来。

• thread_cache_size
• thread_concurrency
• thread_handling
• thread_pool_high_prio_mode
• thread_pool_high_prio_tickets
• thread_pool_idle_timeout
• thread_pool_max_threads
• thread_pool_oversubscribe
• thread_pool_size
• thread_pool_stall_limit
• thread_stack
• thread_statistics

一眼看以前，大年夜部分是和Thread-Pool相干。同时意识到这些问题是跟着进级到MySQL 5.6产生的，5.6惹人了 Thread-Pool 功能。

结不雅： 看来MySQL5.6的 Thread-Pool 有很大年夜嫌疑了。

思路4： 封闭MySQL 5.6的 Thread-Pool ，确认一下问题

办法： 调剂MySQL参数 thread_handling = pool-of-threads---- → thread_handling = >

慢SQL数量：3788

封闭 Thread-Pool 功能后(2016年9月13日当天数据)。

99line占比：已经看不到跨越100ms的sql了，都在10ms以内。

慢SQL数量：818

那么封闭 Thread-Pool ? 谜底很显然，不克不及! Thread-Pool 是MySQL5.6重要的功能，可以或许包管MySQL数据库高并发下的机能稳定。

办法：深刻懂得 Thread-Pool 的工作道理，查找可能产生慢SQL的参数。

结不雅： 找到了相干参数(thread_pool_stall_limit)，并且效不雅明显，慢SQL数量大年夜最初的3788削减到63，几乎全部祛除掉落。

以xxx-service这个service为例，调剂后的效不雅，2016年9月20日当天的数据：

99line占比：

慢SQL数量：63

ok，效不雅有了，总结一下。

问题分析

1、基来源基本理

2、Thread-Pool 是若何工作的?

起首可以看到，MySQL重要有三个组件：连接/线程处理、MySQL Server层、存储引擎层。

• 最上层重要进行连接处理、授权认证、安然等;
   2/4   首页 上一页 1 2 3 4 下一页 尾页
  
  

  　　推荐阅读

  　　微软Word漏洞：黑客可利用链接自动更新安装恶意软件

  【51CTO晃荡】8.26 带你与清华大年夜学、搜狗、京东大年夜咖们一路商量基于算法的IT运维实践 根据外媒消息，SANS 互联网中间的一名自由安然参谋和 Handler 在微软 Word 中>>>详细阅读

  
  

  本文标题：简单SQL也很慢？数据库端到端性能问题的解决思路探讨

  地址：http://www.17bianji.com/lsqh/36869.html

   1/2    1