无标题.sql (2.2 KB)
-
这个执行计划应该是没问题的。 读 bill_detail 表用了147ms。读btd这个表用了8.5s（并行时间） 总时间2.4秒 可以尝试调大 tidb_index_lookup_join_concurrency 到 8 ，如果有效，再调大到 16 看看
-
在 session 级别调整方法如下
这个时间是查询相同的sql，每次执行结果不一样，还是说 value 值不同，每次查询结果不一样？
查询相同的sql，执行结果一样，value值是相同的，每次查询返回的时间不一样
能否麻烦您再测试一下，是否不同的时间，是因为执行计划选择的索引不同，多谢。
执行 explain analyze sql ，多次执行，测试下，多谢。
你好，这个sql是采用 force index 指定和mysql相同的索引执行的，所以每次选择的索引是相同的，执行的就是explain analyze sql
- 请问，这个库的负载如何？ 是否业务压力比较大，所以在查询时，有时系统负载较高有影响？ 麻烦查看下 over-view 监控，duration ，loader ，cpu，memory等值，多谢。
- 还是说是空库，没有业务压力？
- 看您集群负载已经比较高了，cpu 几乎打到了 100%。 感觉是和集群整体性能有关。
- 您是否有空负载的测试环境，可以测试下，理论上每次查询时间是一致的； 或者，在集群负载很低的情况下，试试每次查看的差距是否时间比较长，多谢。
你好，昨天的确实是负载高导致的查询时间差距较大，但是这个大表left join 和 mysql 的left join 原理是否还是有区别的
您可以参考下这篇文章
你好针对于join的问题我们做了sql的优化
SELECT count(*) from (
SELECT
( SELECT
count( 0 )
FROM
bill_trade_detail btd
WHERE
btd.bill_trans_no = bd.bill_trans_no
AND btd.merchant_id = 112454
AND btd.bill_type = 2
) AS tradeCount
FROM
bill_detail bd
WHERE
bd.merchant_base_info_id = 112454
) aa
将原本的left join语句变成了参数子查询 发现一个问题
两次sql唯一不同的是查询的字段值不一样，表结构上述已提供
请问问题是什么？ 麻烦帮忙明确下，辛苦了
问题是同一条参数子查询的sql，我们更改了这个字段值以后，执行计划变化就这么大，测试了其它不同的值，也没啥问题，目前就发现这个执行计划不一样
我们这个sql，merchant_base_info_id是指的我们商户ID， 问题就是同一个sql，指定不同的商户id，112454商户数据执行计划看样是没走索引，全表扫了。
哦哦，非常感谢。我们对bill_trade_detail 表执行了ANALYZE TABLE bill_trade_detail ；后发现执行计划是正常的了。 那么有2个疑问是： 1、是统计信息导致出现上面问题的，那么统计信息是什么原因导致不正确的呢？ 2、那么我们如何主动检查某个表的统计信息是否有问题呢？
- 可以参考文档。数据在不断增长，统计信息达到阈值时才会更新
https://pingcap.com/docs-cn/stable/statistics/#统计信息简介
- 可以查看 health 信息，如果低于80 可能需要重新收集。 对于一些大表由于要达到 0.5 的阈值比较困难，所以可以考虑对大表设定定时任务，业务低峰期，定时收集。 以后的版本会有 SPM 来避免这些问题。