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

第二层包含萌芽解析、分析、优化(这三个是解决问题最关怀的)、缓存治理、所有内置函数、存储过程、触发器、视图，似乎扯得有点远;

第三层包含了重要的存储引擎层，MySQL Server层(第二层)经由过程“存储引擎API”向存储引擎层存储和提取数据，此层主如果数据存储相干。

在MySQL内部有一个专用的thread用来监听数据库连接请求，当一个新的请求过来，如不雅采取以前的模型(one-thread-per-connection)，main listener(这是主线程中的listener，为了避免与thread group 中的listener混淆，我们称之为“Main listener”)将大年夜thread cache中掏出1个thread或创建1个新的thead急速处理该连接请求，由该thread完成该连接的┞符个生命周期;

而如不雅采取Thread-Pool模型，这个连接请求将会被随机放到一个thread group(thread pool由多个thread group 构成)的队列中，之后该thread group中worker thread大年夜队列中掏出场建立连接，一旦连接建立，该连接对应的socket句柄将与该thread group中的listener接洽关系起来，之后该连接将在该thread group中完成它的生命周期。

接下来我们来说说Thread Group 。Thread Group是Thread-Pool的核心组件，所有的操作都是产生在thread group。Thread-Pool由多个(数量由参数thread_pool_size来决定，默认等于cpu个数)thrad group构成。一个连接请求被随机地绑定到一个thread group，每个thread group自力工作，并且占用一个核的CPU。所以thread group都邑最大年夜限度地保持一个thread处于ACTIVE状况，并且最好只有一个，因为太多就有可能压跨数据库。

Thread Group中的thread一般有4个状况：

TP_STATE_LISTENER
TP_STATE_IDLE
TP_STATE_ACTIVE
TP_STATE_WAITING

当一个线程作为listener运行时就处于“TP_STATE_LISTENER”，它经由过程epoll的方法监听联接到该Thread Group的所有连接，当一个socket就鹱?，listener将决定是否唤醒一个thread或本身处理该socket。此时如不雅Thread Group的队列为空，它将本身处理该socket并将状况更改为“ACTIVE”，之后该thread 在MySQL Server内部处理“工作”，当该线程碰到锁或异步IO(比如将数据页读入到buffer pool)这些wait时，该thread精晓过回调函数的方法告诉thread pool，让其把本身标记为“WAITING”状况。

此时，假设队列中有了新的socket预备就绪，是急速创建新的线程照样等待刚才的线程履行停止呢?

因为Thread-Pool最初设计的目标是保持必定命量的线程处于“ACTIVE”状况，具体的实现方法就是控制thread group的数量和thread group内部处于"ACTIVE"状况的thread的数量。控制thread group内部的ACTIVE状况的数量，办法就是最大年夜限度地包管处于ACTIVE状况的线程个数是1。很显然，当前thread group中有一个处于WAITING状况的thread了，如不雅再启用一个新的线程并且处于ACTIVE状况，刚才的线程由WAITING变为ACTIVE状况时，此时将会有2个“ACTIVE”状况的线程，和最初的目标似乎相背，但显然也不克不及让后续就绪的socket一向等待下去，那应当怎么处理?

那么此时须要一个衡量了，供给了如许的一个办法：对正在ACTIVE或WAITING状况的线程启用一个计数器，跨越计数器后将该thread标记为stalled，然后thread group创建新的thread或唤醒sleep的thread处理新的sokcet，如许将是一个很好的衡量。超不时光该参数thread_pool_stall_limit来决定，默认是500ms。

作为综合性多营业的“互联网+生活办事”平台，美团点评对数据库的稳定运行有较高的请求，小概率的机能颤抖(包含慢SQL)都邑造成必定的可用性损掉。本文将大年夜以前几年碰到的一些机能问题中，遴选了一个较为棘手的案例，商量端到端数据库机能问题的解决思路，为DBA同窗在解决类似问题时供给一种参考。

如不雅一个线程无事可做，它将保持余暇状况(TP_STATE_WAITING)一准时光(thread_pool_idle_timeout参数决定，默认是60秒)后“自杀”。

3、和我们碰到的具体问题相干的点

假设上文提到的由“ACTIVE”转化为“WAITING”状况的线程(标记为“线程A”)所履行的“SQL"可能是一个标准的慢SQL(定名为SQLA，履行时光较长)，那么后续有连接请求分派到了同一个thread group,那么新连接的SQL(定名SQLB)须要等待线程A停止;如不雅SQLA履行时光跨越500ms，该thread group创建新的worker线程来处理SQLB。

解决办法

思路5： 调优 Thread-Pool 相干参数

找到问题了，那么解决办法就Ｒ单了。调剂thread_pool_stall_limit=10，如许就强迫被SQLA更快被标记为stalled，然后创建新的线程来处理SQLB。

带来的价值