Clustered and Secondary Indexes

Clustered and Secondary Indexes

secondary index

  A type of InnoDB index that represents a subset of table columns. An InnoDB table can have zero, one, or many

secondary indexes. (Contrast with the clustered index, which is required for each InnoDB table, and stores the data for

all the table columns.)

 

  Every InnoDB table has a special index called the clustered index where the data for the rows is stored. Typically, the

clustered index is synonymous with the primary key. To get the best performance from queries, inserts, and other database

operations, you must understand how InnoDB uses the clustered index to optimize the most common lookup and DML

operations for each table.

  • When you define a PRIMARY KEY on your table, InnoDB uses it as the clustered index. Define a primary key for each table

that you create. If there is no logical unique and non-null column or set of columns, add a new auto-increment column, whose

values are filled in automatically.

  • If you do not define a PRIMARY KEY for your table, MySQL locates the first UNIQUE index where all the key columns are

NOT NULL and InnoDB uses it as the clustered index.

  • If the table has no PRIMARY KEY or suitable UNIQUE index, InnoDB internally generates a hidden clustered index on a synthetic

column containing row ID values. The rows are ordered by the ID that InnoDB assigns to the rows in such a table. The row ID is

a 6-byte field that increases monotonically as new rows are inserted. Thus, the rows ordered by the row ID are physically in

insertion order.

How the Clustered Index Speeds Up Queries

  Accessing a row through the clustered index is fast because the index search leads directly to the page with all the row data.

If a table is large, the clustered index architecture often saves a disk I/O operation when compared to storage organizations

that store row data using a different page from the index record. (For example, MyISAM uses one file for data rows and another

for index records.)

How Secondary Indexes Relate to the Clustered Index

  All indexes other than the clustered index are known as secondary indexes. In InnoDB, each record in a secondary index

contains the primary key columns for the row, as well as the columns specified for the secondary index. InnoDB uses this primary

key value to search for the row in the clustered index.

  If the primary key is long, the secondary indexes use more space, so it is advantageous to have a short primary key.

Clustered and Secondary Indexes

时间: 2024-11-05 21:45:59

Clustered and Secondary Indexes的相关文章

clustered and nonclustered indexes

SQL Server has two basics kinds of indexes.  They are clustered and nonclustered indexes.  There are some fundamental differences to the two which are key to understanding before you can master index tuning. First the things that they have in common.

MySQL 加锁处理分析

1    背景    1 1.1    MVCC:Snapshot Read vs Current Read    2 1.2    Cluster Index:聚簇索引    3 1.3    2PL:Two-Phase Locking    3 1.4    Isolation Level    4 2    一条简单SQL的加锁实现分析    5 2.1    组合一:id主键+RC    6 2.2    组合二:id唯一索引+RC    6 2.3    组合三:id非唯一索引+RC 

mysql事务和锁InnoDB(转)

背景 MySQL/InnoDB的加锁分析,一直是一个比较困难的话题.我在工作过程中,经常会有同事咨询这方面的问题.同时,微博上也经常会收到MySQL锁相关的私信,让我帮助解决一些死锁的问题.本文,准备就MySQL/InnoDB的加锁问题,展开较为深入的分析与讨论,主要是介绍一种思路,运用此思路,拿到任何一条SQL语句,都能完整的分析出这条语句会加什么锁?会有什么样的使用风险?甚至是分析线上的一个死锁场景,了解死锁产生的原因. 注:MySQL是一个支持插件式存储引擎的数据库系统.本文下面的所有介绍

14.7 InnoDB Table Compression

pdf:http://download.csdn.net/detail/paololiu/9576929 14.7 InnoDB Table Compression 14.7.1 Overview of Table Compression 14.7.2 Enabling Compression for a Table 14.7.3 Tuning Compression for InnoDB Tables 14.7.4 Monitoring Compression at Runtime 14.7.

【转载】MySQL 加锁处理分析

1    背景    1 1.1    MVCC:Snapshot Read vs Current Read    2 1.2    Cluster Index:聚簇索引    3 1.3    2PL:Two-Phase Locking    3 1.4    Isolation Level    4 2    一条简单SQL的加锁实现分析    5 2.1    组合一:id主键+RC    6 2.2    组合二:id唯一索引+RC    6 2.3    组合三:id非唯一索引+RC 

Mysql加锁过程详解

1.背景 MySQL/InnoDB的加锁分析,一直是一个比较困难的话题.我在工作过程中,经常会有同事咨询这方面的问题.同时,微博上也经常会收到MySQL锁相关的私信,让我帮助解决一些死锁的问题.本文,准备就MySQL/InnoDB的加锁问题,展开较为深入的分析与讨论,主要是介绍一种思路,运用此思路,拿到任何一条SQL语句,都能完整的分析出这条语句会加什么锁?会有什么样的使用风险?甚至是分析线上的一个死锁场景,了解死锁产生的原因. 注:MySQL是一个支持插件式存储引擎的数据库系统.本文下面的所有

MySQL 加锁处理分析 转

MySQL 加锁处理分析  转 http://hedengcheng.com/?p=771 十二 13th, 2013 发表评论 | Trackback 1    背景    1 1.1    MVCC:Snapshot Read vs Current Read    2 1.2    Cluster Index:聚簇索引    3 1.3    2PL:Two-Phase Locking    3 1.4    Isolation Level    4 2    一条简单SQL的加锁实现分析 

[MySQL FAQ]系列 — 为什么InnoDB表要建议用自增列做主键

[MySQL FAQ]系列 — 为什么InnoDB表要建议用自增列做主键 http://imysql.com/2014/09/14/mysql-faq-why-innodb-table-using-autoinc-int-as-pk.shtml 我们先了解下InnoDB引擎表的一些关键特征: InnoDB引擎表是基于B+树的索引组织表(IOT): 每个表都需要有一个聚集索引(clustered index): 所有的行记录都存储在B+树的叶子节点(leaf pages of the tree):

mysql事务和锁InnoDB

背景 MySQL/InnoDB的加锁分析,一直是一个比较困难的话题.我在工作过程中,经常会有同事咨询这方面的问题.同时,微博上也经常会收到MySQL锁相关的私信,让我帮助解决一些死锁的问题.本文,准备就MySQL/InnoDB的加锁问题,展开较为深入的分析与讨论,主要是介绍一种思路,运用此思路,拿到任何一条SQL语句,都能完整的分析出这条语句会加什么锁?会有什么样的使用风险?甚至是分析线上的一个死锁场景,了解死锁产生的原因. 注:MySQL是一个支持插件式存储引擎的数据库系统.本文下面的所有介绍