当我们使用desc查看表的结构时，会看到如下结果：
mysql> desc t1;
+-------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------+-------------+------+-----+---------+-------+
| name | varchar(32) | YES | | NULL | |
| age | int(11) | YES | | NULL | |
+-------+-------------+------+-----+---------+-------+
2 rows in set (0.00 sec)我们可以看到，返回的结果集是一个表格，第一列Field是表中的字段名，Type是字段的类型，而Null这一列，是该字段是否可以为空，Key为是索引类型，Default为是否有默认值，最后的Extra表示的是表的外键。
除了Key之外，其他列的定义在前面介绍过。
1. 什么是索引
用一句说烂了的概念就是：索引就像书的目录， 通过书的目录就准确的定位到了书籍具体的内容。
索引的好处是在海量数据的表中才能体现出来的，例如，在几千条数据中查找一条数据时，可能只需要零点几秒，但是在处理上千万，上亿条数据时，所花费的时间是惊人的。因为没有加索引的数据是按顺序的保存在硬盘上的，再查找一个数据时，DBMS会一个一个遍历这些数据来查找，所以时间复杂度为O(n)，而且在数据量很多时，它们是从硬盘逐次读进内存中的，IO操作的慢速，想必大家都深有耳闻。
而如果给数据加上了索引，就像有了一个到达该数据的线索，可以摈弃绝大多数毫无意义的遍历和IO操作，节省的时间是肉眼级别的。
2. 索引的实现
既然索引这么高效，那是怎么做到这些功能的呢。
实际上，添加了索引的字段数据，就不像普通数据一样按顺序保存在硬盘上，而是被DBMS维护成了一个平衡树(不一定是平衡二叉树，可能会分更多的叉)，平衡树搜索一个数据的时间复杂度为O(logn)，log底数为平衡树的叉数，大家可以设想，在x非常大的时候，加了索引的效率比不加索引的效率好得多。以一亿条数据为例，不加索引最坏要查找100000000次，而加了索引，哪怕是一个二叉树的索引，最坏也只查找19次。
大家可以在我的GitHub下载随机生成八百万数据的数据库脚本，尝试一下海量数据的普通查找，那速度，慢到令人发指。
3. 索引的代价
如果大家尝试了上面的数据库脚本，会发现在添加索引的时候，也会花费一定的时间，这就是索引的代价。
占用磁盘空间，进行树的维护。
当添加一条记录，除了添加到表中，还要维护树，速度有影响，但不大(比起数据库频繁的查找操作)。
当我们添加一个索引，不能够解决所有查询问题，需要分别给字段建立索引(聚集性索引与非聚集性索引)；例如 select * from EMP where
ename=’abcdef’;索引是以空间换时间。
4. 创建索引的原则
索引是在表的字段上创建的，但是也不是每个字段都适合添加索引，应遵守以下原则：
比较频繁作为查询条件的字段应该创建索引。
唯一性太差的字段不适合单独创建索引，即使频繁作为查询条件
select * from EMP where sex=’男’;更新非常频繁的字段不适合作创建索引，毕竟更新删除索引字段开销还是有的。
不会出现在where子句中的字段不该创建索引，没有必要。