mysql查看索引，执行计划，联合索引

一，查看t2表的索引：
mysql> show index from t2 \G
*************************** 1. row ***************************
Table: t2
Non_unique: 0
Key_name: PRIMARY
Seq_in_index: 1
Column_name: id
Collation: A
Cardinality: 0
Sub_part: NULL
Packed: NULL
Null:
Index_type: BTREE
Comment:
Index_comment:

Collation: A 列以什么方式存储在索引中，可以是A或NULL，B+树索引总是A，即排序的。
cardinality:非常关键的值，表示索引中唯一值的数目的估计值，cardinality除以表的行数应尽可能接近1，
如果非常小，那么用户考虑是否可以删除该索引。

Index_type: BTREE #索引的类型，innodb存储引擎只支持B+树索引，所以这里显示的都是BTREE。
Cardinality:值非常关键，优化器会根据这个值来判断是否使用这个索引，这个值并不是实时更新的，
即并非每次索引更新都会更新该值，因为这样代价非常大，因此该值不太准确，
如果想要更新Cardinality，可以使用analyze table；

mysql5.5之前，对于数据库索引的添加或删除这类DDL操作，mysql的操作过程为：
首先创建一张新的临时表，表结构通过alter table新定义的结构
然后把原表中数据导入到临时表。
接着删除原表
然后把临时表命名为原来的表。

可以发现，若用户对于一张大表进行索引的添加或删除工作，那么需要很长的时间，若有大量事物需要访问被修改的表，
这意味着数据库不可用，后来mysql开始支持一种新的叫做 fast index creation的索引创建方式 FIC.

对于辅助索引的创建，innodb存储引擎会对创建索引的表加上一个S锁，在创建过程中不需要重建表，
因此速度较之前快很多，并且数据库的可用性得到提高，删除辅助索引就更简单了，innodb存储引擎只需更新内部视图
并将辅助索引的空间标记为可用，同时删除mysql数据库内部视图上对该表的索引定义即可。

这里需要特别注意的是，临时表的创建路径是通过参数tmpdir进行设置的，用户必须保证tmpdir有足够的空间可以
存放临时表，否则会导致创建临时表失败。
由于FIC在索引创建的过程中对表加了S锁，因此创建的过程中只能对该表读，此外，FIC

mysql5.6开始支持online DDL操作，其允许辅助索引创建的同时，还允许诸如其他insert update delete这类DML操作，
极大的提高了mysql数据库生产环境的可用性。
此外不仅是辅助索引，以下这几类DDL操作都可以通过在线的方式进行操作：
辅助索引的创建于删除
改变自增长值
添加或删除外检约束
列的重命名

cardinality
并不是在所有的查询条件中出现的列都需要添加索引，对于什么时候添加B+树索引？
一般的经验是：在访问表中很少一部分时使用B+树索引才有意义，
对于性别字段，地区字段，类型字段，他们的取值范围很小，称为低选择性。
对性别进行查询时，可取值的范围一般只有 M F ,因此上述SQL语句得到的结果可能是该表50%的数据。

怎样查看索引是否是高选择性的呢？
可以通过show index 结果中的列cardinality来观察，cardinality值非常关键，表示索引中不重复记录数量的预估值。
需要同时注意的是cardinality是一个预估值，而不是一个准确值，基本上用户也不可能得到一个准确值。
cardinality/n_rows_in_table应尽可能地接近1，若果太小，可考虑放弃该索引。

建立索引的前提是高选着性，cardinality的统计是仿真存储引擎层完成的。
在生产环境中，索引的更新操作可能是非常频繁的，如果每次索引在发生操作时就对其进行cardinality的统计，
那么将给数据库带来非常大的负担，此外如果一张表有50G的数据，那么统计一次cardinality将要非常耗时，
在生产环境也是不能接受的，因此数据库对于cardinality的统计是通过采样（sample）的方法来完成的。

innodb存储引擎内部对更闹心cardinality信息的策略为：
1 表中1/16的数据已发生变化。
自上次统计后，表中1/16的数据发生了变化，这时需要统计cardinality。
2 stat_modified_counter>2 000 000 000

默认innodb存储引擎对8个叶子节点进行采样，采样过程如下：
取得B+树索引叶子节点的数量，计为A。
随机取得B+树索引中的8个叶子节点，统计每个页不同的个数，P1,P2…P8
根据采样信息给出cardinality的预估值;cardinary=(P1+P2+…P8)*A/8

可以通过innodb_stats_sample_pages 设置统计cardinality时每次采样页的数量，默认8，（已经被innodb_stats_transisent_sample_pages参数取代）
参数innodb_stats_method用来判读如何对待索引记录中出现的NULL值记录。默认nulls_equal,表示将NULL值记录视为相等的记录
其有效值还有 nulls_unequal,nulls_ignored
另外当执行 SQL语句ananlyze table ,show table status,show index 以及访问information_schema架构下的表tables和statistics
时都会导致innodb存储引擎去重新计算索引的cardinality值，
若表中的数据量巨大，且存在多个辅助索引，执行上述命令会非常慢。