Sql Server 字符串比较答案

【问题标题】：Sql Server String ComparisionSql Server 字符串比较
【发布时间】：2009-04-21 18:59:51
【问题描述】：

是否有任何关于 SQL Server 如何比较字符串并在其中处理搜索的信息（如语句）？我试图找出是否有一种方法可以确定将信息存储为大字符串并使用 sql server 对行进行一堆比较以确定哪个匹配项的效率。我知道这可能会很慢（每个信息字符串的长度为 2400 个字符），但我需要一些文件来说明字符串的比较方式，以便我可以展示它的效率（或低效率）。

【问题讨论】：

1.您是否计划建立全文索引？ 2.你有没有对这种解决方案进行过任何时间试验？ 3. 你将使用什么样的数据？通常我们避免使用 LIKE 语句。这个帖子似乎表明动态sql可能比全文索引更好：social.msdn.microsoft.com/forums/en-US/sqldatabaseengine/thread/…
like 有什么问题？ WHERE LastName like 'Smi%' 是 sargable 而 WHERE LEFT(LastName ,3) = 'Smi' 不是....当您搜索列的开头时，like 绝对没有问题
因为我很确定 like 语句在字段中间搜索 400 个字符长的字符串时效果不佳。

标签： sql-server string algorithm comparison sql-like

【解决方案1】：

每条信息的长度为 2400 个字符

正好是 2400？所以你那里有固定宽度的字段？节省您的时间，只需将其拆分为单独的列。以后你会感谢自己的。

如果您必须有数据，请设置一个测试数据库并尝试两种方式。那么至少你会有特定于你的系统的数据。

【讨论】：

由于数据的性质，我不能这样做。我考虑过这种方法，但它会迫使我做一堆连接来确定数据的整体价值。 2400 本质上是一大组标志，我们需要搜索这些标志才能连续找到一系列设置标志。我真正要寻找的是说明这样做效率很低的信息。
我认为（知道！）您会发现在插入时拆分字符串比在搜索或检索时拆分要快得多。数据库设计的基本规则：1 列，1 值。
这就是交易。 dba 希望每个字符代表 1 分钟的时间。我必须搜索以确定可用时间跨度有多长。拆分它意味着我必须做大量的工作来确定哪些值在哪里排列，以确定时间跨度有多长。我不是说你错了，但我需要足够的信息来说明为什么这是个坏主意。我想到了其他数据结构来解决这个问题，但我需要先反驳他的想法，然后才能提出我自己的想法。
然后让您的 dba 为您编写搜索代码。 DBA 通常最终会得到他们想要的东西，无论好坏，最好现在就为此做好准备。要么告诉他你不够聪明，需要他的专家帮助，要么你认为他做不到——这取决于他的个性和人际关系；）

【解决方案2】：

在它们中搜索会很慢，因为您将无法创建索引，因为索引的长/宽不能超过 900 字节

我会按照 Joel Coehoorn 的建议去做，并将其分成几列

您可能还想将其拆分为更多表，因为您只能存储 3 行 pr 页面，每行 2400 个字符

【讨论】：

【解决方案3】：

您可以将全文搜索索引应用于 sql server，这些索引通常用于搜索引擎之类的东西。全文索引通常允许布尔逻辑运算符用于搜索。

【讨论】：

我个人不知道有人使用 SQL Server 全文索引作为搜索引擎后端。你知道任何例子吗？我知道的大多数实现都使用 Lucene 或自定义代码来实现文本搜索。

【解决方案4】：

只是已经提到的附加信息。如果您需要使用like 过滤大字符串，也不会使用索引（通配符 % 仅位于搜索字符串的末尾）。所以最好避免点赞，让需要过滤的部分在自己的字段中可用。

【讨论】：

【解决方案5】：

在关于全文搜索的 MSDN 文章中，提到了 LIKE 谓词如何使用字符模式。

将 LIKE 与全文搜索进行比较

与全文搜索相比，LIKE Transact-SQL 谓词有效仅在字符模式上。此外，您不能使用 LIKE 谓词查询格式化的二进制数据。此外，针对一个大型的 LIKE 查询非结构化文本数据的数量比等价的要慢得多针对相同数据的全文查询。针对数百万的 LIKE 查询多行文本数据可能需要几分钟才能返回；而全文针对相同的数据，查询可能只需要几秒钟或更短的时间，具体取决于返回的行数。

【讨论】：