使用PARTITION BY RANGE 的大表,执行select * from table limit 1;性能非常差

为提高效率,提问时请提供以下信息,问题描述清晰可优先响应。

  • 【TiDB 版本】:3.0.5
  • 【问题描述】: 我们将mysql的表导入到tidb;条数超过250亿。表使用PARTITION BY RANGE ( to_days(insert_time) 来分区; 我们有一个查询平台,默认会触发类似select * from table limit 1这种语句,每次打开查询平台,对应的tidbserver都会oom; 使用explain select * from table limi 1;发现这个sql 扫描了所有的partiton。 请问有什么办法能够避免select * from table limit 1 这种sql 扫描所有的partition,提升这种sql的查询性能避免server的oom?

若提问为性能优化、故障排查类问题,请下载脚本运行。终端输出的打印结果,请务必全选并复制粘贴上传。

在做探活么? 改写成这样子呗:

select * from table t partition(p0) limit 1;

这个语法叫 partition selection

您发的这种sql是可以的,但是查询平台要适配其他的数据库,没法加partition限制。 还有其他的办法吗?

如果是探活的作用,可以考虑使用 where 来做:比如 where 1 = 2 这种。另外如果内存比较小,进行 select limit 1 查询出现 OOM 的概率也很高。

server使用的是128G内存的aws ec2。主要是表太大了。有么有其他方法避免?如果把表改成非分区表,会有这种问题吗?

上面有介绍 where 方式,不知道能否满足需求。

where方式可以的; 请问tidb的分区表和非分区表在查询性能上会有多大的性能差异?如果我把我这个250亿条数据的表改成非分区,是否建议这样做?期待您的解答,谢谢!!!

目前这个 where 走了全分区扫描会再确认下。

性能差异的话,分区表在分区键的查询前提下,region 范围会小很多。

改成非分区需要根据具体情况来看。

这种不带条件的limit不能通过优化器优化成只查询需要记录就返回结果

这个问题,不知道有没有解决方案?
目前我碰到也是类似的,我的情况不一样
我们使用Sqoop导出到tidb,结果他会生成一条 select *from table limit 1,这个我们一般又控制不了
40亿 的记录,这个语句执行直接卡死了~~~~就不能优化成不走全表扫描吗

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。