Consideration when writing an SQL statement is that it returns a correct result. The second is that it be the most efficient for a given situation. You can use many different SQL statements to achieve the same result. It is often the case that only one statement will be the most efficient choice in a given situation.
Remember that processing SQL is a sequence of Parse (syntax check and object resolution), Execution (required reads and writes), and Fetch (row results retrieved, listed, sorted, and returned). SQL “tuning” consists, quite simply, of reducing one or more of them.
Note: generally Parse is the greatest time and resource hog. Parse overhead can be minimized by the use of Procedures, Functions, Packages, Views, etc.
Following are some general tips that often increase SQL statement efficiency. Being general they may not apply to a particular scenario.
- Tuning SQL should only be done after your code is working correctly. Be aware that there is an inevitable tug-of-war between writing efficient SQL and understandable SQL.
- Ensure repeated SQL statements are written absolutely identicallyto facilitate efficient reuse: re-parsing can often be avoided for each subsequent use of an identical statement.
Writing best practices: all SQL verbs in upper-case i.e. SELECT; separate all words with a single space; all SQL verbs begin on a new line; SQL verbs aligned right or left within the initial verb; set and maintain a table alias standard; use table aliases and when a query involves more than one table prefix all column names with their aliases. Whatever you do, be consistent.
- Use bind variables: The values of bind variables do not need to be the same for two statements to be considered identical. Bind variables are not substituted until a statement has been successfully parsed.
- Use standard approach to table aliases. If two identical SQL statements vary because an identical table has two different aliases, then the SQL is different and will not be re-use or shared.
- Use table aliases and prefix all column names by their aliases when more than one table is involved in a query. This reduces parse time and prevents future syntax errors if someone adds a column to one of the tables with same name as a column in another table. (ORA-00918: COLUMN AMBIGUOUSLY DEFINED)
- Code the query as simply as possible i.e. no unnecessary columns are selected, no unnecessary GROUP BY or ORDER BY.
It is the same or faster to SELECT by actual column name(s). The larger the table the more likely the savings.Use:
SELECT customer_id, last_name, first_name, street, city FROM customer;
SELECT * FROM customer;
- Beware of WHERE clauses which do not use indexes at all. Even if there is an index over a column that is referenced by a WHERE clause included in this section, Oracle will ignore the index. All these WHERE clause can be re-written to use an index while returning the same values. In other words, Do not perform operations on database objects referenced in the WHERE clause:
SELECT client, date, amount FROM sales WHERE amount > 0;
SELECT client, date, amount FROM sales WHERE amount !=0;
SELECT account_name, trans_date, amount FROM transaction WHERE account_name LIKE ‘CAPITAL%’;
SELECT account_name, trans_date, amount FROM transaction WHERE SUBSTR(account_name,1,7)=‘CAPITAL’;
SELECT account_name, trans_date, amount FROM transaction WHERE amount > 0;
SELECT account_name, trans_date, amount FROM transaction WHERE amount NOT=0;
SELECT account_name, trans_date, amount FROM transaction WHERE amount < 2000;
SELECT account_name, trans_date, amount FROM transaction WHERE amount + 3000 < 5000;
SELECT account_name, trans_date, amount FROM transaction WHERE account_name = ‘AMEX’ AND account_type = ‘A’;
SELECT account_name, trans_date, amount FROM transaction WHERE account_name|| account_type=‘AMEXA’;
To be Continued..............
Like the Facebook Page & join Group
For WHATSAPP group , drop a msg to 91-88-00-906098