为提高效率，提问时请提供以下信息，问题描述清晰可优先响应。
- 【TiDB 版本】：
- 【问题描述】：服务器 16核 内存64G 共三台服务器 其中一台同时部署了tidb和tikv 查询单表数据300w ,查询特别慢 请问这跟部署的有关系吗
若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。
生产环境建议按照官网推荐的标准部署。 https://pingcap.com/docs-cn/stable/how-to/deploy/hardware-recommendations/
tikv 是不建议和 pd 或者 tidb 混合部署的，如果是简单 sql 的话，可以结合执行计划以及慢查询来看下是否可以优化。
-
- 检查 SQL 涉及的表的执行计划是否是最新，注意 https://pingcap.com/docs-cn/v3.0/reference/performance/statistics/
-
- 确认 SQL Plan 是否符合预期，走上预期索引，有没有 cost 特别高的执行计划 https://pingcap.com/docs-cn/v3.0/reference/performance/understanding-the-query-execution-plan/
-
- 检查 TiKV 存储的 region size 的平均值是否在 96MB 左右 https://pingcap.com/docs-cn/v3.0/reference/key-monitoring-metrics/tikv-dashboard/
-
- 检查 TiDB 集群中 CPU 资源瓶颈和 scan key 的数据量，确认当前瓶颈的点，适当调整 coprocessor 和 conccurency 情况 https://pingcap.com/docs-cn/v3.0/reference/performance/tune-tikv/
1 个赞
辛苦你这边 检查 SQL 涉及的表的执行计划是否是最新，注意 https://pingcap.com/docs-cn/v3.0/reference/performance/statistics/
另外麻烦提供下 tidb 的版本、两个表结构、数据量、以及该 sql 的慢查询日志吧
慢查询日志 SELECT * FROM michain_enterprise_test.t_bill LIMIT 0, 1000 2020-02-20 16:31:42.353867 00:00:04 Process_time: 0.012 Request_count: 1 Total_keys: 2017 Process_keys: 2016 1 16 414760960611844097 root michain_enterprise_test [4635] 0 d090fb61de8f46382f98ad19b6f30cbc9697db801b4c2c8531dc07f06ff72afd
tidb 版本是 3.0.9
b_bill 是300万数据
您好，您这边提供的两个 sql 前后不一致，请确认下，是哪个 sql 执行比较慢？要分析哪个 sql 呢 ？
第一个是两个表走了 hash join ，如果确认cpu 资源比较多，可以尝试调整 hash join 的 concurrency 的大小。另外一张表应该也可以加索引试试。
目前服务器是16核的 查询时发现tidb-server占用内存和cpu较多 内存一直再涨
您好：预格式化文本
- 麻烦再明确一下当前的问题，您觉得哪里有问题？ 是不该占用这么多cpu，还是需要查看哪个sql运行慢？
- tidb-server的cpu达到98%时，总的cpu使用率是多少？ 请截取top的完整信息
- 看你的这个sql是查询对吧？ 请帮忙执行explain analyze 看一下实际执行的执行计划，多谢.
1.上个问题是 tidb和tikv放一起会严重影响性能吗
如果我再添加一台服务器 ,默认配置的话 ,请问查询速度能否上去
3.查询sql 这是查询慢日志
select SUM(t.sum_bill_price) as sumBillPrice from t_bill t left join t_company tc on tc.company_code=t.company_code WHERE 1=1 2020-02-21 11:05:22.455113 00:00:00 Process_time: 5.236 Wait_time: 0.008 Request_count: 19 Total_keys: 3000397 Process_keys: 3000378 1 2 414778477100138499 root@172.18.218.80 michain_enterprise_test [4635] [t_company:t_company_code] 0 fdf99c586286fab67b9961badd75aab963d60f6ec967fc7723685f9647b96716
执行计划
您好：预格式化文本
1.从你的执行计划看当前执行此sql语句只需要769ms， 但是慢日志中达到了5s多， 所以你的问题不是这个sql执行的慢，是你在开启了并发的时候，sql执行变慢，对吗？ 你的并发数是多少？ 如果是并发的问题，请反馈一下grafana的监控，看一下系统的瓶颈在哪里. 采集over-view，tidb， tikv-detail三个面板 ，步骤如下：
（1）、chrome 安装这个插件https://chrome.google.com/webstore/detail/full-page-screen-capture/fdpohaocaechififmbbbbbknoalclacl （2）、鼠标焦点置于 Dashboard 上，按 ?可显示所有快捷键，先按 d 再按 E 可将所有 Rows 的 Panels 打开，需等待一段时间待页面加载完成。 （3）、使用这个 full-page-screen-capture 插件进行截屏保存
-
从监控看leader分布不均匀，149和77的leader差的比较多，这两个tikv上的磁盘空间不一样大吗？ df -h检查下
-
看起来有热点读的问题，你在大概11点左右测试的吧，当时使用的测试sql，都是这一条sql吗？ select SUM(t.sum_bill_price) as sumBillPrice from t_bill t left join t_company tc on tc.company_code=t.company_code WHERE 1=1
-
t_company 和 t_bill 表的数量是多少，有没有哪个表很小？
1.149磁盘较小 120G 77为300G
2.测试sql有两条 这是另一条
SELECT count(0) FROM t_bill t LEFT JOIN t_bill_company tc ON tc.company_code = t.company_code LEFT JOIN t_bill_tobeinvoiced tbt ON tbt.bill_serial_num = t.bill_serial_num
3.t_company 表400条 t_bill 300万条数据
慢日志
SELECT count(0) FROM t_bill t LEFT JOIN t_bill_company tc ON tc.company_code = t.company_code LEFT JOIN t_bill_tobeinvoiced tbt ON tbt.bill_serial_num = t.bill_serial_num 2020-02-21 11:05:20.711449 00:00:01 Process_time: 2.072 Request_count: 7 Total_keys: 3012430 Process_keys: 3012423 1 2 414778476641386498 root@172.18.218.80 michain_enterprise_test [t_bill:t_company_code_bill_serial_num,t_bill_company:companyCode,t_bill_tobeinvoiced:t_b_tobe_t_bill_tobeinvoiced] 0 bdc40366fd81c2e788ecbb6285ff75b3a36bef294d0d29c5373dfe562bd3ecf9
请保证每个tikv上的容量一致，不然会出现当前leader不均衡的情况，大多数查询都落在了77上。 试着先让leader均衡，再试一下.
需要增加一下149的容量对吗? 增加容量后,需要重新插入测试数据吗?
你可以再找一个相同容量的机器，先扩容tikv，再缩容这个容量小的tikv就可以了.
https://pingcap.com/docs-cn/stable/how-to/scale/with-ansible/
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。