80 lines
5.1 KiB
HTML
80 lines
5.1 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="Proactive approach to tuning" />
|
||
|
<meta name="abstract" content="Typically you will create an index for the most selective columns and create statistics for the least selective columns in a query. By creating an index, the optimizer knows that the column is selective and it also gives the optimizer the ability to use that index to implement the query." />
|
||
|
<meta name="description" content="Typically you will create an index for the most selective columns and create statistics for the least selective columns in a query. By creating an index, the optimizer knows that the column is selective and it also gives the optimizer the ability to use that index to implement the query." />
|
||
|
<meta name="DC.Relation" scheme="URI" content="rzajqindexstrat.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="rzajqproact" />
|
||
|
<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>Proactive approach to tuning</title>
|
||
|
</head>
|
||
|
<body id="rzajqproact"><a name="rzajqproact"><!-- --></a>
|
||
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
|
<h1 class="topictitle1">Proactive approach to tuning</h1>
|
||
|
<div><p>Typically you will create an index for the most selective columns
|
||
|
and create statistics for the least selective columns in a query. By creating
|
||
|
an index, the optimizer knows that the column is selective and it also gives
|
||
|
the optimizer the ability to use that index to implement the query.</p>
|
||
|
<div class="section"><p>In a perfect radix index, the order of the columns is important.
|
||
|
In fact, it can make a difference as to whether the optimizer uses it for
|
||
|
data retrieval at all. As a general rule, order the columns in an index in
|
||
|
the following way: </p>
|
||
|
<ul><li>Equal predicates first. That is, any predicate that uses the "=" operator
|
||
|
may narrow down the range of rows the fastest and should therefore be first
|
||
|
in the index.</li>
|
||
|
<li>If all predicates have an equal operator, then order the columns as follows: <ul><li>Selection predicates + join predicates</li>
|
||
|
<li>Join predicates + selection predicates</li>
|
||
|
<li>Selection predicates + group by columns</li>
|
||
|
<li>Selection predicates + order by columns</li>
|
||
|
</ul>
|
||
|
</li>
|
||
|
</ul>
|
||
|
<p>In addition to the guidelines above, in general, the most selective
|
||
|
key columns should be placed first in the index.</p>
|
||
|
</div>
|
||
|
<div class="section"><p>Consider the following SQL statement: </p>
|
||
|
<pre><strong>SELECT</strong> b.col1, b.col2, a.col1
|
||
|
<strong>FROM</strong> table1 a, table2 b
|
||
|
<strong>WHERE</strong> b.col1='some_value' <strong>AND</strong>
|
||
|
b.col2=some_number <strong>AND</strong>
|
||
|
a.join_col=b.join_col
|
||
|
<strong>GROUP BY</strong> b.col1, b.col2, a.col1
|
||
|
<strong>ORDER BY</strong> b.col1</pre>
|
||
|
</div>
|
||
|
<div class="section"><p>With a query like this, the proactive index creation process can
|
||
|
begin. The basic rules are: </p>
|
||
|
<ul><li>Custom-build a radix index for the largest or most commonly used queries.
|
||
|
Example using the query above: <pre>radix index over join column(s) - a.join_col and b.join_col
|
||
|
radix index over most commonly used local selection column(s) - b.col2 </pre>
|
||
|
</li>
|
||
|
<li>For ad hoc online analytical processing (OLAP) environments or less frequently
|
||
|
used queries, build single-key EVIs over the local selection column(s) used
|
||
|
in the queries. Example using the query above: <pre> EVI over non-unique local selection columns - b.col1 and b.col2</pre>
|
||
|
</li>
|
||
|
</ul>
|
||
|
</div>
|
||
|
</div>
|
||
|
<div>
|
||
|
<div class="familylinks">
|
||
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzajqindexstrat.htm" title="There are two approaches to index creation: proactive and reactive. As the name implies proactive index creation involves anticipating which columns will be most often used for selection, joining, grouping and ordering; and then building indexes over those columns. In the reactive approach, indexes are created based on optimizer feedback, query implementation plan, and system performance measurements.">Indexing strategy</a></div>
|
||
|
</div>
|
||
|
</div>
|
||
|
</body>
|
||
|
</html>
|