05. bad constructs in sql

  1. NULLs and the NOT IN predicate
  2. Functions on indexed columns in predicates
  3. Incorrect subquery column
  4. Data type mismatch in predicates
  5. Predicate evaluation order
  6. Outer joins and placement of predicates
  7. Subqueries that return more than one value
  8. Use of SELECT *
  9. Scalar user-defined functions

  10. Overuse of cursors

  11. don’t rbar (use cursors only for well defined scenario’s )

  12. don’ use functions in select list
  13. get the least possible amount of data
    - limit colums ; no select * (not always bad)
    - limit rows

  14. make sure sql server can correctly estimate # of rows
    - select * from tabA join tabB on ID where ID in ( id’s…)
    => 1 row : row lookup > => 13000 ID => run away query plan

    • join table var = always estimated 1 or 100 (since sql 2014 ?)
    • correct statistics

  15. negative search (select * from .... where colX <> 3 )

  16. not using partioning by/over when possible (running totals)

  17. more then 6 joins ( used to be 4)

  18. joining tables with views (but NOT always) (indexed views can help , but NOT always)

  19. nested views

avoid writing a SQL query using multiple joins that includes outer joins, cross apply, outer apply and other complex sub queries. It reduces the choices for Optimizer to decide the join order and join type. Sometime, Optimizer is forced to use nested loop joins, irrespective of the performance consequences for queries with excessively complex cross apply or sub queries.

wm : vaak perfomance verhoogd door queries in meerdere simpelder op te splitsen

move non-correlated scalar sub query as a separate query instead of part of the main query and store the output in a variable, which can be referred to in the main query or later part of the batch. This will give better options to Optimizer, which may help to return accurate cardinality estimates along with a better plan.

Avoid Multi-statement Table Valued Functions (TVFs)
Multi-statement TVFs are more costly than inline TFVs. SQL Server expands inline TFVs into the main query like it expands views but evaluates multi-statement TVFs in a separate context from the main query and materializes the results of multi-statement into temporary work tables. The separate context and work table make multi-statement TVFs costly.

Order or position of a column in an index plays a vital role to improve SQL query performance. An index can help to improve the SQL query performance if the criteria of the query matches the columns that are left most in the index key. As a best practice, most selective columns should be placed leftmost in the key of a non-clustered index.

revisit your schema definitions; keep on eye out that appropriate FORIGEN KEY, NOT NULL and CEHCK constraints are in place or not. Availability of the right constraint on the right place always helps to improve the query performance, like FORIGEN KEY constraint helps to simplify joins by converting some outer or semi-joins to inner joins and CHECK constraint also helps a bit by removing unnecessary or redundant predicates.