Is there a performance penalty between these 2 statements:

select * from table1
where (@param1 is null or col1 = @param1)
    and (@param2 is null or col2 = @param2)

select * from table1
where (@param1 is null or col1 like @param1)
    and (@param2 is null or col2 like @param2)

This would allow the user to key in e.g. SMIT% to search for a customer name starting with SMIT, but if he keys in SMITH, then only the exact name would appear in the result list.

Is this good practice, or should I avoid?

Thanks for this great article!

Shouldn’t this:

select * from table1
where (col1 is null or col1 = @param1)
    and (col2 is null or col2 = @param2)

read:

select * from table1
where (@param1 is null or col1 = @param1)
    and (@param2 is null or col2 = @param2)

? Cheers, Will

One, COALESCE() (or similar but not identical functions such as ISNULL() or IFNULL(), which I’ve seen used as well) still results in a potentially large value being compared, which might be optimized out with IS NULL. It’s also a function call, which has overhead.

Two, because it’s a function call it won’t be optimized out in the optimizer phase, if applicable. When using an interface which sends the commands in plain text, the optimizer can completely remove parts of the query, as I mentioned above in MySQL. If you have any inclination to see that in action, it’s kind of fun to do.

Theoretically, an optimizer could detect the query will be col1 = COALESCE(NULL, col1) and know that can be rewritten as col1 = col1, which can be optimized out altogether, but in practice, that’s a heck of a lot smarter and harder-to-write optimizer than I’d expect to find. I only have access to MySQL 5.x right now, but I expect other optimizers are no smarter than this:

mysql> explain extended select col1 from tbl1 where col1 = coalesce(@param1, col1)G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: col1
         type: index
possible_keys: NULL
          key: PRIMARY
      key_len: 4
          ref: NULL
         rows: 397
        Extra: Using where; Using index
1 row in set, 1 warning (0.00 sec)

mysql> show warningsG
*************************** 1. row ***************************
  Level: Note
   Code: 1003
Message: select sql_no_cache `test`.`tbl1`.`col1` AS `col1` from `test`.`tbl1` where (`test`.`tbl1`.`col1` = coalesce((@param1),`test`.`tbl1`.`col1`))
1 row in set (0.01 sec)

mysql> explain extended select col1 from tbl1 where col1 = coalesce(null, col1)G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: tbl1
         type: index
possible_keys: NULL
          key: PRIMARY
      key_len: 4
          ref: NULL
         rows: 397
        Extra: Using where; Using index
1 row in set, 1 warning (0.00 sec)

mysql> show warningsG
*************************** 1. row ***************************
  Level: Note
   Code: 1003
Message: select `test`.`tbl1`.`col1` AS `col1` from `test`.`tbl1` where (`test`.`tbl1`.`col1` = coalesce(NULL,`test`.`tbl1`.`col1`))
1 row in set (0.00 sec)

In that query @param1 is undefined, and you can see it results in the same query plan as using NULL. MySQL does consider the current value of variables when generating an optimized query plan, as you can see here:

mysql> explain extended select col1 from tbl1 where col1 = @param1G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: NULL
         type: NULL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: NULL
        Extra: Impossible WHERE noticed after reading const tables

The function call is defeating the optimization. To optimize that out, the optimizer would have to know the behavior of every function, which isn’t its job. In general, function calls can defeat a lot of optimizations.

On the other hand, as I said before:

mysql> explain extended select col1 from tbl1 where (@param1 is null or col1 = @param1)G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: tbl1
         type: index
possible_keys: NULL
          key: PRIMARY
      key_len: 4
          ref: NULL
         rows: 397
        Extra: Using index
1 row in set, 1 warning (0.00 sec)

mysql> show warningsG
*************************** 1. row ***************************
  Level: Note
   Code: 1003
Message: select sql_no_cache `test`.`tbl1`.`col1` AS `col1` from `test`.`tbl1`
1 row in set (0.00 sec)

The optimizer removed the WHERE clause completely.

Stored procedures, and other situations where a query plan might be cached and re-used later, are always a factor to consider. In Microsoft SQL Server, for example, the first time a stored procedure is executed its query plan is cached for re-use (mostly… this can be defeated intentionally or with bad practices), which avoids the costs associated with generating a query plan. That can be a fairly significant optimization, as generating a query plan involves looking at index statistics, etc etc. But it also means whatever parameter is supplied for the first invocation of the stored procedure influences the cached query plan, so the query might be well-optimized for @param1 but not at all for @param2 — and it won’t get re-evaluated for @param2.

SELECT * FROM table1
WHERE col1= COALESCE(@param1,col1)
AND col2 = COALESCE(@param2,col2)

COALESCE returns the first non-null value in the list, so if @param1 is supplied, col1 is compared to it. If not, col1 is compared to *itself* which always matches. The resulting behavior is that if a parameter is supplied, your code filters by it, otherwise it returns all rows.