你的思路方向是对的——通过反转列+索引来优化通配符查询，但当前的写法还没完全匹配你的需求，咱们一步步拆解清楚：

先明确当前写法的问题 #

1. 第一个查询：

   SELECT String, StringReversed FROM Tests WHERE String LIKE '%0A7EB%'
   

   这个写法完全用不上索引。因为SQL Server的B树索引是按字符串前缀排序的，前导通配符%会让数据库无法利用IX1索引定位数据，只能执行全表扫描，当数据量较大时（比如你的10万行测试数据），效率会很低。

2. 第二个查询：

   SELECT String, StringReversed FROM Tests WHERE String LIKE '0A7EB%' OR StringReversed LIKE 'BE7A0%'
   

   这个写法能利用IX1和IX2两个索引，但只能匹配两种场景：字符串以0A7EB开头，或者以0A7EB结尾。它并没有覆盖你真正需要的「字符串任意位置包含0A7EB」的情况（比如X0A7EBY这种中间包含子串的数据），所以不符合%0A7EB%的查询需求。

反转列方案的正确适用场景 #

反转列+索引的方案，其实是用来优化后缀通配查询（LIKE '%xxx'）的绝佳方法，比如：

• 原低效查询：SELECT ... WHERE String LIKE '%0A7EB'
• 优化后查询：SELECT ... WHERE StringReversed LIKE 'BE7A0%'

这时候SQL Server可以直接使用IX2索引做前缀匹配，效率和LIKE 'xxx%'一样高，完美解决后缀通配的性能问题。

对于任意位置包含的%xxx%查询，可行的替代优化方案 #

在无法使用全文搜索的生产环境排查阶段，你可以尝试以下几种方法来降低查询开销：

1. 创建覆盖索引减少扫描成本 #

即使必须做扫描，你可以创建一个包含所需返回列的覆盖索引，让SQL Server执行索引全扫描而非表全扫描——索引的体积远小于表，扫描速度会快很多：

CREATE NONCLUSTERED INDEX IX_Tests_String_Covering 
ON dbo.Tests(String) 
INCLUDE (Id, StringReversed) -- 包含你需要查询的所有列

之后执行SELECT String, StringReversed FROM Tests WHERE String LIKE '%0A7EB%'时，数据库会直接扫描这个覆盖索引，避免访问主表。

2. 临时使用内存优化表（如果环境允许） #

如果你的生产环境有足够内存，可以临时将测试数据迁移到内存优化表中。SQL Server对内存优化表的通配符查询有专门的优化，全表扫描的速度会比传统磁盘表快一个数量级，适合排查阶段临时使用。

3. 限制返回结果集（如果业务允许） #

如果你的查询不需要返回所有匹配行，可以加上TOP子句，让SQL Server找到匹配的行后立即停止扫描，比如：

SELECT TOP 100 String, StringReversed FROM Tests WHERE String LIKE '%0A7EB%'

总结 #

你的反转列方案本身是可行的，但仅适用于前缀或后缀匹配的场景。如果需要处理任意位置的包含查询，在无法启用全文搜索的情况下，覆盖索引是最稳妥的临时优化方案，能有效降低查询的IO开销。

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