103 lines
6.5 KiB
HTML
103 lines
6.5 KiB
HTML
|
<?xml version="1.0" encoding="UTF-8"?>
|
||
|
|
<!DOCTYPE html
|
||
|
|
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||
|
|
<html lang="en-us" xml:lang="en-us">
|
||
|
|
<head>
|
||
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||
|
|
<meta name="security" content="public" />
|
||
|
|
<meta name="Robots" content="index,follow" />
|
||
|
|
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
||
|
|
<meta name="DC.Type" content="reference" />
|
||
|
|
<meta name="DC.Title" content="Single table optimization" />
|
||
|
|
<meta name="abstract" content="At run time, the optimizer chooses an optimal access method for the query by calculating an implementation cost based on the current state of the database. The optimizer uses 2 costs when making decisions: an I/O cost and a CPU cost. The goal of the optimizer is to minimize both I/O and CPU cost." />
|
||
|
|
<meta name="description" content="At run time, the optimizer chooses an optimal access method for the query by calculating an implementation cost based on the current state of the database. The optimizer uses 2 costs when making decisions: an I/O cost and a CPU cost. The goal of the optimizer is to minimize both I/O and CPU cost." />
|
||
|
|
<meta name="DC.subject" content="query optimizer, decision-making rules" />
|
||
|
|
<meta name="keywords" content="query optimizer, decision-making rules" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="per0001.htm" />
|
||
|
|
<meta name="copyright" content="(C) Copyright IBM Corporation 1998, 2006" />
|
||
|
|
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 1998, 2006" />
|
||
|
|
<meta name="DC.Format" content="XHTML" />
|
||
|
|
<meta name="DC.Identifier" content="decmakrules" />
|
||
|
|
<meta name="DC.Language" content="en-us" />
|
||
|
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
||
|
|
<!-- US Government Users Restricted Rights -->
|
||
|
|
<!-- Use, duplication or disclosure restricted by -->
|
||
|
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
||
|
|
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
|
||
|
|
<link rel="stylesheet" type="text/css" href="./ic.css" />
|
||
|
|
<title>Single table optimization</title>
|
||
|
|
</head>
|
||
|
|
<body id="decmakrules"><a name="decmakrules"><!-- --></a>
|
||
|
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
|
|
<h1 class="topictitle1">Single table optimization</h1>
|
||
|
|
<div><p>At run time, the optimizer chooses an optimal access method for
|
||
|
|
the query by calculating an<em> implementation cost</em> based on the current
|
||
|
|
state of the database. The optimizer uses 2 costs when making decisions:
|
||
|
|
an I/O cost and a CPU cost. The goal of the optimizer is to minimize both
|
||
|
|
I/O and CPU cost.</p>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Optimizing Access to each table</h4><p>The optimizer uses
|
||
|
|
a general set of guidelines to choose the best method for accessing data of
|
||
|
|
each table. The optimizer:</p>
|
||
|
|
<ul><li>Determines the default filter factor for each predicate in the selection
|
||
|
|
clause.</li>
|
||
|
|
<li>Determines the true filter factor of the predicates by doing a key range
|
||
|
|
estimate when the selection predicates match the left most keys of an index
|
||
|
|
or by using columns statistic when available.</li>
|
||
|
|
<li>Determines the cost of table scan processing if an index is not required.</li>
|
||
|
|
<li>Determines the cost of creating an index over a table if an index is required.
|
||
|
|
This index is created by performing either a table scan or creating an index-from-index.</li>
|
||
|
|
<li>Determines the cost of using a sort routine or hashing method if appropriate.</li>
|
||
|
|
<li>Determines the cost of using existing indexes using Index Probe or Index
|
||
|
|
Scan <ul><li>Orders the indexes. For SQE, the indexes are ordered in general such
|
||
|
|
that the indexes that access the smallest number of entries are examined first.
|
||
|
|
For CQE, the indexes are generally ordered from mostly recently created to
|
||
|
|
oldest.</li>
|
||
|
|
<li>For each index available, the optimizer does the following: <ul><li>Determines if the index meets the selection criteria.</li>
|
||
|
|
<li>Determines the cost of using the index by estimating the number of I/Os
|
||
|
|
and the CPU cost that will be needed to perform the Index Probe or the Index
|
||
|
|
Scan and the possible Table Probes.</li>
|
||
|
|
<li>Compares the cost of using this index with the previous cost (current
|
||
|
|
best).</li>
|
||
|
|
<li>Picks the cheaper one.</li>
|
||
|
|
<li>Continues to search for best index until the optimizer decides to look
|
||
|
|
at no more indexes.</li>
|
||
|
|
</ul>
|
||
|
|
<p>For SQE, since the indexes are ordered so that the best indexes are
|
||
|
|
examined first, once an index that is more expensive than the previously chosen
|
||
|
|
best index, the search is ended.</p>
|
||
|
|
<p>For CQE, the <em>time limit</em> controls
|
||
|
|
how much time the optimizer spends choosing an implementation. It is based
|
||
|
|
on how much time was spent so far and the current best implementation cost
|
||
|
|
found. The idea is to prevent the optimizer from spending more time optimizing
|
||
|
|
the query than it takes to actually execute the query. Dynamic
|
||
|
|
SQL queries are subject to the optimizer time restrictions. Static SQL queries
|
||
|
|
optimization time is not limited. For OPNQRYF, if you specify OPTALLAP(*YES),
|
||
|
|
the optimization time is not limited. For small tables, the query optimizer
|
||
|
|
spends little time in query optimization. For large tables, the query optimizer
|
||
|
|
considers more indexes. Generally, the optimizer considers five or six indexes
|
||
|
|
(for each table of a join) before running out of optimization time. Because
|
||
|
|
of this, it is normal for the optimizer to spend longer lengths of time analyzing
|
||
|
|
queries against larger tables.</p>
|
||
|
|
</li>
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
<li>Determines the cost of using a temporary bitmap <ul><li>Orders the indexes that can be used for bitmapping. In general the indexes
|
||
|
|
that select the smallest number of entries are examined first.</li>
|
||
|
|
<li>Determine the cost of using this index for bitmapping and the cost of
|
||
|
|
merging this bitmap with any previously generated bitmaps.</li>
|
||
|
|
<li>If the cost of this bitmap plan is cheaper than the previous bitmap plan,
|
||
|
|
continue searching for bitmap plans.</li>
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
<li>After examining the possible methods of access the data for the table,
|
||
|
|
the optimizer chooses the best plan from all the plans examined.</li>
|
||
|
|
</ul>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div>
|
||
|
|
<div class="familylinks">
|
||
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="per0001.htm" title="This overview of the query optimizer provides guidelines for designing queries that will perform and will use server resources more efficiently.">Processing queries: Overview</a></div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</body>
|
||
|
|
</html>
|