我的表中有一个具有文本数据类型的字段。
以下两个sql查询的性能是否有所不同：
select * from tablename where fieldname="xyz%"; select * from tablename where fieldname="%zyx";
如果我们要实现这些查询的执行，那么我认为这是我们需要做的：
我们必须匹配两个正则表达式（xyz 和 zyx）。
我们必须从头开始检查字符串chars。
对于第一个查询，我们将必须读取前三个字符以查看是否存在匹配项，但是对于第二个查询，我们将必须读取直至获取字符串的末尾以确定是否已发生匹配。但是，如果我们将字符串的长度存储在某个位置，则可以直接读取后三个字符，从而获得与第一种情况相似的性能。
我的问题是，诸如mysql和oracle之类的商业数据库是否在执行查询方面表现出任何差异。
从您的评论中获取意见：“我只想知道匹配开始与匹配结束之间是否存在差异”。
首先-请记住，我们并不是在寻找匹配字符串的最佳算法。我们正在寻找最佳算法，以找到一组N行中的所有匹配字符串。我们想要做得比“做算法X，N次”更好。
如果未对fieldname进行索引，则两个查询之间的性能差异将很小-SQL引擎将只对字符串的前3个字节或后3个字节进行匹配，这只是偏移到正确的内存位置。
如果对字段名进行索引，则两次搜索之间的性能将存在巨大差异，因为我们可以丢弃大部分数据，而不是检查所有N行。
即对于“ xyz％”版本，我们可以使用二进制搜索。
我们从中间元素开始，恰好是“ peter”。我们可以立即丢弃“ peter”之前的所有内容，并获取其余部分的中间元素-“ samantha”，依此类推，直到找到以“ xyz”开头的条目。
对于“％xyz”版本，我们无法执行此操作，因为任何字符串都可能在末尾匹配，因此我们需要查看每个字符串。
随着表格规模的扩大，这两种方法之间的差异会变得很大。
为字段名反向创建字段/索引的解决方案使我们可以再次使用二进制搜索技术。（在某些数据库中，实际上可以在不创建额外字段的情况下执行此操作，而是通过使用特定的索引类型，虚拟列等）。
这已大大简化-有关数据库索引的实际实现的详细信息，请查看B-Tree和B * Tree索引。
