大家好，如果您还对SQL Servere 通过LIKE 在另一个字符串中查找字符串不太了解，没有关系，今天就由本站为大家分享SQL Servere 通过LIKE 在另一个字符串中查找字符串的知识，包括的问题都会给大家分析到，还望可以解决大家的问题，下面我们就开始吧！
为了说明这个问题，首先我们建立一个简单的数据表作为例子：
创建表dbo.String
（
StringId INT NOT NULL 主键IDENTITY(1, 1) ,
字符串VARCHAR(20) NOT NULL
）；
我们使用大小为5M 行的样本数据集来填充String 表，其中String 列只有20 个字符长，StringID 是整数，不为空（NOT NULL），并且主键（PRIMARY KEY）。
我们用它来测试不同查询的性能比较：
不用索引
要查找String 列中以字符序列“abcd”开头的字符串数，我们使用以下查询：
选择计数(1)
来自dbo.String
WHERE 字符串LIKE ‘abcd%’;
查询将在14 秒内执行。
要查找包含“abcd”序列的所有字符串的计数，查询为：
选择计数(1)
来自dbo.String
WHERE 字符串LIKE ‘%abcd%’;
执行时间也是一样的。因为无论哪种情况，SQL Server 都必须执行全表扫描并检查每个字符串是否匹配。
索引优化
加快查询速度的常用技术是为此字段String 创建索引：
创建非聚集索引ix_nc_test ON dbo.String (String);
构建索引后，使用“abcd%”谓词的查询在1 毫秒内执行。第二个查询不会经过索引，因此无法加速。
因为索引是从第一个字符到最后一个字符排序的，而查找匹配字符串的操作与我们之前看到的操作类似。如果LIKE 谓词是’%abcd’ 并且我们想要搜索以’abcd’ 字符结尾的字符串，我们可以使用另一种优化并在该字段上放置反向索引。
然而，如果查询字符可能出现在我们表中字符串的任何位置，那么正向索引和反向索引似乎都无法帮助我们最初的需求（实际上是模糊查询）。
构建临时表
这是一个常见问题。如果我们对字符串的长度有限制，我们可以牺牲存储空间，通过对字符串进行切割，构造一个临时表，将像’abcdefgh’ 这样的字符串构造出八个子字符，连接起来并存储在临时表中以下方式，包含StringID 和分割小节：
abcdefgh
BCDF
cdfg
德格
埃夫格
弗格
GH
小时
完成此操作后，我们可以索引该列并使用尾随通配符执行LIKE 搜索。如果我们正在搜索的字符串出现在该字符串中，这将帮助我们找到它。
当然，这意味着对于长度为3 的字符串，我们在新表中获得3 行。随着字符串长度的增加，存储它所需的行数呈指数增长。例如，存储长度为n 的字符串所需的字符总数（和空间）等于算术数列：n + (n-1) + (n-2) + … + 2 + 1，其值为(n*(n+1))/2。对于长度为100 的字符串，这将变为5050 个字符。对于长度为20 的字符串，必须存储的字符数为210。因此此过程将导致需要更多资源来处理查询。
对于较长的字符串，使用此临时表的查询性能可能无法证明这些资源的开销是合理的。考虑到系统整体吞吐量等其他因素，该技术的应用可以仅限于较短的字段，例如电子邮件、用户名、短文章和类似字符串等。
下面我们在一个StringSplit临时表中测试性能，该临时表填充了String表中字段拆分后的数据，其中字符串按照上述拆分方法进行拆分（每个子字符串的StringId相同）：
创建表dbo.StringsSplit
（
StringId INT NOT NULL,
StringSplit VARCHAR(20) NOT NULL
）；
5M的原始表处理完后，表中的行数为100M。我们在StringSplit 列上创建聚集索引：
创建聚集索引ix_c_test ON dbo.StringSplit (StringSplit);
构建完成后，我们现在可以通过以下查询来查询它：
选择计数（字符串ID）
来自dbo.String
WHERE 字符串LIKE ‘%abcd%’;
选择计数（不同的字符串ID）
FROM dbo.StringSplit
WHERE StringSplit LIKE ‘abcd%’;
第一个查询在14 秒内完成，就像以前一样。第二次查询花费了大约250 毫秒。正如预期的那样，我们使用查询计划来显示这种差异，我们在第一个查询上看到完整索引扫描（因为我们创建的索引在字符串的开头搜索），在第二个查询上看到聚集索引搜索。
原创文章，作者：小su，如若转载，请注明出处：https://www.sudun.com/ask/119307.html
用户评论
那伤。眞美
我最近也在学习用SQL Server查询数据的时候遇到过这个问题！真没想到可以用 `LIKE` 这个操作符来解决，我之前一直都是用字符串比较的方法，这样好像更复杂一点儿。
有8位网友表示赞同！
苍白的笑〃
LIKE 操作符确实是个好工具，以前没怎么用过，现在看来挺万能的。不过有时候匹配太精准会麻烦，不知道有没有什么方法可以设置模糊查询模式？
有7位网友表示赞同！
她最好i
这个SQL Server的 `LIKE` 操作符功能强大啊！我之前一直在用其他数据库管理系统，发现很多功能都是通用的，学习起来更快更容易。分享这种查询技巧真是太实用了！
有12位网友表示赞同！
淡淡の清香
虽然LIKE操作符挺好使的，但是如果字符串比较长的话，性能上可能会有一些影响吧？有没有什么更快速的方法可以替代呢？
有11位网友表示赞同！
夏日倾情
这篇文章写的真好理解，我以前一直以为LIKE只能用于查找字母，原来还可以用来匹配数字啊！太棒了！我现在就来尝试一下看看效果如何。
有20位网友表示赞同！
敬情
LIKE 操作符的用法确实挺多种多样，还有通配符和模式等等，不过感觉有时候操作有点复杂，需要学习更多相关的知识才能熟练掌握。 希望以后再分享一些更深入的文章!
有17位网友表示赞同！
苏莫晨
这个文章的讲解太棒了！像我这种SQL新手也能很快理解。之前经常遇到字符串查找困难，现在学会了LIKE，效率一定会提高很多！
有19位网友表示赞同！
拥菢过后只剰凄凉
其实，有些数据库系统在实现 `LIKE` 操作的时候，是会使用一些更巧妙的算法进行匹配的，因此有时候性能上还是会有差异。这篇博客可以进一步了解下SQL Server的做法。
有17位网友表示赞同！
冷嘲热讽i
LIKE操作符确实好用，但是需要注意它可能会导致性能问题，特别是当数据集很大时。这时候应该考虑使用其他的查询方法或者优化查询语句来提高效率。
有15位网友表示赞同！
逃避
我尝试了一下 `LIKE` 的用法，感觉还不错，特别是在需要进行模糊匹配的时候比较方便。 而且各种通配符的使用也挺有用的，可以根据实际的需求灵活调整匹配规则。
有14位网友表示赞同！
纯真ブ已不复存在
这个博客太棒了！让我学到了很多关于 SQL Server `LIKE` 操作符的新知识。以前我都是用其他函数来进行字符串匹配，这个方法更加简洁高效，感谢你的分享！
有7位网友表示赞同！
哭着哭着就萌了°
我觉得 `LIKE` 操作符在实际项目中应用还是挺广泛的，特别是在需要检索类似或部分匹配数据的时候非常有用。 但是要注意一些细节问题，例如通配符的使用以及性能优化等。
有8位网友表示赞同！
像从了良
这个博客讲得简单明了，轻松就能理解。 以后遇到字符串查找的需求就用 `LIKE` 操作符了，肯定比以前的方法效率更高！
有8位网友表示赞同！
容纳我ii
LIKE 操作符的功能确实很强大，可以用来匹配多个字符类型的数据。 在实际操作中要注意一些特殊字符的使用方式，需要根据不同情况调整匹配规则。
有9位网友表示赞同！
我要变勇敢℅℅
我对 SQL Server 的 `LIKE` 操作符 还是挺熟悉的， 但是这篇文章让我了解到了一些新的使用方法和坑点。 比如在使用通配符的时候需要注意避免无限循环等问题。
有7位网友表示赞同！
执拗旧人
学习了这种查询方法后，我感觉自己SQL语言水平提高了不少！期待看到更多像这种简洁实用的小技巧分享!
有12位网友表示赞同！
裸睡の鱼
这个 SQL Server 的 `LIKE` 操作符确实挺好用的! 我在做数据匹配的时候经常用到它, 以后肯定还会继续学习它的各个用法。
有12位网友表示赞同！