Choosing Composite Indexes
A composite index contains more than one key column. Composite indexes can provide additional advantages over single-column indexes:
Improved selectivity
Sometimes two or more columns or expressions, each with poor selectivity, can be combined to form. a composite index with more accurate selectivity.
Reduced I/O
If all columns selected by a query are in a composite index, then Oracle can return these values from the index without accessing the table.
A SQL statement can use an access path involving a composite index if the statement contains constructs that use a leading portion of the index. A leading portion of an index is a set of one or more columns that were specified first and consecutively in the list of columns in the CREATE INDEX statement that created the index. Consider this CREATE INDEX statement:
CREATE INDEX comp_ind
ON tab1(x, y, z);
These combinations of columns are leading portions of the index: x, xy, and xyz. These combinations of columns are not leading portions of the index: yz, y, and z.
Follow these guidelines for choosing keys for composite indexes:
Consider creating a composite index on keys that are frequently used together in WHERE clause conditions combined with AND operators, especially if their combined selectivity is better than the selectivity of either key individually.
If several queries select the same set of keys based on one or more key values, then consider creating a composite index containing all of these keys.
Of course, consider the guidelines associated with the general performance advantages and trade-offs of indexes described in the previous sections. Follow these guidelines for ordering keys in composite indexes:
Create the index so the keys used in WHERE clauses make up a leading portion.
If some keys are used in WHERE clauses more frequently, then be sure to create the index so that the more frequently selected keys make up a leading portion to allow the statements that use only these keys to use the index.
If all keys are used in WHERE clauses equally often, then ordering these keys from most selective to least selective in the CREATE INDEX statement best improves query performance.
If all keys are used in the WHERE clauses equally often but the data is physically ordered on one of the keys, then place that key first in the composite index.
Improved selectivity
Sometimes two or more columns or expressions, each with poor selectivity, can be combined to form. a composite index with more accurate selectivity.
Reduced I/O
If all columns selected by a query are in a composite index, then Oracle can return these values from the index without accessing the table.
A SQL statement can use an access path involving a composite index if the statement contains constructs that use a leading portion of the index. A leading portion of an index is a set of one or more columns that were specified first and consecutively in the list of columns in the CREATE INDEX statement that created the index. Consider this CREATE INDEX statement:
CREATE INDEX comp_ind
ON tab1(x, y, z);
These combinations of columns are leading portions of the index: x, xy, and xyz. These combinations of columns are not leading portions of the index: yz, y, and z.
Follow these guidelines for choosing keys for composite indexes:
Consider creating a composite index on keys that are frequently used together in WHERE clause conditions combined with AND operators, especially if their combined selectivity is better than the selectivity of either key individually.
If several queries select the same set of keys based on one or more key values, then consider creating a composite index containing all of these keys.
Of course, consider the guidelines associated with the general performance advantages and trade-offs of indexes described in the previous sections. Follow these guidelines for ordering keys in composite indexes:
Create the index so the keys used in WHERE clauses make up a leading portion.
If some keys are used in WHERE clauses more frequently, then be sure to create the index so that the more frequently selected keys make up a leading portion to allow the statements that use only these keys to use the index.
If all keys are used in WHERE clauses equally often, then ordering these keys from most selective to least selective in the CREATE INDEX statement best improves query performance.
If all keys are used in the WHERE clauses equally often but the data is physically ordered on one of the keys, then place that key first in the composite index.
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/543979/viewspace-332637/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- Partitioned Indexes on Composite PartitionsIndex
- Composite Indexes (196)Index
- 高效的SQL【Composite Indexes(最佳前導列的選擇)】SQLIndex
- Choosing Column Data Type
- composite
- Choosing between HttpSession and Stateful session beanHTTPSessionBean
- Rebuild IndexesRebuildIndex
- ORACLE INDEXESOracleIndex
- oracle composite partition組合分割槽_composite partition rangeOracle
- Choosing a driver model for developing a USB client driverdevclient
- Oracle - Tables/IndexesOracleIndex
- Reverse Key IndexesIndex
- ORACLE -> NULL & INDEXESOracleNullIndex
- Overview of Partitioned IndexesViewIndex
- Local Partitioned IndexesIndex
- Global Nonpartitioned IndexesIndex
- Extents in Indexes (19)Index
- 翻譯(九)——Clustered Indexes: Stairway to SQL Server Indexes Level 3IndexAISQLServer
- 組合模式(Composite)模式
- composite模式疑問模式
- 【Abaqus】Composite Layup建模
- skip_unusable_indexesIndex
- The Secrets of Oracle Bitmap IndexesOracleIndex
- Restrictions on Create Bitmap IndexesRESTIndex
- Global Range Partitioned IndexesIndex
- Global Hash Partitioned IndexesIndex
- Maintenance of Global Partitioned IndexesAINaNIndex
- Overview of Indexes (194)ViewIndex
- Indexes and Nulls (198)IndexNull
- Codeforces Round #246 (Div. 2) A. Choosing Teams
- composite pattern(組合模式)模式
- SqlTuning&Composite IndexSQLIndex
- Composite模式的疑問模式
- Body SweptSolid Composite GeometrySolid
- B. Composite Coloring
- Sparse Indexes vs unique indexIndex
- SKIP_UNUSABLE_INDEXES InitializationIndex
- 建立Function-Based IndexesFunctionIndex