【 TiDB 使用环境】生产环境
【 TiDB 版本】v6.5.1
【复现路径】执行explain analyze
【遇到的问题:问题现象及影响】看信息不知道如何优化
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件:截图/日志/监控】
看看执行计划,再trace sql看看
operator info
结果
EXPLAIN
返回结果中 operator info
列可显示诸如条件下推等信息。本文以上示例中,operator info
结果各字段解释如下:
-
range: [1,1]
表示查询的WHERE
字句 (a = 1
) 被下推到了 TiKV,对应的 task 为cop[tikv]
。 -
keep order:false
表示该查询的语义不需要 TiKV 按顺序返回结果。如果查询指定了排序(例如SELECT * FROM t WHERE a = 1 ORDER BY id
),该字段的返回结果为keep order:true
。 -
stats:pseudo
表示estRows
显示的预估数可能不准确。TiDB 定期在后台更新统计信息。也可以通过执行ANALYZE TABLE t
来手动更新统计信息。
EXPLAIN
执行后,不同算子返回不同的信息。你可以使用 Optimizer Hints 来控制优化器的行为,以此控制物理算子的选择。例如 /*+ HASH_JOIN(t1, t2) */
表示优化器将使用 Hash Join 算法。详细内容见 Optimizer Hints。
你现在想解决的问题是什么?
优化sql
rpc _num , rpc_time :向 TiKV 发送 Cop 类型的 RPC 请求总数量和总时间
大佬能讲一下吗,面对复杂tidb sql的时候要从哪里开始优化,现在很迷茫。一个几百行的sql,或者几千行的sql根本不知道慢在哪里?
只能是执行计划
我trace一下3万多行。。。。我怎么看。。。。
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。