You have pointed out something that is pretty random in where clauses and is based on a query optimization problem when you use non-parameter predicates. This result can be cause by the following:
1) the query where the where clause is tax_type_code=”004″ may already have been parsed in the query cache or pool and therefore runs much faster because it’s hash value matches the the same query but is different with a ‘015’
2) A scan of the index may return ‘004’ faster because the optimizer more information and has decided to use the index instead of scanning the object itself. Typically, scanning the index is faster depending on the cardinality of the data.
3) The reasons may be as basic as a change in the execution plan.
So the point I’m making is, you will not know the reasons why unless you look at the query execution plan, make sure that the latest statistics are collected on the objects and check for matching hash values in the plan cache/shared pool for that query.
Make sure you alway…
1) Use bind variable/parameterization
2) Make sure your indexes/tables have the latest statistics collected.
3) Check the execution plan to make sure the most optimal plan is being use.
4) Use predicates that have columns in unique and key indexes for normalized tables.