|
本站Feed
hash index支持”=”等式查询，不支持”>=”,”< =”,”<”,”>”,”<>”,”between”,”!=”,”like”
如果我们的数据库引擎是InnoDB，那么建立”category_id, created“复合索引是最佳答案。让我们看看InnoDB的索引结构，在InnoDB里，索引结构有一个特殊的地方：非主键索引在其BTree的叶节点上会额外保存对应主键的值，这样做一个最直接的好处就是Covering Index，不用再到数据文件里去取id的值，可以直接在索引里得到它。
如果我们的数据库引擎是MyISAM，那么建立”category_id, created”复合索引就不是最佳答案。因为MyISAM的索引结构里，非主键索引并没有额外保存对应主键的值，此时如果想利用上Covering Index，应该建立”category_id, created, id”复合索引。
细节决定结果！可惜人们往往无视细节的存在。很多人在给表加索引的时候，喜欢直接使用PHPMyAdmin操作，因为这样做操作简单，甚至不用记ALTER TABLE语法，用鼠标点一下就OK了，但是这样做的一个缺点是让使用者忽视了“索引长度”的存在，使用数据的完整长度去建立索引，这本身并没有什么逻辑错误，但是很多时候，我们并不需要使用数据的完整长度去建立索引，比如说有两个老王，一个是北京回龙观的老王，一个是上海徐家汇的老王。如果你按照数据的完整长度去建立索引以便定位老王的话，那么就要完整的索引北京回龙观和上海徐家汇这样的信息，但实际上在本例中回龙观，徐家汇这些地址信息是不必要的，只要提供一下城市信息是北京还是上海，就能定位要找的老王了，这也正是Prefix Index的含义所在，它的意义在于会大大缩减索引文件的大小，从而加快数据检索的速度。
