如何优化含多个LIKE条件的多SELECT语句临时表填充查询

针对你这种用多个带LIKE条件的SELECT语句往临时表#tempTable填充数据的场景，我给你整理几个实用的优化方向，都是实际项目里踩过坑后验证有效的：

• 合并多段SELECT，减少写入次数
  别一个个单独执行INSERT INTO #tempTable SELECT ...，如果各段查询的结果结构一致，直接用UNION ALL（无重复数据时优先用，比UNION快，因为不用去重）把所有查询合并成一次插入。比如：

  INSERT INTO #tempTable
  SELECT 统计字段1 FROM 表A WHERE 条件（含LIKE）
  UNION ALL
  SELECT 统计字段2 FROM 表B WHERE 条件（含LIKE）
  ...
  

  这样能减少SQL Server对临时表的多次写入操作，也减少了查询编译和执行的次数，性能提升很明显。

• 优化LIKE条件的索引利用率
  LIKE的写法直接决定了能不能用到索引：

  • 如果是前缀匹配（比如DetailItemName LIKE 'ABC%'）：给对应的列（比如DetailItemName）加非聚集索引，完全可以利用索引快速过滤数据，避免全表扫描。
  • 如果是后缀/中间匹配（比如DetailItemName LIKE '%ABC'或'%ABC%'）：普通索引基本失效，这时候可以试试这两个方案：
    1. 给列创建全文索引，用CONTAINS或FREETEXT代替LIKE，适合模糊搜索场景；
    2. 建一个反转列的计算列（比如ALTER TABLE DetailItem ADD ReverseName AS REVERSE(DetailItemName)），然后给这个计算列加索引，查询时用REVERSE(DetailItemName) LIKE REVERSE('%ABC')（也就是'CBA%'），这样就变成了前缀匹配，能用到索引。
       另外，别在LIKE条件里对列做函数运算（比如CONCAT(DetailItemName, '') LIKE '%XXX%'），这会直接导致索引失效，尽量保持列的原始形态。

• 临时表本身的优化

  • 别依赖SELECT INTO自动创建临时表，提前显式定义临时表的结构（指定列名、数据类型、长度），比如：

    IF OBJECT_ID('tempdb..#tempTable') IS NOT NULL DROP TABLE #tempTable
    CREATE TABLE #tempTable (totalProcessed INT, ...) -- 明确列定义
    

    这样能避免SQL Server自动推断类型带来的存储浪费和类型转换问题。
  • 如果临时表后续还要做查询、关联操作，根据查询条件给临时表加索引；但如果只是一次性填充数据就没用了，别瞎加索引增加写入开销。
  • 数据量小的时候可以试试用表变量@tempTable代替，但数据量大的话还是临时表更靠谱——表变量的统计信息有限，SQL Server可能会生成糟糕的执行计划。

• 原查询里的细节优化
  看你给的示例代码，还有几个可以抠细节的地方：

  • 把CONVERT(date, di.CompletionTime) = '2018-01-31'改成di.CompletionTime >= '2018-01-31' AND di.CompletionTime < '2018-02-01'，这样如果CompletionTime有索引，就能直接利用索引范围扫描，不会因为函数调用导致索引失效。
  • 检查DetailItem.DownloadFileID和DownloadFile.DownLoadID这两个关联列有没有索引，关联操作没索引的话，会做全表扫描或者哈希匹配，开销极大。
  • df.CompanyID = 164这个过滤条件，给DownloadFile.CompanyID加个非聚集索引，能快速过滤出目标公司的数据，减少关联的数据量。

• 用执行计划定位瓶颈
  最后一定要看执行计划！按Ctrl+M打开实际执行计划，看看哪个步骤的开销最高——是全表扫描？还是键查找？还是哈希匹配？针对性优化才是最有效的，比如如果LIKE导致了全表扫描，就优先解决索引的问题。

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