硬编码SQL有时比绑定变量SQL要好

众所周知，SQL提交到数据库引擎后，在执行前要做一系列的工作，包括解析，优化，生成执行计划等，这个过程是比较消耗CPU的计算过程。

相同的SQL提交到引擎后，就可以省略掉执行前的一系列工作，直接选定上次用过的那个执行计划进行查询。所以，绑定变量的SQL就在这个情境下发挥最大的作用了，让多个查询共享一个游标和执行计划，大大提高了效率。


但事情也不完全是这样的，在有些范围查询中，关键查询条件如果是变量的话，那引擎就很难依此作出优化，然后就得出了错误的执行计划，大大影响了效率。



比如有个表， 某个字段值 value 为 1~10000,value字段上有索引， 查询语句为：   select * from table where value>?

当?=9995的时候，结果集只有5条，这个时候采用索引查询的效率会好些。
而当？=100的时候，结果集有9千多，这个时候全表扫描会比索引查询的效率好很多。


但是由于我们用的是绑定变量， 引擎由于不知道value是9995或者是100，因此很难作出正确的执行计划，那么执行效率就看人品了。


这个时候如果采用硬编码的方式，生成的执行计划就能给出最优解。


所以，结论是：  当执行的SQL需要消耗比较长时间，解析，优化，生成执行计划的时间与之比起来可以忽略的时候，那么还是建议用硬编码，这样引擎能够根据查询条件的值进行优化，并给出最优解。而执行时间短，但是次数多的SQL，就需要坚决采用变量绑定。