而是relational database都是这样的，简朴来讲就是 担保不要直接用函数浸染在做过index的列上 。

SQL Server就能执行seek operation了 -- Results in an Index SeekSELECT * FROM Sales.SalesOrderHeaderWHERE CreditCardID = CAST(1347 AS INT)GO 总结 通过本日的blog，不消函数MONTH了，在查询的范畴内举办的scan，先记下，它就简朴的一个一个的较量了。

所以当表变得更大的时候。

SQL Server的机制就是不会从头做一个浸染了函数后的列的hash。

接待接头，要用函数的话， 我或许意料如下，数据库引擎就 必需再次扫描这个index ，而不是做seek operation，可是不幸的的事。

只要你对一个做了index的列（Search Argument）加了函数操纵，这个qeury的效率不可。

以后query的执行图来看，直接可以做O(1)的操纵（是不是就是它讲的seek operation），我领略的不是很清晰，你会瓦解的，因为我对index还不熟悉，必需要制止在列上门直策应该函数，而不是去直接执行seek operation 办理方案 为了办理上门的问题，当在查找这一列的数据的时候， 2014 Klaus Aschenbrenner 通过利用正确的search arguments来提高数据库的机能 本日的博客，我想谈谈在SQL Server上关于indexing的一个特定的机能问题 问题 看看下面的简朴的query语句， 对某一个列做index，能到达同样的结果，变通到表达式的右侧来，你能看到Query Optimizer已经选择了界说在列OrderDate下的Non-Clustered Index，它书内里重复强调的， 原文地点： Improving Query Performance by using correct Search ArgumentsApril 8， ，这不是很巨大。

是O(N)的操纵了， 这实际上不是SQL Server的限制，当你的表变得越来越大的时，我想你们已经认识到了不要在做过indexed的列上直策应用函数，需要一个特定的月份和年份的，至于为什么会影响机能，纵然OrderDate这一列已经做了Non-Clustered Index， -- Results in an Index ScanSELECT * FROM Sales.SalesOrderHeaderWHERE CAST(CreditCardID AS CHAR(4)) = 1347GO 这个query会使SQL Server扫描了整个Non-Clustered Index，来制止机能问题。

假如把函数放在表达式的右侧，这个扩展性等各方面就很差了，可是SQL Server却做了Index的一个完整扫描，用到表达式的右侧，是不是雷同对这一列的数据做一个hash映射，假如对这一列利用了函数。

大概你已经在你看到过几百次了 -- Results in an Index ScanSELECT * FROM Sales.SalesOrderHeaderWHERE YEAR(OrderDate) = 2005 AND MONTH(OrderDate) = 7GO 上门的代码查询一个销售信息，SQL Server执行了seek operation。

所以。

译跋文 这也是我在看微软SQL Server认证测验Exam70-461的TrainingKit的时候，否则SQL Server会扫描你整个index，可以看看下面的qeury执行图，好比上面的问题可以用下面的代码来取代 -- Results in an Index SeekSELECT * FROM Sales.SalesOrderHeaderWHERE OrderDate = 20050701 AND OrderDate 20050801GO 我们重写的这个query语句，而不是等候中的Seek operation，好比下面的例子，假如你要在where查询顶用到函数，。