sql INDEX，CLUSTERED INDEX，非集群索引

Posted 2021-05-13

/**************************
OVERVIEW
***************************/

/* An INDEX is an on-disk structure associated with a table or view that speeds retrieval of rows from the table or view. An index contains keys built from one or more columns in the table or view. These keys are stored in a structure (B-tree) that enables SQL Server to find the row or rows associated with the key values quickly and efficiently. There are different types of indexes, mainly CLUSTERED and NONCLUSTERED. 

With a CLUSTERED index the rows are stored physically on the disk in the same order as the index. Therefore, there can be only one clustered index.

With a NONCLUSTERED index there is a second list that has pointers to the physical rows. You can have many nonclustered indexes, although each new index will increase the time it takes to write new records. The pointer from an index row in a nonclustered index to a data row is called a row locator. The structure of the row locator depends on whether the data pages are stored in a heap or a clustered table. For a heap, a row locator is a pointer to the row. For a clustered table, the row locator is the clustered index key. 

It is generally faster to read from a clustered index if you want to get back all the columns. You do not have to go first to the index and then to the table.

*/

-- CLUSTERED INDEX example. You can only have one CLUSTERED index, and SQL Server automatically creates a clustered index if you define the column as a PRIMARY KEY. This example creates an index idx_playerID, acting on the playerID column of the batting table.
CREATE CLUSTERED INDEX idx_playerID
ON batting(playerID);

-- to view indexes, go to Object Explorer, click the table in question, and then open the Indexes folder to see the index name(s) and type(s).

/**************************
SOME GENERAL INDEX DO'S
***************************/
/*
--Do Index the Primary and Unique Key Columns

Make certain that the primary key for each table and any unique key columns that exist are indexed. You don't have to index a table's primary 
key yourself because when you create a table and declare the primary key, SQL Server automatically creates a unique index on that column or 
set of columns. However, if another column also contains unique data and you want to maintain the uniqueness of each column entry, you should 
create a unique index or a unique constraint on that column as well. A secondary benefit from indexing the unique key column is the query
performance boost this operation gives to the joins or searches executed on the unique key column.

-- Do Index the Foreign Key Column

If a table contains one or more foreign key columns that reference other tables, you need to index those columns. Foreign key columns are usually 
nonunique because they're on the "many" side of the one-to-many (1:M) relationship. Therefore, you expect to see duplicate values in the foreign 
key column every time one row in the master table (on the "one" side) is related to two or more rows in the detail table (on the "many" side). 
You need to create a unique index on a foreign key column only if you're enforcing a mandatory one-to-one (1:1) relationship between two tables. 
In a 1:1 relationship, the values in the foreign key column are a unique set that corresponds to the primary key values in the master table. 
When the foreign key column in a table is indexed, SQL Server can scan the indexes for the rows it needs instead of scanning both tables.

-- Do Consider Using a Clustered Index for Large Tables and Range-of-Values Queries

A clustered index determines the storage order of the records on disk. The Authors table is clustered on au_id, so au_id is the clustered key. 
When you query the Authors table without specifying ordering criteria, as follows:

SELECT * FROM Authors

The results might display in clustered key order (e.g., the lowest value of au_id might appear at the top of the list, as Figure 2 shows). In SQL 
Server 7.0 and later releases, ordering of the result set can vary, depending on the retrieval strategy that the query optimizer chooses. Therefore, 
don't count on record ordering. Instead, use the ORDER BY option in your queries. However, if you have a large table, particularly a table that you 
often query by using a range-of-values condition on the clustered key (e.g., WHERE au_id between '400-00-0000' and '499-99-9999'), the query 
performance will improve when you use a clustered index. If you join this table to other tables and the clustered key is also a joined column, 
the JOIN query performance might be better than if the query executed the join without a clustered index.
*/

/**************************
SOME GENERAL INDEX DONT'S
***************************/

/*
-- Don't Over-Index Transactional Tables with Heavy I/O Activity

A transactional table is a table in an online transaction processing (OLTP) database. 
You can use transactional tables for reports or as input to programs that export data (e.g., in a SELECT ... FOR XML query). 
However, the OLTP database's primary purpose is capturing data, and if you over-index a transactional table, you might inhibit performance of 
INSERT, UPDATE, and DELETE operations. Each index is a database structure—a table that contains a column of values arranged in ascending order, 
with bookmarks that point to associated rows in the data pages. Therefore, when you add a record to a transactional table, an INSERT operation 
occurs not only on the data page, but also in all associated indexes. And when you delete a row from the data page, SQL Server removes the 
corresponding row from all associated indexes. Certainly you need to create some indexes on heavily used OLTP tables, but don't overdo it—an UPDATE 
operation involves not only the data page but also the number of index pages that matches the number of indexed columns that you need to modify.

-- Don't Index Wide Columns

If a table's columns are wide (i.e., the columns have a data type of char(25) or larger), indexes created on those columns might result in a large 
number of pages, thereby negating the benefit of using an index in the first place. Nonclustered indexes in SQL Server 2000 and 7.0 are structured 
differently from those in earlier releases. If you're not careful, you can create indexes that take more space on disk than the original data pages.
*/