求助大佬，doris2.1.4 detail模型在带有日分区的like条件下count很慢，要好几秒，怎么解决？

建表语句如下，数据按日分区。

CREATE TABLE `browser_domain_problem_url_v2` (
  `uuid` VARCHAR(50) NULL COMMENT 'uuid',
  `problem_uuid` VARCHAR(50) NULL COMMENT '上级uuid',
  `url` TEXT NULL COMMENT '请求地址',
  `cookie` TEXT NULL COMMENT 'Cookie',
  `remote_address` VARCHAR(4024) NULL COMMENT '地址',
  `time` INT NULL COMMENT '花费的时间',
  `status_code` VARCHAR(50) NULL COMMENT 'http状态码',
  `response` TEXT NULL COMMENT '响应数据',
  `problem_id` INT NULL COMMENT '问题id',
  `add_time` INT NULL COMMENT '添加时间',
  `tunnel_code` INT NULL COMMENT '请求类型',
  `request_header` TEXT NULL COMMENT '请求',
  `response_header` TEXT NULL COMMENT '响应头',
  `log_time` INT NULL COMMENT '添加时间',
  `type` TINYINT NULL COMMENT '类型',
  INDEX add_time_index (`add_time`) USING INVERTED COMMENT '',
  INDEX url_ngram_idx (`url`) USING NGRAM_BF PROPERTIES("gram_size" = "8", "bf_size" = "1024") COMMENT ''
) ENGINE=OLAP
DUPLICATE KEY(`uuid`)
COMMENT 'OLAP'
PARTITION BY RANGE(`add_time`)
(PARTITION p20240731 VALUES [("-2147483648"), ("1722441600")),
PARTITION p20240801 VALUES [("1722441600"), ("1722528000")),
PARTITION p20240802 VALUES [("1722528000"), ("1722614400")),
PARTITION p20240803 VALUES [("1722614400"), ("1722700800")),
PARTITION p20240804 VALUES [("1722700800"), ("1722787200")),
PARTITION p20240805 VALUES [("1722787200"), ("1722873600")),
PARTITION p20240806 VALUES [("1722873600"), ("1722960000")),
PARTITION p20240807 VALUES [("1722960000"), ("1723046400")),
PARTITION p20240808 VALUES [("1723046400"), ("1723132800")),
PARTITION p20240809 VALUES [("1723132800"), ("1723219200")),
PARTITION p20240810 VALUES [("1723219200"), ("1723305600")),
PARTITION p20240811 VALUES [("1723305600"), ("1723392000")),
PARTITION p20240812 VALUES [("1723392000"), ("1723478400")),
PARTITION p20240813 VALUES [("1723478400"), ("1723564800")),
PARTITION p20240814 VALUES [("1723564800"), ("1723651200")),
PARTITION p20240815 VALUES [("1723651200"), ("1723737600")),
PARTITION p20240816 VALUES [("1723737600"), ("1723824000")),
PARTITION p20240817 VALUES [("1723824000"), ("1723910400")),
PARTITION p20240818 VALUES [("1723910400"), ("1723996800")),
PARTITION p20240819 VALUES [("1723996800"), ("1724083200")),
PARTITION p20240820 VALUES [("1724083200"), ("1724169600")),
PARTITION p20240821 VALUES [("1724169600"), ("1724256000")),
PARTITION p20240822 VALUES [("1724256000"), ("1724342400")),
PARTITION p20240823 VALUES [("1724342400"), ("1724428800")),
PARTITION p20240824 VALUES [("1724428800"), ("1724515200")),
PARTITION p20240825 VALUES [("1724515200"), ("1724601600")),
PARTITION p20240826 VALUES [("1724601600"), ("1724688000")),
PARTITION p20240827 VALUES [("1724688000"), ("1724774400")),
PARTITION p20240828 VALUES [("1724774400"), ("1724860800")),
PARTITION p20240829 VALUES [("1724860800"), ("1724947200")),
PARTITION p20240830 VALUES [("1724947200"), ("1725033600")),
PARTITION p20240831 VALUES [("1725033600"), ("1725120000")),
PARTITION p20240901 VALUES [("1725120000"), ("1725206400")),
PARTITION p20240902 VALUES [("1725206400"), ("1725292800")),
PARTITION p20240903 VALUES [("1725292800"), ("1725379200")),
PARTITION p20240904 VALUES [("1725379200"), ("1725465600")),
PARTITION p20240905 VALUES [("1725465600"), ("1725552000")),
PARTITION p20240906 VALUES [("1725552000"), ("1725638400")),
PARTITION p20240907 VALUES [("1725638400"), ("1725724800")),
PARTITION p20240908 VALUES [("1725724800"), ("1725811200")),
PARTITION p20240909 VALUES [("1725811200"), ("1725897600")),
PARTITION p20240910 VALUES [("1725897600"), ("1725984000")),
PARTITION p20240911 VALUES [("1725984000"), ("1726070400")),
PARTITION p20240912 VALUES [("1726070400"), ("1726156800")),
PARTITION p20240913 VALUES [("1726156800"), ("1726243200")),
PARTITION p20240914 VALUES [("1726243200"), ("1726329600")),
PARTITION p20240915 VALUES [("1726329600"), ("1726416000")),
PARTITION p20240916 VALUES [("1726416000"), ("1726502400")),
PARTITION p20240917 VALUES [("1726502400"), ("1726588800")),
PARTITION p20240918 VALUES [("1726588800"), ("1726675200")),
PARTITION p20240919 VALUES [("1726675200"), ("1726761600")),
PARTITION p20240920 VALUES [("1726761600"), ("1726848000")),
PARTITION p20240921 VALUES [("1726848000"), ("1726934400")),
PARTITION p20240922 VALUES [("1726934400"), ("1727020800")))
DISTRIBUTED BY HASH(`uuid`) BUCKETS 1
PROPERTIES (
"replication_allocation" = "tag.location.default: 1",
"is_being_synced" = "false",
"storage_medium" = "hdd",
"storage_format" = "V2",
"light_schema_change" = "true",
"disable_auto_compaction" = "false",
"enable_single_replica_compaction" = "false"
);

实际执行的查询语句：

SELECT count(*) FROM `browser_domain_problem_url_v2`  PARTITIONS(p20240909) WHERE  `url` LIKE '%https://seller.shopee.co.th%'

其中url字段是string类型，有建了ngram索引，这个p20240909分区里大概有12GB的数据，实际执行起来好几秒，至少5S以上，但是不加count(*)很快，直接 *的话是毫秒级。我按这样去查过一个800MB左右的分区p20240902也要1S多。

分区数据分布情况，未来数据还会逐步增加，整个表总数据7000多万，按理也不是非常大，我这个是一个网站访问的日志记录。

p20240827 79.179 MB
p20240828 167.612 MB
p20240829 187.655 MB
p20240830 582.778 MB
p20240831 450.885 MB
p20240901 168.743 MB
p20240902 829.001 MB
p20240903 1002.353 MB
p20240904 1.932 GB
p20240905 6.089 GB
p20240906 10.517 GB
p20240907 7.025 GB
p20240908 4.212 GB
p20240909 12.497 GB
p20240910 11.628 GB
p20240911 11.713 GB
p20240912 12.764 GB
p20240913 12.853 GB
p20240914 11.673 GB
p20240915 6.039 GB
p20240916 4.672 GB
p20240917 3.347 GB
p20240918 298.008 MB