一个早晨，当我来到公司时，我收到了商务同学的反馈。在某个SQL之前，在线查询速度很快。从某个时间点开始，查询速度突然变得越来越慢。我希望DBA能够帮助检查它。商务同学的原始单词如下：
看到这个问题，我首次向业务询问了该表的基本操作。反馈如下：
首先，让我们看一下这个SQL（脱敏后）：
选择
xxx，xxx，xxx，xxx，...
来自log_xxxx_2022_4
其中1 = 1
和='xxxxxxx-e527b8cd-84b-960'
和 < '2022-04-20 10:56:37'
AND >='2022-03-20 10:56:37'
订购DESC限制0,20;
SQL本身的语义相对简单。它是一个单表查询，不涉及复杂的查询：
从某个表中，将L_MID和L_OPERTIME的两个字段用作滤波器条件，在其他字段中输出输出表，然后对L_Opertime进行排序。
如此简单的SQL，如果有索引，应该没有问题。让我们看一下表结构：
从上面的索引结构中，我们可以看到我们的L_MID字段和L_Opertime字段具有索引。
从索引原则的角度来看，该SQL的执行计划至少应为索引式（索引扫描）。
在传统的MySQL中，解释性语句用于分析tidb的mysql.in的执行计划，我们可以使用2种方法查看TIDB的执行计划：
A，解释 + SQL：此方法并未真正执行语句，并将直接返回执行计划
B，解释分析 + SQL：此方法执行SQL语句并返回SQL执行计划
我们使用上述方法B查看执行计划（因为此方法可以看到SQL的执行时间），如上所述，上述SQL的执行计划如下：
上述SQL的执行时间为：26.15秒
我们分析了TIDB的执行计划：
id：占用名称。从数字可以看出，我们当前的SQL操作员包括：
indexlookup：总结TIKV扫描的ROWID，然后转到探针终端以准确地读取TIKV上的数据。
indexfullscan：另一个“全表扫描”，扫描索引数据，而不是表数据。
tableOwIdScan：根据上层传递的ROWID扫描表数据。经常在索引操作后搜索合格的行。
口气列：显示TIDB有望处理的线路数量的数量：显示TIDB运算符实际输出的实际数据编号估计最多可扫描2W行，但实际输出号为2000W行。
任务列：显示操作员位于句子位置的位置，root代表tidb，cop表示tikvaccess对象列：表示访谈的表对象和索引执行信息列：操作员的实际执行信息，包括执行时间和其他内容，可以看到每个步骤的执行时间，但并不是特别直观。我们将稍后通过仪表板页面分析执行时间。
操作员信息：显示访问表，分区，索引的其他信息：[2022-03-20 10：56：37，2022-04-20 10:56:37] -20 10:56:37），相应的任务是警察[tikv]
保留订单：正确意味着此查询需要TIKV返回结果
统计：伪意味着雌激素显示的估计行可能不准确。TIDB定期更新背景中的统计信息。您还可以通过分析表手动更新信息。
内存列：操作员歌剧所占据的内存空间：上面的解释分析分析的执行计划的内容还不够直观。LET对TIDB的仪表板的看法，实际上，我们还可以找到一些线索。
输入TIDB的仪表板页--->单击左侧的慢速查询--->根据SQL语句（或精制的SQL指纹）搜索 - - >查看SQL执行时间消耗，请参阅类似的SQL执行时间消费时间消耗时间消耗时间消耗时间消耗如下：
可以看出，大多数执行时间都是时间 - 在执行过程中进行耗费，而在其他阶段的时间很少。
值得注意的是，协处理器的累积时间 - 累积的执行看起来比SQL的执行时间还要大。这是因为TIKV将并行处理任务，因此累积执行时间不是自然传递时间的时间。
让我们看一下SQL的基本信息：
从SQL的基本信息中，还可以看出，SQL使用的当前统计数据是伪，伪代表不准确的统计信息，这可能会导致TIDB基于成本的执行计划以选择错误。
在上述理论基础上，问题的解决方案变得简单。
根据官方文档，我们使用分析表log_xxxx_2022_4重新收集此表的统计信息，然后重新执行查询：
从最新的SQL执行计划中，不难找到：
1.在执行计划中，从2W开始到当前2.15行的估计行远程口气，实际号码。
2. SQL的执行时间变为0.00，这意味着执行时间在10ms之内。
现在我们比较执行时间：
在收集统计信息之前：SQL执行26S
统计信息收集之后：SQL执行0.00
分析操作允许整个SQL执行时间（超过1000次）！
修改后，商务同学的反馈查询速度得到了显着提高，并且可以看到肉眼的监测：
从上面的情况下，可以发现，如果表的统计信息使用伪，则可能会引起缓慢的查询。因此，在实际应用中，我们需要将使用伪统计信息的SQL绑定。您可以使用以下方法进行领带：
使用上面的SQL查找使用伪统计的所有SQL，并手动执行分析表操作。
上述SQL的输出样本如下：下面：
此参数表示修改的行/表总数的比率。当超过该值时，系统将相信统计信息已过期，并且将使用伪。该值的默认值为0.8，最小值为0.1。这是统计信息判断的标准。
可以将此参数调整为1，因此TIKV执行SQL时不会选择伪统计信息。
该变量用于控制表统计信息到期后TIDB优化器的行为。默认值已打开。
如果使用默认值，则表的统计信息到期后，表示优化器认为当前表是无效的，因此其他统计信息已无效，因此将使用伪统计信息；
如果您使用的是，即使表上的统计信息无效，也不会使用当前表的统计信息，也不会使用伪。，建议使用OFF选项。
登录到tidb的仪表板，单击tidb --->统计信息--->伪估计操作面板。
如果使用伪统计信息的SQL太多，则意味着我们的统计信息有很多故障，并且需要在此类SQL访问的表上重新组织信息统计信息。
在这一点上，解决了上述问题，我们也知道如何研究使用伪统计的SQL。
让我们尝试首先编写一些摘要：
1.在遇到缓慢的查询时，我们通常需要一系列分析，包括对SQL历史操作，SQL语义分析，表结构分析的理解，与SQL访问表相对应，执行计划的分析等。
2. TIDB仪表板中的慢日志模块已帮助用户编译相关信息，我们必须学会使用现有功能来检查问题。
3.解决问题后，您还应该找到一种方法来防止问题从源头发生。
实际上，如果您更仔细地考虑它，因为TIDB本身会收集统计信息，那么它的收集策略是什么？相交的策略是什么，为什么它具有收集统计信息的功能，而我们的表仍然使用伪统计信息？我在这里提醒您一点官方文件：
有关统计信息的更多详细信息，请等待每个人在实践和发现中探索。:)
原始作者：Asiaye出版：2022/4/26原始链接：https：//tidb.net/blog/df697598
原始：https：//juejin.cn/post/7094898741265563656