是什么让SQL语句变得可思议？

Question

是什么让SQL语句变得可思议？根据定义（至少从我所见过的），sargable意味着查询能够使查询引擎优化查询使用的执行计划。我已经尝试过查找答案，但似乎没有太多关于主题的内容。所以问题是，什么做或不做一个SQL查询sargable？任何文件将不胜感激。供参考：SARGable

Answer 1

使查询不可搜索的最常见的事情是在where子句中的函数内包含一个字段：

SELECT ... FROM ...

WHERE Year(myDate) = 2008

SQL优化器无法在myDate上使用索引，即使存在索引也是如此。它实际上必须为表的每一行评估此函数。使用起来好多了：

WHERE myDate >= '01-01-2008' AND myDate < '01-01-2009'

其他一些例子：

Bad: Select ... WHERE isNull(FullName,'Ed Jones') = 'Ed Jones'

Fixed: Select ... WHERE ((FullName = 'Ed Jones') OR (FullName IS NULL))

Bad: Select ... WHERE SUBSTRING(DealerName,4) = 'Ford'

Fixed: Select ... WHERE DealerName Like 'Ford%'

Bad: Select ... WHERE DateDiff(mm,OrderDate,GetDate()) >= 30

Fixed: Select ... WHERE OrderDate < DateAdd(mm,-30,GetDate()) 

Answer 2

不要这样做：

WHERE Field LIKE '%blah%'

这会导致表/索引扫描，因为LIKE值以通配符开头。

不要这样做：

WHERE FUNCTION(Field) = 'BLAH'

这会导致表/索引扫描。

数据库服务器必须针对表中的每一行计算FUNCTION（），然后将其与“BLAH”进行比较。

如果可能的话，反过来做：

WHERE Field = INVERSE_FUNCTION('BLAH')

这将对参数运行一次INVERSE_FUNCTION（）并仍然允许使用索引。

Answer 3

对于被认为是可攻击的操作，仅仅能够使用现有索引是不够的。在上面的示例中，对where子句中的索引列添加函数调用仍然很可能会利用已定义的索引。它将“扫描”也从该列（索引）中检索所有值，然后消除与提供的过滤器值不匹配的值。对于行数较多的表，它仍然不够高效。真正定义sargability的是使用二进制搜索方法遍历b-tree索引的查询能力，该方法依赖于已排序项目数组的半集消除。在SQL中，它将作为“索引查找”显示在执行计划中。