您好：
1. explain sql对于相同的sql语句，执行计划应该是一样的，这里有可能是具体的where条件中代入值不同，导致扫描的key数量级相差比较大. 方便执行explain ananlze看下吗？
2. 麻烦新的问题创建个新帖子，尽量一个问题在一个帖子里答复，这样方便其他人查看，并且追踪问题也会高效很多，多谢。Leader Balance 和 Region Balance 100%
explain analyze …不是explain 这样后面会有具体的扫描行数。。可能就是楼上大佬说的 因为条件不一样 扫描的key 不同导致
按这个扫描量级 应该不会这么慢啊。。。TIKV的配置都一样吗？
TiKV 的机型、配置完全一样。并且，同一台机器的其他实例也正常啊。
(不过，提醒一下后面看到这个帖子的人，慢的 store 会迁移，最开始在 172.16.150。92:20182，然后是 172.16.150.121:20180，现在是 172.16.150.121:20182)
方便提供一下 PD 监控面板中 Operator 和 Statistics-balance 相关的监控么，我这边看下 region 调度的情况会不会有影响
确认一下目前需要看的实际是两个问题是吧
第一个问题：往 TiDB 导入大量数据之后，查询变慢，从亚秒级变成了秒级的，相同的查询在满日中记录有执行 0 点几秒的，有执行十几秒的，手动执行的时候速度正常
第二个问题：从 95% Wait duration by store 监控看到，有某一个 store 比较慢，且这个 store 随着时间变化，会迁移。
关于第一个问题可以看下慢日志记录的信息，对应 0 点几秒和十几秒执行的 SQL 对应的耗时阶段是哪部分不同，定位到差异部分。v3.0.5 以上版本慢日志中会记录运行 SQL 当时的执行计划，可以判断是否有执行计划不稳定的问题，这边考虑升级集群吗？
关于第二个问题，从提供的 PD 监控看没有 Hot Region 的分布，目前查询慢的情况是一直出现还是导入完数据之后出现了一段时间，后续就正常了？
差不多是这样，慢的情况看起来是在 导入了大量数据 或者 是对要读取的表做了比较大的插入 操作之后比较明显。然后调查原因的时候，发现有一个 store 特别慢，看起来像是等待时间比较长，而且随着时间的变化，这个特别慢的 store 还会迁移。
没有大量数据写入的时候是会恢复的比较正常，查询变快，那个慢的 store 的 wait duration 短了很多。
升级集群的提议我们考虑一下。
导入完数据之后一个 store 特别慢，且随着时间变化，慢 store 会迁移，从现象看比较容易怀疑是 region 调度产生的影响，但是从提供的 PD 监控看是 last 1 hour 的监控信息，这个应该是已经恢复正常了的时候的监控了吧。
可以看下导入数据完成那段时间以及到慢 store 发生迁移到最终恢复正常这段时间的 region 调度情况 另外可以排查一下 TiKV-Detail 监控中慢 store 发生迁移时，除了 wait duration 监控指标外，还有什么指标也对应发生了迁移的
嗯，刚注意到慢 store 又发生了一次迁移。另外，有关 region 调度的历史记录从哪里可以获得？
- 请上传最近一次慢的情况发生时，一小时的监控信息，overview，tidb tikv-detail，disk-performance信息. (1)、chrome 安装这个插件https://chrome.google.com/webstore/detail/full-page-screen-capture/fdpohaocaechififmbbbbbknoalclacl
(2)、鼠标焦点置于 Dashboard 上，按 ?可显示所有快捷键，先按 d 再按 E 可将所有 Rows 的 Panels 打开，需等待一段时间待页面加载完成。
(3)、使用这个 full-page-screen-capture 插件进行截屏保存
-
上传这个时间段的tidb日志,
-
请查看集群中是否存在大的region ,反馈以下信息，多谢. 使用jq查询
./bin/pd-ctl -d region | jq “.regions | map(select(.approximate_size > 96)) | length”
./bin/pd-ctl -d region | jq “.regions | map(select(.approximate_size > 128)) | length”
./bin/pd-ctl -d region | jq “.regions | map(select(.approximate_size > 256)) | length”
./bin/pd-ctl -d region | jq “.regions | map(select(.approximate_size > 512)) | length”
现在集群的状况持续不太好，这是最近一个小时的监控，
日志上传在百度云盘，这是链接和提取码：
链接: https://pan.baidu.com/s/1f1OXs4q7mrXgx2trZaTdVg 提取码: dmnh
链接: https://pan.baidu.com/s/1aPZFLqIkckQUk_LLpRipkg 提取码: sfjp
麻烦把jq的信息也更新到帖子里，我先看下监控，多谢.
- [“compile sql error”] [conn=1030644] [error="[parser:1149]syntax error, unexpected ‘?’"] [errorVerbose="[parser:1149]syntax error, unexpected 这种解析的sql报错很多，看下是否可以修改下.
- 从监控信息看，coprocessor慢，主要在wait duration慢
- 查看慢日志都是SELECT
start_time,the_other_typeFROMmongo.mongo_mobile_raw_data_mobile_detailsWHERE ((use_time> ‘xxx’)) AND ((orderid= ‘xxx’)); - 尝试先优化这些sql. 从历史记录看，某些数据的执行时间很长. Leader Balance 和 Region Balance 100% 请帮忙上传这个表的表结构，多谢，
- [“compile sql error”] [conn=1030644] [error="[parser:1149]syntax error, unexpected ‘?’"] [errorVerbose="[parser:1149]syntax error, unexpected 这种解析的sql报错很多，看下是否可以修改下.
SQL解析报错的问题我也很纳闷，一样的 SQL（不同的只有参数值），一会正常，一会报错。报错了的，手工执行也都是正常的。
另外，SQL 本身是优化过的（其实是同样的 SQL在不同的数据上跑），只是它执行不稳定，一会儿快一会慢。
[问题澄清]
数据库版本：V3.0.4 集群拓扑： 1个服务器部署了4个tikv实例 16core，128G
问题描述： tidb集群查询慢，并且会漂移到不同的store
[问题分析]
- 查看监控信息，发现主要慢在了coprocessor wait duration
- 查看90 这个服务器的 coprocessor cpu ，达到了250%，查看配置文件中配置的是3，按理说没有到达瓶颈
- 查看所有服务器的cpu，发现总的cpu已经打满，导致coprocessor cpu在没有达到最大值时，已经到达瓶颈
[下步计划]
- 由分析中的1和2可以看出，存在热点情况，请先按照热点问题排查处理 https://github.com/pingcap-incubator/tidb-in-action/blob/master/session4/chapter7/hotspot-resolved.md
- 由分析中1，2，3看出集群已经到达瓶颈，这个时候，可以尝试先调整tikv参数配置：
[server] grpc-concurrency = 2
[raftstore] store-pool-size = 2 apply-pool-size = 1 raft-base-tick-interval = “2s”
[readpool.storage] high-concurrency = 1 normal-concurrency = 1 low-concurrency = 1
[storage] scheduler-worker-pool-size = 1
[readpool.coprocessor] # high-concurrency = 2 normal-concurrency = 4 low-concurrency = 4
这样调整是希望可以针对整体cpu不足，给coprocessor多一些cpu使用，不具有普遍操作意义。 从每个参数对应的cpu可以看出，当前使用的最大值，可以先这样调整观察
- 如果调整后，还是无法满足要求，请尝试添加CPU，或者扩容机器，分散tikv实例
问题已解决，集群恢复正常。采取了以下措施：
- 相关表添加
SHARD_ROW_ID_BITS（p.s. 相关表没有主键，TiDB会自动产生自增的隐式主键），使写入热点、以及后续高频计算带来的读热点得以分散 - 部署了 @rongyilong-PingCAP 建议的调优参数，CPU消耗得以有效降低，不再成为影响正常吞吐的瓶颈
谢谢！
