考虑表testTable，一个包含六个字段的表：其中一个是UNIQUEIDENTIFIER，一个是TIMESTAMP，另外四个是VARCHAR。字段Filename是VARCHAR。
第一次查询需要1分38秒
Select top 1 * from testTable WHERE Filename = 'any.string.1512.b'
这些查询中的任何一个需要1-3秒
Select top 1 * from testTable WHERE Filename = 'any.string.1512'
Select top 1 * from testTable WHERE Filename like 'cusip.realloc.1412.b%'
我已经查看了所有三个的执行计划，唯一的区别是最后一个查询（LIKE语句）使用46％索引查找\ 54％密钥查找与50 \ 50索引\键查找前两个。据我所知，一旦我不再使用此搜索标准的.b部分，查询就会恢复正常速度。
FileName已被编入索引;表已被删除并重新创建以防万一。我们添加了索引，删除索引，检查表，检查数据库，重启服务，重启服务器，重新创建表。此字段曾经是VARCHAR（MAX），我将其更改为VARCHAR（100）以对其进行索引，但问题是在进行此更改之前发生的。
我认为可能发生的其他事情是表格末尾可能有问题。它永远不会完整：
Select * from testTable
我希望这是一张腐败的桌子，但事实并非如此。但是，当我们尝试在SSMS中生成脚本时，它无法生成（没有给出错误）。我能够通过使用另一个SQL客户端并从SSMS生成结构并从其他SQL客户端生成数据来重新创建它。
我们很难过。