众所周知,SQL提交到数据库引擎后,在执行前要做一系列的工作,包括解析,优化,生成执行计划等,这个过程是比较消耗CPU的计算过程。
相同的SQL提交到引擎后,就可以省略掉执行前的一系列工作,直接选定上次用过的那个执行计划进行查询。所以,绑定变量的SQL就在这个情境下发挥最大的作用了,让多个查询共享一个游标和执行计划,大大提高了效率。
但事情也不完全是这样的,在有些范围查询中,关键查询条件如果是变量的话,那引擎就很难依此作出优化,然后就得出了错误的执行计划,大大影响了效率。
比如有个表, 某个字段值 value 为 1~10000,value字段上有索引, 查询语句为: select * from table where value>?
当?=9995的时候,结果集只有5条,这个时候采用索引查询的效率会好些。
而当?=100的时候,结果集有9千多,这个时候全表扫描会比索引查询的效率好很多。
但是由于我们用的是绑定变量, 引擎由于不知道value是9995或者是100,因此很难作出正确的执行计划,那么执行效率就看人品了。
这个时候如果采用硬编码的方式,生成的执行计划就能给出最优解。
所以,结论是: 当执行的SQL需要消耗比较长时间,解析,优化,生成执行计划的时间与之比起来可以忽略的时候,那么还是建议用硬编码,这样引擎能够根据查询条件的值进行优化,并给出最优解。而执行时间短,但是次数多的SQL,就需要坚决采用变量绑定。
相同的SQL提交到引擎后,就可以省略掉执行前的一系列工作,直接选定上次用过的那个执行计划进行查询。所以,绑定变量的SQL就在这个情境下发挥最大的作用了,让多个查询共享一个游标和执行计划,大大提高了效率。
但事情也不完全是这样的,在有些范围查询中,关键查询条件如果是变量的话,那引擎就很难依此作出优化,然后就得出了错误的执行计划,大大影响了效率。
比如有个表, 某个字段值 value 为 1~10000,value字段上有索引, 查询语句为: select * from table where value>?
当?=9995的时候,结果集只有5条,这个时候采用索引查询的效率会好些。
而当?=100的时候,结果集有9千多,这个时候全表扫描会比索引查询的效率好很多。
但是由于我们用的是绑定变量, 引擎由于不知道value是9995或者是100,因此很难作出正确的执行计划,那么执行效率就看人品了。
这个时候如果采用硬编码的方式,生成的执行计划就能给出最优解。
所以,结论是: 当执行的SQL需要消耗比较长时间,解析,优化,生成执行计划的时间与之比起来可以忽略的时候,那么还是建议用硬编码,这样引擎能够根据查询条件的值进行优化,并给出最优解。而执行时间短,但是次数多的SQL,就需要坚决采用变量绑定。