nvl函数上 建立索引 建立索引的数据类型

MySQL索引类型包括：

普通索引

这是最基本的索引，它没有任何限制。它有以下几种创建方式：

创建索引CREATE INDEX indexName ON mytable(username(length));

//如果是CHAR，VARCHAR类型，length可以小于字段实际长度；如果是BLOB和TEXT类型，必须指定 length，下同。

修改表结构ALTER mytable ADD INDEX [indexName] ON (username(length)); //创建表的时候直接指定

CREATE TABLE mytable( ID INT NOT NULL, username VARCHAR(16) NOT NULL, INDEX [indexName] (username(length)) ); //删除索引的语法：

DROP INDEX [indexName] ON mytable;

唯一索引

它与前面的普通索引类似，不同的就是：索引列的值必须唯一，但允许有空值。如果是组合索引，则列值的组合必须唯一。它有以下几种创建方式：

创建索引CREATE UNIQUE INDEX indexName ON mytable(username(length)); //修改表结构

ALTER mytable ADD UNIQUE [indexName] ON (username(length)); //创建表的时候直接指定

CREATE TABLE mytable( ID INT NOT NULL, username VARCHAR(16) NOT NULL, UNIQUE [indexName] (username(length)) );

主键索引

它是一种特殊的唯一索引，不允许有空值。一般是在建表的时候同时创建主键索引：

CREATE TABLE mytable( ID INT NOT NULL, username VARCHAR(16) NOT NULL, PRIMARY KEY(ID) );

//当然也可以用 ALTER 命令。记住：一个表只能有一个主键。

组合索引

为了形象地对比单列索引和组合索引，为表添加多个字段：

CREATE TABLE mytable( ID INT NOT NULL, username VARCHAR(16) NOT NULL, city VARCHAR(50) NOT NULL, age INT NOT NULL );

为了进一步榨取MySQL的效率，就要考虑建立组合索引。就是将 name, city, age建到一个索引里：

ALTER TABLE mytable ADD INDEX name_city_age (name(10),city,age);

建表时，usernname长度为 16，这里用 10。这是因为一般情况下名字的长度不会超过10，这样会加速索引查询速度，还会减少索引文件的大小，提高INSERT的更新速度。

如果分别在 usernname，city，age上建立单列索引，让该表有3个单列索引，查询时和上述的组合索引效率也会大不一样，远远低于我们的组合索引。虽然此时有了三个索引，但MySQL只能用到其中的那个它认为似乎是最有效率的单列索引。

建立这样的组合索引，其实是相当于分别建立了下面三组组合索引

usernname,city,age usernname,city usernname 为什么没有 city，age这样的组合索引呢？这是因为MySQL组合索引“最左前缀”的结果。简单的理解就是只从最左面的开始组合。并不是只要包含这三列的查询都 会用到该组合索引

下面的几个SQL就会用到这个组合索引：

SELECT * FROM mytable WHREE username="admin" AND city="株洲" SELECT * FROM mytable WHREE username="admin" 而下面几个则不会用到：

SELECT * FROM mytable WHREE age=20 AND city="株洲" SELECT * FROM mytable WHREE city="株洲"

什么时候使用到索引

到这里我们已经学会了建立索引，那么我们需要在什么情况下建立索引呢？一般来说，在WHERE和JOIN中出现的列需要建立索引，但也不完全如此， 因为MySQL只对<，<=，=，>，>=，BETWEEN，IN，以及某些时候的LIKE才会使用索引。

例如：

SELECT t.Name FROM mytable t LEFT JOIN mytable m ON t.Name=m.username WHERE m.age=20 AND m.city=’株洲’ 此时就需要对city和age建立索引，由于mytable表的userame也出现在了JOIN子句中，也有对它建立索引的必要。

刚才提到只有某些时候的LIKE才需建立索引。因为在以通配符%和_开头作查询时，MySQL不会使用索引。

例如下句会使用索引：

SELECT * FROM mytable WHERE username like’admin%’ 而下句就不会使用：

SELECT * FROM mytable WHEREt Name like’%admin’ 因此，在使用LIKE时应注意以上的区别。

索引的不足之处

上面都在说使用索引的好处，但过多的使用索引将会造成滥用。因此索引也会有它的缺点：

虽然索引大大提高了查询速度，同时却会降低更新表的速度，如对表进行INSERT、UPDATE和DELETE。因为更新表时，MySQL不仅要保存数据，还要保存一下索引文件。建立索引会占用磁盘空间的索引文件。一般情况这个问题不太严重，但如果你在一个大表上创建了多种组合索引，索引文件的会膨胀很快。索引只是提高效率的一个因素，如果你的MySQL有大数据量的表，就需要花时间研究建立最优秀的索引，或优化查询语句。

使用索引的的细节问题【须知】

使用索引时，有以下一些技巧和注意事项：

索引不会包含有NULL值的列只要列中包含有NULL值都将不会被包含在索引中，复合索引中只要有一列含有NULL值，那么这一列对于此复合索引就是无效的。所以我们在数据库设计时不要让字段的默认值为NULL。

使用短索引对串列进行索引，如果可能应该指定一个前缀长度。例如，如果有一个CHAR(255)的列，如果在前10个或20个字符内，多数值是惟一的，那么就不要对整个列进行索引。短索引不仅可以提高查询速度而且可以节省磁盘空间和I/O操作。

索引列排序MySQL查询只使用一个索引，因此如果where子句中已经使用了索引的话，那么order by中的列是不会使用索引的。因此数据库默认排序可以符合要求的情况下不要使用排序操作；尽量不要包含多个列的排序，如果需要最好给这些列创建复合索引。

like语句操作一般情况下不鼓励使用like操作，如果非使用不可，如何使用也是一个问题。like “%aaa%” 不会使用索引而like “aaa%”可以使用索引。

不要在列上进行运算select id from userinfo where YEAR(adddate)<2007;

//将在每个行上进行运算，这将导致索引失效而进行全表扫描，因此我们可以改成

select id from userinfo where adddate<‘2007-01-01’;

尽量不要使用NOT IN和<>操作因为逻辑判断会让索引失效。

————————————————————————————————————————

从另一角度来看索引也可以这样进行划分

MySQL聚集索引和非聚集索引

聚集索引

聚集索引的作用对象是一张表数据的物理地址，聚集索引使得数据按照物理地址顺序的存储在存储介质中，数据的物理地址也是连续的，因此聚集索引是查询速度最快的索引，其查询原理是二分法。

聚集索引尽量建立在值不会发生变更的列上，否则会带来非聚集索引的维护。一般来说这个索引建立在ID列上，而该ID则一般赋予一个自增的属性。这样做的意义和好处是当向表中插入一条ID序号靠前的数据时，不会因为插入一条数据，而移动整个数据集合的物理地址。

尽量在建立非聚集索引之前建立聚集索引，否则会导致表上所有非聚集索引的重建，聚集索引应该避免建立在数值单调的列上，否则可能会造成IO的竞争，以及B树的不平衡，从而导致数据库系统频繁的维护B树的平衡性。聚集索引的列值最好能够在表中均匀分布

但是对于业务的角度上来说，自增的ID列往往是个相对来说没有意义的字段，而且聚集索引一个表中只能存在一个。所以这里又引入了一个非聚集索引的概念。

非聚集索引

非聚集索引定义的原则往往是基于业务逻辑。非聚集索引在物理地址上不相邻，更像是一个数据字典索引。

在使用非聚集索引时，首先通过一级索引字典查出来一个包含所需数据内容的数据块，一般是8K的数据块，而后遍历这个数据块找到所需数据。非聚集索引速度比聚集索引慢，但是一个表中非聚集可以建立多个。

 

非聚集索引又分唯一非聚集索引和非唯一两种，这同样是依据业务逻辑而定的，唯一非聚集索引指的是一个由多个业务字段组成的索引，在业务逻辑上是唯一的，反之就是非唯一的非聚集索引。比如“中国+身份证号”，这就是一个唯一索引，因为中国的每个身份证号理论上都是唯一的。而“中国+姓名”则是一个非聚集索引，因为中国又很多重名的人。

相比之下，唯一非聚集索引速度更快，这是因为查询过程中，一旦查到符合要求的数据，数据库会立刻停止查找，因为其是唯一的，继续查下去就没有意义了。反之，非唯一非聚集索引就会慢一些，因为即使查到了一条数据后，还要继续向后查找，因为本条数据在数据库中是非唯一的，仍然可能有其他索引字段相同的数据存在，所以查询开销会增加。

区别

聚集索引是一种物理排序规则，数据按照聚集索引列有序的排列，查询时根据数据查询范围即可直接定位数据内容。

非聚集索引是一种映射的数据字典，数据在物理空间中是乱序的，字典中存储了索引列的位置映射，在查询使先根据字典查询出数据所在的大致物理位置，再去相应的物理位置查询数据的具体内容。

Innodb的聚集索引

Innodb的存储索引是基于B+tree，理所当然，聚集索引也是基于B+tree。与非聚集索引的区别则是，聚集索引既存储了索引，也存储了行值。当一个表有一个聚集索引，它的数据是存储在索引的叶子页（leaf pages）。因此innodb也能理解为基于索引的表。

* 那么Innodb如何决定那个索引作为聚集索引呢？*

Innodb如何选择一个聚集索引

对于Innodb，主键毫无疑问是一个聚集索引。但是当一个表没有主键，或者没有一个索引，Innodb会如何处理呢。请看如下规则

如果一个主键被定义了，那么这个主键就是作为聚集索引

如果没有主键被定义，那么该表的第一个唯一非空索引被作为聚集索引

如果没有主键也没有合适的唯一索引，那么innodb内部会生成一个隐藏的主键作为聚集索引，这个隐藏的主键是一个6个字节的列，改列的值会随着数据的插入自增。

还有一个需要注意的是：

次级索引的叶子节点并不存储行数据的物理地址。而是存储的该行的主键值。

所以：一次级索引包含了两次查找。一次是查找次级索引自身。然后查找主键（聚集索引）