高性能索引策略

• 高性能的索引策略（如何高效实用索引）

高性能的索引策略（如何高效实用索引）

1. 独立的列：索引列不能是表达式的一部分，或者函数的参数。养成好习惯，始终将索引列单独放在比较符的一侧。

   示例：select * from xxtable where xxindex +1 = 10;
   xxindex是索引列，但是由于使用了表达式，导致索引失效；

2. 前缀索引和索引选择性：
   前提：索引很长的字符串时，索引会变的很大也效率很低。
   此类情况解决办法：第一种是使用模拟的哈希索引（不懂不介绍），第二种就是前缀索引。顾名思义，前缀，是将较长字符串从前向后截取一部分，然后作为索引，减小了索引的空间从而提升索引效率。问题来了，截取多少合适呢？此时提出了新名词索引的选择性，书中也说明了，索引选择性越高则查询效率越高！那么什么是索引选择性呢？其实方法很简单，只是这个新名词比较难理解，但实际的思路是很通俗的，就是前缀选择时尽可能可以代表唯一的一条记录。
   索引选择性是一个比值（比如5/10,索引选择性就是0.5），被除数（5）表示的是不重复的记录数，除数（10）表示的是总共的记录数所以，可知唯一索引的索引选择性是1，性能最好。

   通俗理解：如果要索引：abc、abd、adf时，如果前缀索引选择a(key(1))也就是a,则无法很好的区分三个索引，如果选择ab(key(2))时，abc和abd无法区分，这是索引选择性等于2/3，如果选择key(3)时，就是唯一索引了。
   创建前缀命令：ALTER TABLE pre_index_demo ADD KEY(city(2));

3. 多列索引：一个未来提高查询效率的误区，把where条件的列都加上索引，在多个列上创建单列索引，并不能提高MySQL的查询效率。这样做有时候并不能很好的提高效率，最好的效率也仅仅是一个一星索引。不如把忘掉where子句，集中精力优化索引的顺序或者创建一个全覆盖索引。（实践5.6版本，好像已经被优化了，EXPLAIN时extra并没有索引联合或相交的提示）
4. 选择合适的索引列顺序：经验法则，在不考虑排序和分组时，将索引选择性（还记得怎么计算吗？）最高的列放在前面。
5. 聚簇索引：聚簇索引并不是一种单独的索引类型，而是一种数据存储方式。术语“聚簇”表示数据行和键值紧凑的存储在一起，一个表只能有一个聚簇索引，因为数据只存一份。InnoDB的聚簇索引实际是在同一个结构中保存了B-tree索引和数据行，叶子页实际保存了全部数据。InnoDB通过主键聚集数据，而B-Tree特点是顺序存贮，故对于聚簇索引，索引的顺序插入非常影响性能。一般建议主键是一个与数据无关的自动增长的数值，但是如果使用了UUID类似的作为主键，聚簇索引会产生大量的碎片和分页，极其不建议。InnoDB的二级索引，保存了主键的地址，故使用时需要回表，意思是先根据二级索引查找到主键，然后根据主键查询到数据行，需要查询两次，是一个不足支持。
6. 覆盖索引：如果一个索引包含了所有查询所需要的字段的值，成为覆盖索引。
7. 冗余和重复索引：找到冗余和重复索引，删除即可。

索引的合理性，可使用响应时间来判断，通过实际查询来优化索引及SQL。

• 点赞
• 收藏
• 分享
• • 文章举报

思与行 发布了5 篇原创文章 · 获赞 2 · 访问量 150 私信 关注

标签：前缀,读书笔记,聚簇,查询,索引,选择性,第五章,MySQL,主键
来源： https://blog.csdn.net/qq_15392269/article/details/104578263