doris唯一建模型对本表子查询特别慢，cpu跑满

Viewed 88
2.0 

SELECT
   *
from
   a_database.a_table
WHERE
   o_id in(
   SELECT
      o_id
   FROM
      a_database.a_table
   WHERE
      d_id = 878112
   order by
      create_time
   limit 10);

sql 如上 数据量大概20多亿，表为唯一键模型，key 为 o_id 分桶100 无分区
image.png
如果分别对子查询和子查询的结果进行in查询 子查询约1～2s返回，in查询毫秒返回
但查询合并就要等很久超过正常的计算时间，且cpu跑满

查询计划如下（表字段100多，这个表是在1.2.6的版本建的，后面doris集群升级到了2.0.13）

PARTITION: UNPARTITIONED

  HAS_COLO_PLAN_NODE: false

  VRESULT SINK

  970:VEXCHANGE
     offset: 0
     limit: 400

PLAN FRAGMENT 1

  PARTITION: HASH_PARTITIONED: o_id[#150]

  HAS_COLO_PLAN_NODE: false

  STREAM DATA SINK
    EXCHANGE ID: 970
    UNPARTITIONED

  961:VHASH JOIN
  |  join op: LEFT SEMI JOIN(BUCKET_SHUFFLE)[]
  |  equal join conjunct: o_id[#295] = o_id[#149]
  |  runtime filters: RF000[in_or_bloom] <- o_id[#149](-1/0/2097152)
  |  cardinality=1,490,624,495
  |  vec output tuple id: 7
  |  vIntermediate tuple ids: 6 
  |  hash output slot ids: 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 
  |  limit: 400
  |  
  |----958:VEXCHANGE
  |       offset: 0
  |    
  929:VOlapScanNode
     TABLE: default_cluster:a_database.a_table(a_table), PREAGGREGATION: ON
     PREDICATES: __DORIS_DELETE_SIGN__[#293] = 0
     runtime filters: RF000[in_or_bloom] -> o_id[#150]
     partitions=1/1 (a_table)
     tablets=100/100, tabletList=211968,211972,211976 ...
     cardinality=2981248990, avgRowSize=0.0, numNodes=1
     pushAggOp=NONE
     projections: o_id[#150],..., combine_pay[#288], request_transport_channel[#289], dispatch_transport_channel[#290], supplier_id[#291], create_day[#292]
     project output tuple id: 5

PLAN FRAGMENT 2

  PARTITION: UNPARTITIONED

  HAS_COLO_PLAN_NODE: false

  STREAM DATA SINK
    EXCHANGE ID: 958
    BUCKET_SHFFULE_HASH_PARTITIONED: o_id[#149]

  949:VMERGING-EXCHANGE
     offset: 0
     limit: 10
     projections: o_id[#147]
     project output tuple id: 3

PLAN FRAGMENT 3

  PARTITION: HASH_PARTITIONED: o_id[#0]

  HAS_COLO_PLAN_NODE: false

  STREAM DATA SINK
    EXCHANGE ID: 949
    UNPARTITIONED

  946:VTOP-N
  |  order by: create_time[#148] ASC
  |  offset: 0
  |  limit: 10
  |  
  936:VOlapScanNode
     TABLE: default_cluster:a_database.a_table(a_table), PREAGGREGATION: ON
     PREDICATES: d_id[#24] = 878112 AND __DORIS_DELETE_SIGN__[#143] = 0
     partitions=1/1 (a_table)
     tablets=100/100, tabletList=211968,211972,211976 ...
     cardinality=2981248990, avgRowSize=0.0, numNodes=1
     pushAggOp=NONE
     projections: o_id[#0], create_time[#99]
     project output tuple id: 1
danvid3
1 Answers
徐振超@SelectDB6501