SQLParity

Query optimizer

9 checks for the patterns that make a query scan more than it needs to.

1

Your query

2

What it found

5 findings, 2 costly

  • SELECT * reads every column

    Costly

    Columnar stores like Snowflake, BigQuery, Redshift and Athena bill by bytes scanned, and reading a column you discard costs exactly as much as reading one you use. On a wide table this is usually the single largest avoidable cost in a query.

    Do this instead: Name the columns you actually need. If you are exploring, add a LIMIT so the scan stays small.

  • A function wraps the column being filtered

    Costly

    Once a column is inside a function the engine can no longer match it against an index or prune partitions by it, so a filter that looks narrow reads everything. This is the usual reason a date filter still scans the whole table.

    Do this instead: Rewrite the predicate so the bare column is on one side — compare against a computed range instead of transforming the column.

  • LIKE pattern starts with a wildcard

    Worth fixing

    A pattern beginning with % cannot use an index or a column's min/max statistics, so the engine has to read and test every row.

    Do this instead: Anchor the pattern if you can (LIKE 'abc%'). For genuine substring search, a full-text or search index is the right tool.

  • Tables joined with a comma

    Worth fixing

    Comma joins produce a cross product unless every pair is constrained in the WHERE clause. One forgotten predicate multiplies the row count instead of raising an error.

    Do this instead: Use explicit JOIN ... ON. The join condition then sits next to the join it belongs to, and a missing one is visible.

  • ORDER BY without a LIMIT

    Worth fixing

    Sorting is one of the few operations that cannot stream — the engine materialises and orders the entire result before returning the first row. Without a LIMIT you pay that for rows you may never read.

    Do this instead: Add a LIMIT if you only need the top rows. If the ordering is for a downstream consumer, consider sorting there instead.

These are patterns in the text, not a cost estimate. Without your table sizes, partitions and indexes — none of which leave your machine — nothing here can tell you which of two queries is faster. Check the plan in your engine for that.