为符合SARG标准，如：将“价格25000”转换为“价格25002”，以达到可以使用索引的目的，但这种转化不是100可靠的，有时会有语义上的损失，有时转化不了。如果对“查询优化器”的工作原理不是特别了解，写出的SQL语句可能不会按照您的本意进行查询。所以不能完全依赖查询优化器的优化，建议大家还是利用自己的优化知识，尽可能显式的书写出符合SARG标准的SQL语句，自行确定查询条件的构建方式，这样一方面有利于查询分析器分析最佳索引匹配顺序，另一方面也有利于今后重读代码。介绍完SARG后，我们再结合一些实际运用中的例子来做进一步的讲解：1、Like语句是否属于SARG取决于使用通配符的样式如：
amelike‘张’，这就属于SARG而：
amelike‘张’就不属于SARG通配符在字符串首字符的使用会导致索引无法使用，虽然实际应用中很难避免这样用，但还是应该对这种现象有所了解，至少知道此种用法性能是很低下的。2、“非”操作符不满足SARG形式，使得索引无法使用不满足SARG形式的语句最典型的情况就是包括非操作符的语句，NOT、如：、、、、NOTEXISTS、NOTIN、NOTLIKE等。下面是一个NOT子句的例子：where
otstatusvalid
ot运算符也隐式的包含在另外一些逻辑运算符中，比如运算符。见下例：wherestatusi
valid
再看下面这个例子：selectfromemployeewheresalary3000
f对这个查询，可以改写为不使用
ot：selectfromemployeewheresalary3000orsalary3000
虽然这两种查询的结果一样，但是第二种查询方案会比第一种查询方案更快些。第二种查询允许对salary列使用索引，而第一种查询则不能使用索引。
3、函数运算不满足SARG形式，使得索引无法使用例：下列SQL条件语句中的列都建有恰当的索引，但执行速度却非常慢：selectfromrecordwheresubstri
gcard_
o14′5378′13秒selectfromrecordwhereamou
t301000（11秒）selectfromrecordwhereco
vertchar10date112′19991201′（10秒）分析：where子句中对列的任何操作结果都是在SQL运行时逐列计算得到的，因此它不得不进行全表扫描，而没有使用该列上面的索引；如果这些结果在查询编译时就能得到，那么就可以被SQL优化器优化，使用索引，避免表搜索，因此将SQL重写成下面这样：selectfromrecordwherecard_
olike′5378′（1秒）selectfromrecordwhereamou
t100030（1秒）selectfromrecordwheredate′19991201′（1秒）
你会发现SQL明显快很多
4、尽量不要对建立了索引的字段，作任何的直接处理selectfromemployswherefirst_r