In my scenario, the following query runs fast (0.5 seconds on a table with 70 million rows):
select * from Purchases where (purchase_id = 1700656396)
and, it even runs fast using bind variables:
var purchase_id number := 1700656396 select * from Purchases where (purchase_id = :purchase_id)
These run fast because I have an index on the
purchase_id column. (Keep reading...)
I need to create a query that allows "filtering" on arbitrary columns. This means providing several input variables, and filtering on each one unless it is
null. This works fine at first.
For example, the following query runs fast (0.5 seconds), too:
select * from Purchases where (1700656396 IS NULL OR purchase_id = 1700656396) and (NULL IS NULL OR purchase_name = NULL) and (NULL IS NULL OR purchase_price = NULL)
But, when I attempt to parameterize the query, either by bind variables or stored procedure, the query slows down dramatically (1.5 minutes), as if it is ignoring any indexes:
var purchase_id number := 1700656396 var purchase_name varchar2 := NULL var purchase_price number := NULL select * from Purchases where (:purchase_id IS NULL OR purchase_id = :purchase_id) and (:purchase_name IS NULL OR purchase_name = :purchase_name) and (:purchase_price IS NULL OR purchase_price = :purchase_price)
Right now, in my application, I am forced to dynamically construct my query at run-time in order to get decent performance. This means I lose all the advantages of parameterized queries, and forces me to worry about SQL injection.
Is it possible to avoid dynamically-constructed queries while still maintaining the same logic?
This is a bigger topic really, but this is the approach that I think is easiest to implement and works well. The trick is to use dynamic SQL, but implement it so that you always pass the same number of parameters (needed), AND you allow Oracle to short-circuit when you don't have a value for a parameter (what you are lacking in your current approach). For example:
set serveroutput on create or replace procedure test_param(p1 in number default null, p2 in varchar2 default null) as l_sql varchar2(4000); l_cur sys_refcursor; l_rec my_table%rowtype; l_ctr number := 0; begin l_sql := 'select * from my_table where 1=1'; if (p1 is not null) then l_sql := l_sql || ' and my_num_col = :p1'; else -- short circuit for optimizer (1=1) l_sql := l_sql || ' and (1=1 or :p1 is null)'; end if; if (p2 is not null) then l_sql := l_sql || ' and name like :p2'; else -- short circuit for optimizer (1=1) l_sql := l_sql || ' and (1=1 or :p2 is null)'; end if; -- show what the SQL query will be dbms_output.put_line(l_sql); -- note always have same param list (using) open l_cur for l_sql using p1,p2; -- could return this cursor (function), or simply print out first 10 rows here for testing loop l_ctr := l_ctr + 1; fetch l_cur into l_rec; exit when l_cur%notfound OR l_ctr > 10; dbms_output.put_line('Name is: ' || l_rec.name || ', Address is: ' || l_rec.address1); end loop; close l_cur; end;
To test, simply run it. For example:
set serveroutput on -- using 0 param exec test_param(); -- using 1 param exec test_param(123456789); -- using 2 params exec test_param(123456789, 'ABC%');
On my system, the table used is over 100mm rows with an index on the number field and name field. Returns almost instantly. Also note that you may not want to do a select * if you don't need all columns, but I'm being a bit lazy and using %rowtype for this example.
Hope that helps