首先要思考两个问题：
如何在字典中查找指定偏旁的汉字？如何在一本书中查找某内容？对于这两个问题大家都不陌生：在字典中查找指定偏旁的汉字时，首先查询目录中指定的偏旁位置，再查询指定笔画的汉字，最后目录中提供的页码找到这个汉字；在书中查询某内容时，首先在目录中查询该内容所属的知识点，然后根据该知识点所对应的页码快速找到要查询的内容。
而在数据库中也可以建立类似目录的数据库对象，实现数据的快速查询，这就是索引。索引是将表中的一个或者多个字段的值按照特定的结构进行排序然后存储。
我们为什么要使用索引：(这是一个值得深思的问题)
使用索引到底有什么好处呢？如果没有索引，在查找某条记录时，MySQL 必须从表的第一条记录开始，然后通读整个表直到找到相关的记录。如果表越大，那么查找记录所耗费的时间就越多。如果有索引，那么 MySQL 可以快速定位目标记录所在的位置，而不必去浏览表中的每一条记录，效率远远超过没有索引时的搜索效率。
所以索引有自己专门的存储空间，与表独立存放。MySQL 中的索引主要支持以下三种存储方式：
(1) B-Tree 存储结构：使用最多的一种存储结构，使用 B-Tree 存储结构的索引的所有结点都按照 Balance Tree 的数据结构来存储，索引数据结点都在叶子结点。B-Tree 的基本思想是：所有值(被索引的字段)都是排过序的，每个叶结点到根结点距离相等。所以 B-Tree适合用来查找某一范围内的数据，而且可以直接支持数据排序(ORDER BY)。但是当索引为多字段时，字段的顺序特别重要。如图 6-1 所示，为 B-Tree 的存储结构示意图。
(2) R-Tree 存储结构：R-Tree 存储结构主要用于空间索引(设置为空间索引字段的数据类型必须是空间数据类型，如 GEOMETRY、POINT、LINESTRING、POLYGON)。
(3) Hash 存储结构：基于 hash 表的一种存储结构，所以这种存储结构的索引只支持精确查找，不支持范围查找，也不支持排序。这意味着范围查找或 ORDER BY 都要依赖 server层的额外工作。不同的存储引擎支持的存储结构不同：
(1) InnoDB 存储引擎(MySQL5.5 版本之后默认的存储引擎)支持 B-Tree 和 R-Tree
(MySQL5.7 新增功能)，但默认使用的是 B-Tree。
(2) MyISAM 存储引擎(MySQL5.5 版本之前默认的存储引擎)支持 B-Tree 和 R-Tree，
但默认使用的是 B-Tree。
(3) MEMORY 存储引擎支持 B-Tree 和 Hash，但默认是 Hash。
需要注意的：
虽然索引可以提升数据的查询效率，但在使用索引时要注意以下几点：
(1) 索引数据会占用大量的存储空间。
(2) 索引改善检索操作的性能，但降低数据插入、修改和删除的性能。在执行这些操作
时，DBMS 必须动态地更新索引。
(3) 限制表中索引的数目。索引越多，在修改表时对索引做出修改的工作量越大。
(4) 并非所有数据都适合于索引。唯一性不好的数据从索引得到的好处并不多。
(5) 索引用于数据过滤和数据排序。如果你经常以某种特定的顺序排序数据，则该数据
可能是索引的备选。
(6) 可以在索引中定义多个字段(如省+城市)，这样的索引只在以“省+城市”的顺序
排序时有用。如果只想按城市排序，则这种索引没有用处
索引的分类
从逻辑角度分析，可以将索引分为普通索引、唯一索引、主键索引、全文索引、空间索
引和复合索引六种，本小节中将会详细讲述这几种索引的特点。
1. 普通索引
普通索引是最基本的索引，它没有任何限制。创建索引的字段可以是任意数据类型，字段的值可以为空，也可以重复。比如说，创建索引的字段为员工的姓名，但是姓名有重名的可能，所以同一个姓名在同一个“员工个人资料”数据表里可能出现两次或更多次。
2. 唯一索引
如果能确定某个字段的值唯一，那么在为这个字段创建索引的时候就可以使用关键字UNIQUE 把它定义为一个唯一索引。创建唯一索引的好处：简化了 MySQL 对索引的管理工作，唯一索引也因此而变得更有效率；MySQL 会在有新记录插入数据表时，自动检查新记录中该字段的值是否已经在某个记录的该字段中出现过了，如果已经出现，MySQL 将拒绝插入这条新记录。也就是说，唯一索引可以保证数据记录的唯一性。
事实上，在许多场合，人们创建唯一索引的目的往往不是为了提高访问速度，而只是为了避免数据出现重复。
3. 主键索引
主键索引是为主键字段设置的索引，是一种特殊的唯一索引。主键索引与唯一索引的区别是在于：前者在定义时使用的关键字是 PRIMARY KEY，而后者使的是 UNIQUE；前者定义索引的字段值不允许有空值，而后者允许。
4. 全文索引
全文索引适用于在一大串文本中进行查找，并且创建该类型索引的字段的数据类型必须是 CHAR、VARCHAR 或者 TEXT。在 MySQL5.7 之前，全文索引只支持英文检索，因为它是使用空格来作为分词的分隔符，对于中文而言，使用空格是不合适的；从 MySQL5.7 开始，内置了支持中文分词的 ngram 全文检索插件，并且 InnoDB 和 MyISAM 存储引擎均支持全文检索。
5. 空间索引
设置为空间索引字段的数据类型必须是空间数据类型，如 GEOMETRY、POINT、LINESTRING、POLYGON，并且该字段必须设置为 NOT NULL。目前 InnoDB 和 MyISAM存储引擎均支持空间检索。
6. 复合索引
复合索引指在多个字段上创建的索引，这种索引只有在查询条件中使用了创建索引时的第一个字段，该索引才会被触发，这是因为使用复合索引时遵循“最左前缀”的原因。例如：当索引字段为(id, name)时，只有查询条件中适用了 id 字段，该索引才会被使用；如果查询条件中只有 name 字段是不会使用该索引的

端午和朋友去了苏州金鸡湖游玩，不料第二天下大雨，就呆在酒店玩Linux内核编译...感觉没意思就开始看那本总也看不完的《失控》，读到了一个思想，感觉挺有思想。
藏品多没什么意义，关键是索引，你能用最快的速度找到你想找的那件，这才是有意义的。
在一个博尔赫斯的那种包含所有图书的图书馆，找到一本书和写出那本书同样困难，找书的过程其实就是写书的过程。狄德罗，百科全书派人物，畅想了人类知识的汇总，汇总于一个博尔赫斯的图书馆中，但是他假设任何知识都是不可压缩的，即你不能用一个更短的短语来描述一个稍长的短语，在这种情况下，索引就是知识点本身。索引就是一种数据压缩，靠索引来查找会大大减小搜索空间。
       类似的思想，我在很早以前也想过，我曾经觉得，家里只要一本新华字典就够了，因为不管是我的作文还是四大名著，所用的字都在这本字典中，可是，关键之处已经不再是字本身，而是字与字之间的关系。
       在如今的信息碎片化时代，这是多么痛的领悟啊！信息碎片已经淹没了几乎所有人，我们终于有机会徜徉于狄德罗的百科全书了，但是我们什么也找不到，我们处在一个时时刻刻找寻的时代，具体在找什么，谁也不知道，找寻的过程替代了我们思考的过程，殊不知，找寻的代价已经超过了思考的代价。我曾经在Linux终端上工作的时候，希望输入一个之前输过的命令，可以采用三个办法，第一个办法是再输一遍，第二个是使用bash历史命令的自动补全，第三个是往上翻，哪个更节省时间呢？其实我只是想输入一个ls而已，直接输入敲两个字符和一个回车即可，但是如果采用其它两种方式，击键次数无疑会更多，孰优孰劣？值得思索。
       写一本书的代价可能会比找一本书的代价更低...信息太多，等于没有信息。