The Basics of Efficient SQL Written for myself –Writing doesnt make you rich Proof of what works...

The Basics of Efficient SQLThe Basics of Efficient SQL

• Written for myself– Writing doesn’t make you rich

• Proof of what works– and what doesn’t

• Three parts:– Data Model Tuning

– SQL Code TuningSQL Code Tuning– Phys. / Config. Tuning

• Written for myself– Writing doesn’t make you rich

• Proof of what works– and what doesn’t

• Three parts:– Data Model Tuning

– SQL Code TuningSQL Code Tuning– Phys. / Config. Tuning

The Basics of Efficient SQLThe Basics of Efficient SQL

• SQL Code TuningSQL Code Tuning– What is SQL?– The Basics of Efficient SQLThe Basics of Efficient SQL– Common Sense Indexing– The Optimizer: Making SQL Efficient– Finding Problem Queries– Oracle Enterprise Manager

• SQL Code TuningSQL Code Tuning– What is SQL?– The Basics of Efficient SQLThe Basics of Efficient SQL– Common Sense Indexing– The Optimizer: Making SQL Efficient– Finding Problem Queries– Oracle Enterprise Manager

Some General GuidelinesSome General Guidelines

• ““KISS” KISS” (Keep It Simple Stupid)(Keep It Simple Stupid)– easier for the Optimizer

• depends on query complexity

– easier for you to tune

• Don’t go too far with granularityDon’t go too far with granularity– connecting and disconnecting for all queries

• ““KISS” KISS” (Keep It Simple Stupid)(Keep It Simple Stupid)– easier for the Optimizer



• Don’t go too far with granularityDon’t go too far with granularity– connecting and disconnecting for all queries

• “KISS”– easier for the Optimizer



• Don’t go too far with granularity– connecting and disconnecting for all queriesconnecting and disconnecting for all queries

• “KISS”– easier for the Optimizer



• Don’t go too far with granularity– connecting and disconnecting for all queriesconnecting and disconnecting for all queries

Watch GranularityWatch Granularity

• Is intelligent– better with simple queries

• Is usually correct

• Nothing is set in stone• Verify SQL code efficiency

– use EXPLAIN PLANEXPLAIN PLAN– SET AUTOTRACE ON EXPLAINSET AUTOTRACE ON EXPLAIN– $ORACLE_HOME/rdbms/admin/utlxplan.sql$ORACLE_HOME/rdbms/admin/utlxplan.sql

• Is intelligent– better with simple queries

• Is usually correct

• Nothing is set in stone• Verify SQL code efficiency

– use EXPLAIN PLANEXPLAIN PLAN– SET AUTOTRACE ON EXPLAINSET AUTOTRACE ON EXPLAIN– $ORACLE_HOME/rdbms/admin/utlxplan.sql$ORACLE_HOME/rdbms/admin/utlxplan.sql

The OptimizerThe Optimizer

Basic Query ComponentsBasic Query Components

• SELECTSELECT– get dataget data

• WHERE– filtering

• ORDER BY– sorting

• GROUP BY– aggregating

• SELECTSELECT– get dataget data





• SELECT– get data

• WHEREWHERE– filteringfiltering




• WHEREWHERE– filteringfiltering






• ORDER BYORDER BY– sortingsorting




• ORDER BYORDER BY– sortingsorting






• GROUP BYGROUP BY– aggregatingaggregating




• GROUP BYGROUP BY– aggregatingaggregating

• SELECTSELECT– FOR UPDATEFOR UPDATE

• Filtering– WHERE

• ORDER BY– often ignored– query complexity

• GROUP BY

• SELECTSELECT– FOR UPDATEFOR UPDATE



• GROUP BY

QueriesQueries

SELECT ** FROM division;

SELECT division_id, name, city, state, country FROM division;

SELECT division_id FROM division;

• SELECT– FOR UPDATE

• Filtering– WHEREWHERE


• GROUP BY


• Filtering– WHEREWHERE


• GROUP BY

QueriesQueries

Avoid unintentional full table scansSELECT * FROM division WHERE country LIKE '%a%';

Match indexes

Exact hits (equality)SELECT * FROM division WHERE division_id = 1;

Range scans / skip scans / full index scans

EXISTS (correlate) faster than IN

Biggest filters first

Full table scans can sometimes be faster

Avoid unintentional full table scansSELECT * FROM division WHERE country LIKE '%a%';

Match indexes

Exact hits (equality)SELECT * FROM division WHERE division_id = 1;

Range scans / skip scans / full index scans

EXISTS (correlate) faster than IN

Biggest filters first

Full table scans can sometimes be faster

QueriesQueriesResorts on result after WHERE and GROUP BY

Don’t repeat sorting (ORDER BY often ignored)

by SELECT

SELECT division_id FROM division ORDER BY division_id;

by WHERE

SELECT * FROM division WHERE division_id < 10 ORDER BY division_id;

GROUP BY

SELECT state, COUNT(state) FROM division GROUP BY state ORDER BY state;

by DISTINCT

SELECT DISTINCT(state) FROM division ORDER BY state;

by indexes


Resorts on result after WHERE and GROUP BY


by SELECT


by WHERE


GROUP BY


by DISTINCT


by indexes




• ORDER BYORDER BY– often ignored– query complexity

• GROUP BY




• GROUP BY




• GROUP BY




• GROUP BY

QueriesQueriesResorts on result after WHERE and GROUP BY


by SELECT


by WHERE


GROUP BY


by DISTINCT


by indexes


Resorts on result after WHERE and GROUP BY


by SELECT


by WHERE


GROUP BY


by DISTINCT


by indexes


QueriesQueries

GROUP BY


HAVING (filters aggregate)

SELECT state, COUNT(state) FROM division GROUP BY state HAVING COUNT(state) > 1;

use WHERE

SELECT state, COUNT(state) FROM division WHERE state = 'NY' GROUP BY state;

not HAVING

SELECT state, COUNT(state) FROM division GROUP BY state HAVING state = 'NY';

GROUP BY




use WHERE


not HAVING





• GROUP BYGROUP BY– Use WHERE not HAVINGUse WHERE not HAVING













QueriesQueries

GROUP BY




use WHERE


not HAVING


GROUP BY




use WHERE


not HAVING


• FunctionsFunctions– conversions– avoid indexes

– function based indexing

– DECODE– CASE expressions– set operators (UNION)

• Use sequencesUse sequences• Use equality (=) or range scans (>)Use equality (=) or range scans (>)

– Avoid negatives (!=, NOT)– Avoid LIKE

• FunctionsFunctions– conversions– avoid indexes

– function based indexing

– DECODE– CASE expressions– set operators (UNION)

• Use sequencesUse sequences• Use equality (=) or range scans (>)Use equality (=) or range scans (>)

– Avoid negatives (!=, NOT)– Avoid LIKE

Other StuffOther Stuff

Other StuffOther Stuff

• JoinsJoins– avoid Cartesian Products– avoid anti joins– avoid outer joins– perhaps replace

– multiple table complex joins– with subquery semi joins and inline views

• Be careful with viewsBe careful with views

• JoinsJoins– avoid Cartesian Products– avoid anti joins– avoid outer joins– perhaps replace

– multiple table complex joins– with subquery semi joins and inline views

• Be careful with viewsBe careful with views

The Basics of Efficient SQL Written for myself –Writing doesnt make you rich Proof of what works...

Documents

Transcript of The Basics of Efficient SQL Written for myself –Writing doesnt make you rich Proof of what works...