为提高效率,提问时请提供以下信息,问题描述清晰可优先响应。
- 【TiDB 版本】:4.0.0
- 【问题描述】:从3.1升级到4.0后,查询耗时明显增加。
截取了其中一个慢SQL,截图感觉有点奇怪。为什么优化耗时这么长
若提问为性能优化、故障排查类问题,请下载脚本运行。终端输出打印结果,请务必全选并复制粘贴上传。
为提高效率,提问时请提供以下信息,问题描述清晰可优先响应。
截取了其中一个慢SQL,截图感觉有点奇怪。为什么优化耗时这么长
若提问为性能优化、故障排查类问题,请下载脚本运行。终端输出打印结果,请务必全选并复制粘贴上传。
测试下来发现,几乎所有的SQL,查询都很不稳定,同样的SQL,可能耗时会有几十倍的区别。看监控发现TiFlash的Region区别很大。不知道有没有关系。
比如:
select count(*) from order_record
麻烦用 explain analyze sql 反馈这个sql,不同执行时间的执行计划,我们分析下,多谢。
https://pingcap.com/docs-cn/v3.0/query-execution-plan/#理解-tidb-执行计划
基本可以确定,是TiFlash的性能,抖动的特别厉害。
请问集群整体负载如何? 麻烦上传{TiDB_Cluster_name}-TiFlash-Summary 和 detail-tikv 的监控,多谢。
(1)、chrome 安装这个插件https://chrome.google.com/webstore/detail/full-page-screen-capture/fdpohaocaechififmbbbbbknoalclacl
(2)、鼠标焦点置于 Dashboard 上,按 ?可显示所有快捷键,先按 d 再按 E 可将所有 Rows 的 Panels 打开,需等待一段时间待页面加载完成。
(3)、使用这个 full-page-screen-capture 插件进行截屏保存
使用TIUP,缩容了所有TIFlash,然后再扩容回来。发现速度快了很多,比刚升级强很多。怀疑从3.1RC使用TIUP升级,TiFlash会有问题。
PS:下方截图中,21分左右有大量的OLAP分析查询,所以CPU比较高。
你好 最开始提问图里的慢日志 说优化时间要5.5秒 这个慢日志的 SQL 帮忙提供一下吧
SELECT
(
SELECT
count(*)
FROM
campus_user
WHERE
campus = '57c5a459-b536-43c4-ab97-f2db739b5031'
) AS user,
(
SELECT
/*+ read_from_storage(tiflash[campus_user]) */
count(*)
FROM
campus_user
WHERE
campus = '57c5a459-b536-43c4-ab97-f2db739b5031'
AND create_time >= DATE_FORMAT(CURDATE(), '%Y-%m-%d %H:%i:%s')
) AS newUser,
(
SELECT
/*+ read_from_storage(tiflash[u]) */
count(*)
FROM
campus_user cu
LEFT JOIN user u ON u.uuid = cu.user
WHERE
cu.campus = '57c5a459-b536-43c4-ab97-f2db739b5031'
AND u.authed = 1
) AS authUser;
帮忙再提供一下这个Sql的执行计划吧 Explain sql 然后贴一下结果
已经确认是升级后,TiFlash异常造成的,已经解决
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。