如何高效优化文本列中多个GUID的查询性能？

你的问题核心是大量LIKE '%GUID%'串联导致全表扫描，性能暴跌，以下是几种可行的优化方式：

1. 临时表关联查询（最推荐） #

先把1080个GUID导入临时表，再通过字符串匹配关联原表，避免大量OR条件：

-- 创建临时表（以Oracle为例，不同数据库语法略有差异）
CREATE GLOBAL TEMPORARY TABLE temp_guids (guid VARCHAR2(36)) ON COMMIT PRESERVE ROWS;

-- 批量插入所有GUID
INSERT INTO temp_guids VALUES ('c016a45d-1e81-472d-a161-79369f87d6a0');
INSERT INTO temp_guids VALUES ('7e5a1766-c26e-4050-8120-25160bbcf5fb');
-- ... 剩余1078个GUID

-- 关联查询，用INSTR比LIKE更高效
SELECT t.*
FROM table_name t
JOIN temp_guids g ON INSTR(t.purpose, g.guid) > 0
WHERE t.CURR_DAY BETWEEN TO_DATE('2023-08-26', 'yyyy-mm-dd') AND TO_DATE('2023-10-11', 'yyyy-mm-dd');

如果担心匹配到GUID的子串（比如描述中刚好包含GUID的部分字符），可以用正则匹配完整GUID：

JOIN temp_guids g ON REGEXP_LIKE(t.purpose, '\b' || g.guid || '\b')

（注：\b是单词边界，不同数据库正则语法可能不同，比如Oracle可改用\W匹配非单词字符）

2. 集合子查询替代OR串联 #

如果不想建临时表，可把GUID列表转成集合，用EXISTS结合字符串匹配：

SELECT *
FROM table_name
WHERE CURR_DAY BETWEEN TO_DATE('2023-08-26', 'yyyy-mm-dd') AND TO_DATE('2023-10-11', 'yyyy-mm-dd')
AND EXISTS (
    SELECT 1
    FROM (
        SELECT 'c016a45d-1e81-472d-a161-79369f87d6a0' guid FROM DUAL
        UNION ALL SELECT '7e5a1766-c26e-4050-8120-25160bbcf5fb' FROM DUAL
        -- ... 剩余1078个GUID
    ) guids
    WHERE INSTR(table_name.purpose, guids.guid) > 0
);

这种方式比原OR串联更高效，数据库会优化集合查询逻辑，避免重复扫描。

3. 建立全文索引（长期高频查询优化） #

如果这类文本匹配查询是高频操作，给purpose列建立全文索引：

• Oracle：创建CONTEXT索引

  CREATE INDEX idx_purpose_fulltext ON table_name(purpose) INDEXTYPE IS CTXSYS.CONTEXT;
  

  查询时用CONTAINS：

  SELECT *
  FROM table_name
  WHERE CURR_DAY BETWEEN TO_DATE('2023-08-26', 'yyyy-mm-dd') AND TO_DATE('2023-10-11', 'yyyy-mm-dd')
  AND CONTAINS(purpose, 'c016a45d-1e81-472d-a161-79369f87d6a0,7e5a1766-c26e-4050-8120-25160bbcf5fb,...') > 0;
  

• MySQL：创建全文索引

  CREATE FULLTEXT INDEX idx_purpose_fulltext ON table_name(purpose);
  

  查询时用MATCH AGAINST：

  SELECT *
  FROM table_name
  WHERE CURR_DAY BETWEEN '2023-08-26' AND '2023-10-11'
  AND MATCH(purpose) AGAINST('"c016a45d-1e81-472d-a161-79369f87d6a0" "7e5a1766-c26e-4050-8120-25160bbcf5fb"' IN BOOLEAN MODE);
  

全文索引能大幅提升模糊匹配性能，适合高频文本搜索场景。

原查询慢的原因 #

每个LIKE '%xxx%'都会触发全表扫描（前缀通配符会让普通B树索引失效），1080个OR条件相当于数据库要执行1080次全表扫描的逻辑判断，性能自然暴跌。

内容的提问来源于stack exchange，提问作者Sanjar Yuldashev