有关SQL Server字符串匹配的探索

本文主要是介绍有关SQL Server字符串匹配的探索，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

1、执行下面代码，结果如何？是否会查出"DB_i"这条数据，若会，通过网络搜索或同学共同探究出原因？

  2、使用其他符号作为转义字符，比如定义"ESCAPE ' # '"或其他符号，看是否也能转义？

查询以"DB_"开头，且倒数第3个字符为 i的课程的详细情况。

      SELECT  *

      FROM   Course

      WHERE  Cname LIKE  'DB\_%i_ _' ESCAPE ' \ '

首先插入数据：

查询以"DB_"开头，且倒数第3个字符为 i的课程的详细情况。

      SELECT  *

      FROM   Course

      WHERE  Cname LIKE  'DB\_%i_ _' ESCAPE ' \ '

执行后得到：

可见会查出"DB_i"这条数据。

进行探究，发现匹配字符串后面无论加多少个"_"都会匹配到这两条数据，并不能做到查询"倒数第3个字符为 i"

甚至在D后面加任意个"_"也能做到

在"数"字后面加任意个"_"也能做到查询所有开头为"数"的数据

经过尝试，加任意个空格和任意个"_"看似都有相同的效果

但是当仅为"数"加任意空格时，则匹配不到，初步猜测是因为没有任何一条数据的Cname为"数"

也就是说，末尾加无数个空格匹配时会按照空格前面的字符去匹配，而末尾加无数个"_"时会进行包含"_"前面字符的整体的模糊匹配

例如此处"数"末尾加无数空格时，相当于会去匹配数据库、数学、数据结构、数据处理在"数"和其它字符中间有没有空格，结果当然是没有，所以什么都没查询到

所以现在依旧可以猜测末尾加任意"_"时能匹配是因为数据库引擎主动在后面加了空格或者类似空格的空字符

在网上查询资料可以得知：

其中有人提到如果匹配时字符串长度不一样会先扩展较短的字符串，我猜测这可能就是最终的原因，至于扩展时用的是空格还是空字符就不重要了。

关于如何查询匹配到倒数第三个字符，我还找到了一些解决方法：

即使用SUBSTRING函数来实现。

该处也提到了这个问题，解释了为什么我们的查询用的是LIKE还是出现了问题，同时还提到了另一个坑

使用其他符号作为转义字符经检验可以成功：

但是使用通配符作为转义字符是不行的。

这篇关于有关SQL Server字符串匹配的探索的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！