oceanbase模糊查询有没有什么好的优化办法，like %%方式性能达不到要求

OceanBase 技术问题
#1

【 使用环境 】测试环境
【 OB or 其他组件 】ob
【 使用版本 】3.x
【问题描述】使用like%%方式模糊查询慢（select count（1） from tablea where id like ‘%%’,1000W数据大概30s，也尝试过instr方式只能提高到25s， 目前最快的方式是调大并行度，请问下大佬们有没有好的方案
【复现路径】
【附件及日志】

#3

ob mysql模式
–explain 计划
explain extended select count(1) from dm_cust_label_filter_table_04_df_bak20231121_3
where data_auth like ‘%00000000000009%’

==========================================================================================
|ID|OPERATOR |NAME |EST. ROWS|COST |

|0 |SCALAR GROUP BY| |1 |4055024|
|1 | TABLE SCAN |dm_cust_label_filter_table_04_df_bak20231121_3(idx)|3332737 |3927826|

Outputs & filters:

0 - output([T_FUN_COUNT()(0x7f435be2e0e0)]), filter(nil),
group(nil), agg_func([T_FUN_COUNT()(0x7f435be2e0e0)])
1 - output([remove_const(1)(0x7f435be7dad0)]), filter([(T_OP_LIKE, dm_cust_label_filter_table_04_df_bak20231121_3.data_auth(0x7f435be2dcc0), ‘%00000000000009%’, ‘\’)(0x7f435be2cd50)]),
access([dm_cust_label_filter_table_04_df_bak20231121_3.data_auth(0x7f435be2dcc0)]), partitions(p0),
is_index_back=false, filter_before_indexback[false],
range_key([dm_cust_label_filter_table_04_df_bak20231121_3.data_auth(0x7f435be2dcc0)], [dm_cust_label_filter_table_04_df_bak20231121_3.one_id(0x7f435be6f270)]), range(,MIN ; ,MAX)

Used Hint:

/*+
*/

Outline Data:

/*+
BEGIN_OUTLINE_DATA
INDEX(@“SEL$1” “business01db.dm_cust_label_filter_table_04_df_bak20231121_3”@“SEL$1” “idx”)
END_OUTLINE_DATA
*/

Plan Type:

LOCAL

Optimization Info:

dm_cust_label_filter_table_04_df_bak20231121_3:table_rows:10000000, physical_range_rows:9998211, logical_range_rows:9998211, index_back_rows:0, output_rows:3332737, est_method:local_storage, optimization_method=cost_based, avaiable_index_name[idx], pruned_index_name[idx2,idx3,dm_cust_label_filter_table_04_df_bak20231121_3], estimation info[table_id:1181974999909207, (table_type:1, version:0-1712426410646984-1712426410646984, logical_rc:9998211, physical_rc:9998211), (table_type:7, version:1712426408416757-1712426408416757-1712426448702511, logical_rc:0, physical_rc:0), (table_type:5, version:1712426408416757-1712426408416757-1712426448702511, logical_rc:0, physical_rc:0), (table_type:0, version:1712426448702511-1712426448702511-9223372036854775807, logical_rc:0, physical_rc:0)]
Parameters

#5

看你的查询，id列为啥用like
可以问问业务种种查询到底是不是合理
最好的方法就是消除like
不然就放es去
没有万能的数据库

1 个赞
#6

大佬好，这边想要做多租户资源隔离所以考虑ob， 场景大概是业务挑选一些字段（类似地址）筛选人群然后进行推送活动，模糊查询也是存在。尝试过用类似instr函数代替like，但是效果感觉不明显，您的意思是ob这个数据库现在不太适合我这个场景么。

#7

模糊搜索用 关系数据库不是很适合，用 搜索引擎产品比较合适。

不过如果只是少数模糊搜索场景，让业务开发去弄个搜索引擎产品，也容易被驳回。

在 SQL 里 想让模糊查询更快，下面方法可能有些帮助，不保证一定有提升。

没法两全其美。

  • 大表分区。
  • SQL 加并行 HINT 。
  • 大宽表取数据尽量分页取。
1 个赞
#8

可以试一下全文索引，效率未必会高，可以测一下。

#9

社区版OB4.4才规划支持全文索引，目前暂不支持。

2 个赞