【 使用环境 】生产环境 or 测试环境
【 OB or 其他组件 】
【 使用版本 】4.3.5.4
【问题描述】清晰明确描述问题
【复现路径】
从3.4.1版本升级到 3.5.4版本后。 大量sql执行选择的路径都变差劲了。 如下一个简单的 in查询，有索引的。也去全表扫描了。 重新全库做过 数据统计。也没用。升级版本后，怎么优化这一问题
SELECT
*
FROM
msg_flash_sale_tiktok
WHERE
promotion_id IN (
?,?,?,?,?,?, …不到500个
)
1 个赞
使用obdiag收集一下plan_monitor
obdiag gather plan_monitor --trace_id YB420BA2D99B-0005EBBFC45D5A00-0-0 --env “{db_connect=’-hxx -Pxx -uxx -pxx -Dxx’}”
https://www.oceanbase.com/docs/common-obdiag-cn-1000000004222802
看看执行计划
大量Sql执行慢,需要优化SQL。
感觉3.4.1 升级到 3.5.4版本后。 对于in范围较大或者关联查询中，左表数据较多时。 解释器，更倾向于缓存全表。做全表扫描。
有没有能调节这个选择的参数。
很多情况下，复杂sql，是根据mysql的执行习惯进行编写的。
比如简单的
select
- from tableA as t1
left join tableB as t2 on t1.xxx = t2.xxx
where t1.id in(…)
默认情况下虽然t1可能查询的数据较多。 但是通过索引关联查询t2表的话。走索引不会慢。
但是oceanbase一旦t1查询的数据多了。 就会选择扫表。
像上的sql
更新前，执行器选择
更新后，执行器选择
更新一天后，又正确选择了走索引
按照我发的使用obdiag收集一下 提供一下plan_monitor信息 要不然也不知道什么原因