Question

我正在使用sql server并且有一个2列的表
myId varchar(80)
cchunk varchar(max)

基本上它存储了大量文本，这就是我需要它的原因varchar(max)。我的问题是当我做这样的查询时：

select *
from tbchunks
where
  (CHARINDEX('mystring1',tbchunks.cchunk)< CHARINDEX('mystring2',tbchunks.cchunk))
AND
  CHARINDEX('mystring2',tbchunks.cchunk) - CHARINDEX('mystring1',tbchunks.cchunk) <=10

完成大约需要3秒钟，表格块大约只有500,000条记录，上述查询返回的数据最多为0到800之间

我在myid列上有非聚集索引，它有助于快速选择计数（*），但对上述查询没有帮助。

我尝试使用全文但速度很慢。我尝试将cchunk中的文本拆分成更小的部分并添加一个id列，它将连接所有这些分裂的块，但最终得到一个包含200万条文本分割块的记录表（我这样做，所以我可以添加索引）但仍然查询甚至更慢。

修改修改了表以包含主键（int）用“Accent Senstive = true”创建了fultext目录在我的tabe上创建全文索引“cchunk”列运行相同的上述查询，它最终花了22秒，慢得多

更新谢谢大家建议FullText（@Aaron Bertrand谢谢！），我将查询转换为此

SELECT * FROM tbchunksAS FT_TBL INNER JOIN CONTAINSTABLE（tbchunks，cchunk，'（mystring1 NEAR mystring2）'）AS KEY_TBL ON FT_TBL.cID = KEY_TBL。[KEY]

顺便说一句，cID是我后来添加的主键。无论如何，我得到了borad结果，我注意到返回的RANK列越高，结果越好。我的问题是RANK何时开始准确？

Answer 1

索引根本无法帮助CHARINDEX。特定列的索引只能快速查找索引字段中的值恰好是索引值的行。实际上我很惊讶查询只需要3秒钟，因为它必须读取每一行四次（或至少两次）。

Answer 2

这里提出的想法很好，没有任何机构可以真正解决我的问题，而是提供有用的提示，引导我找到我想要分享的解决方案。

使用全文确实是许多人提到的答案，但我设法将Contains与Near结合使用，因此它可以完全取代我当前的sql查询并提供极快的速度。

CONTAINS（tbchunks，'NEAR（（mystring1，mystring2），3，TRUE）'）

使用CHARINDEX，SQL Select非常慢

2 个答案: