QUERY EXECUTION

AND OPTIMIZATION

J.Rabera 1
J.Rabera 2
J.Rabera 3
J.Rabera 4
Data Definition Language

J.Rabera 5
Data Manipulation Language

J.Rabera 6
Data Control Language

J.Rabera 7
Cont…

J.Rabera 8
Transaction Control Language

J.Rabera 9
J.Rabera 10
J.Rabera 11
REVIEW OF CREATE, INSERT, &
DELETE

J.Rabera 12
J.Rabera 13
J.Rabera 14
J.Rabera 15
Creating a Schema/Database

J.Rabera 16
CONT….

J.Rabera 17
SQL Script to be Applied on DB

J.Rabera 18
J.Rabera 19
How The Schema Appears

J.Rabera 20
J.Rabera 21
J.Rabera 22
Query to Create Table

J.Rabera 23
Populating The Table

J.Rabera 24
How it Appears on the Schema

J.Rabera 25
Querying from Table Created

J.Rabera 26
Querying Data from Table
Components

J.Rabera 27
J.Rabera 28
J.Rabera 29
Query to Execute Insert

J.Rabera 30
J.Rabera 31
J.Rabera 32
 QUERY OPTIMIZATION
Query Optimization in DBMS is the process of selecting the most efficient way to
execute a SQL statement. Because SQL is a nonprocedural language, the
optimizer can merge, restructure, and process data in any sequence.

Query Optimization in DBMS has a significant application in database designing.

The query optimizer (also known as the optimizer) is database software that
identifies the most efficient way (like by reducing time) for a SQL statement to
access data

There are two types of query optimization in DBMS: Cost-Based Optimization

and Adaptive Query Optimization.

J.Rabera 33
Query Optimization in DBMS

J.Rabera 34
Factors to Consider
• How large is the result set? Should we brace ourselves for a million rows returned,
or just a few?
• Are there any parameters that have limited values? Will a given parameter
always have the same value, or are there other limitations on values that can simplify
our work by eliminating avenues of research.
• How often is the query executed? Something that occurs once a day will be
treated very differently than one that is run every second.
• Are there any invalid or unusual input values that are indicative of an
application problem? Is one input set to NULL, but never should be NULL? Are any
other inputs set to values that make no sense, are contradictory, or otherwise go
against the use-case of the query?
• Are there any obvious logical, syntactical, or optimization problems staring
us in the face? Do we see any immediate performance bombs that will always
perform poorly, regardless of parameter values or other variables?
• What is acceptable query performance? How fast must the query be for its
consumers to be happy? If server performance is poor, how much do we need to
decrease resource consumption for it to be acceptable? Lastly, what is the current
performance of the query? This will provide us with a baseline so we know how much
improvement is needed. J.Rabera 35
Optimizer Components

J.Rabera 36
Query Transformer
• The query transformer determines
whether it is advantageous to
rewrite the original SQL statement
into a semantically equivalent SQL
statement at a lower cost for some
statements.
• When a plausible alternative exists,
the database compares the costs of
each alternative and chooses the
one with the lowest cost. The query
transformer shown in the query
below can be taken as an example of
how query optimization is done by
transforming an OR-based input
query into a UNION ALL-based
output query.
J.Rabera 37
Estimator
• The estimator is the optimizer component that
calculates the total cost of a given execution plan.
• To determine the cost, the estimator employs three
different methods:
• Selectivity: The query picks a percentage of the rows
in the row set, with 0 indicating no rows
and 1 indicating all rows. Selectivity is determined by
a query predicate, such as WHERE the last
name LIKE X%, or by a mix of predicates. As the
selectivity value approaches zero, a predicate gets
more selective, and as the value nears one, it
becomes less selective (or more unselective).
J.Rabera 38
Cont…
• For example, The row set can be a base table, a view,
or the result of a join. The selectivity is tied to a query
predicate, such as last_name = 'Prakash', or a
combination of predicates, such as last_name =
'Prakash' AND job_id = 'SDE'.

J.Rabera 39
Cont…
• Cardinality: The cardinality of an execution plan is the number
of rows returned by each action. This input is shared by all
cost functions and is essential for determining the best
strategy. Cardinality can be calculated using DBMS STATS
table statistics or after taking into account the impact of
predicates (filter, join, and so on), DISTINCT or GROUP BY
operations, and so on. In an execution plan, the Rows column
displays the estimated cardinality.

• For example, if the optimizer estimates that a full table scan

will yield 100 rows, then the cardinality estimate for this
operation is 100. The cardinality estimate appears in the
execution plan's Rows column.
J.Rabera 40
Cont…
• Cost: This metric represents the number of units of
labor or resources used. The query optimizer uses disc
I/O, CPU utilization, and memory usage as units of
effort. For example, if the plan for query A has a lower
cost than the plan for query B, then the following
outcomes are possible: A executes faster than B, A
executes slower than B or A executes in the same
amount of time as B.

J.Rabera 41
Plan Generator
• The plan generator investigates
multiple plans for a query block
by experimenting with various
access paths, join methods, and
join orders.

• Because of the different

combinations that the database
can utilize to generate the
same outcome, many plans are
available. The plan with the
lowest cost is chosen by the
optimizer.
J.Rabera 42
 OPTIMIZATION
TECHNIQUES/METHODS

J.Rabera 43
Cost-Based Query Optimization in DBMS

• The Optimizer allocates a cost in numerical form for each step of

a feasible plan for a given query and environment, and then
discovers these values together to get a cost estimate for the
plan or possible strategy.

• The Optimizer aims to find the plan with the lowest cost estimate
after evaluating the costs of all feasible plans. As a result, the
Optimizer is sometimes known as the Cost-Based Optimizer.

J.Rabera 44
 Execution Plans

• An execution plan specifies the best way to execute a

SQL statement.
• The plan describes the steps taken by a Database to
execute a SQL statement. Each step physically
retrieves or prepares rows of data from the database
for the statement's user.
• An execution plan shows the total cost of the plan,
which is stated on line 0, as well as the cost of each
individual operation. A cost is an internal unit that
appears solely in the execution plan to allow for plan
comparisons. As a result, the cost value cannot be
fine-tuned or adjusted. J.Rabera 45
Query Blocks
• The optimizer receives a parsed representation of a SQL
statement as input. Each SELECT block in the original SQL
statement is internally represented by a query block.
• A query block can be a statement at the top level, a
subquery, or an unmerged view. Let’s take an example
where the SQL statement that follows is made up of two
query sections.
• The inner query block is the subquery in parentheses.
• The remainder of the outer query block of the SQL statement
obtains the names of employees in the departments whose
IDs were supplied by the subquery.
• The query form specifies how query blocks are connected.
J.Rabera 46
J.Rabera 47
Query Sub Plans
• The optimizer creates a query sub-plan for each query
block.
• From the bottom up, the database optimizes query
blocks separately. As a result, the database optimizes
the innermost query block first, generating a sub-plan
for it, before generating the outer query block, which
represents the full query.
• The number of query block plans is proportional to the
number of items in the FROM clause. As the number of
objects rises, this number climbs exponentially. The
possibilities for a join of five tables, for example, are
far higher than those forJ.Rabera
a connection of two tables. 48
Adaptive Query Optimization in
DBMS
• allows the optimizer to make run-time changes to execution plans
and uncover new information that can lead to improved statistics.

• When existing facts are insufficient to produce an ideal strategy,

adaptive optimization comes in handy.

• The optimizer can defer the final plan decision for a statement
with an adaptive plan until execution time.

• The optimizer's ability to alter a plan based on information gained

during execution can significantly increase query performance

J.Rabera 49
HowAdaptive Query Plans
Work
• An adaptive plan is made up of several predefined sub
plans and an optimizer statistics collector.

• A sub-plan is a section of a plan that the optimizer can

use as an alternative during execution. A nested loops
join, for example, might be converted to a hash join
during execution. An optimizer statistics collector is a
row source that is added at crucial points in a plan to
collect run-time statistics. These statistics assist the
optimizer in making a final choice amongst numerous
sub plans.
J.Rabera 50
CONT…
• During statement execution, the statistics collector collects
execution information and buffers some rows received by
the sub-plan.
• The optimizer selects a sub-plan based on the information
collected by the collector. At this point, the collector stops
collecting statistics and buffering rows, and permits rows to
pass through instead.
• On subsequent executions of the child cursor, the optimizer
continues to use the same plan unless the plan ages out of
the cache, or a different optimizer feature (for example,
adaptive cursor sharing or statistics feedback) invalidates
the plan.
J.Rabera 51
ILLUSTRATION

J.Rabera 52