MySql - 索引

重构地球

索引长度

索引长度短,区分度就低,索引长度长,区分度高,查询效率高,但是索引要占内存,所以要找到一个平衡点;

举个例子: (张,张三,张三哥),如果索引长度取1的话,那么每一行的索引都是 张 这个字,完全没有区分度,结果这样三行完全是随机排的,因为索引都一样;如果长度取2,那么排序的时候至少前两个是排对了的,如果取3,区分度达到100%,已经提前排序;

有一些特殊的字段比如url,绝大部分的url都是 http://www. 开头的,这种情况下索引长度取取到11都是无效的,需要更长的索引,那么有没有优雅的方式来解决呢;
第一种方法: 可以将数据倒序存入数据库;
第二种方法:对字符串进行crc32哈希处理;

建立索引

在多个Where条件的时候,会优先采用rows最少的索引。如果多个Where条件查询很频繁,则将where中所有字段加到联合索引。
注意:

  • 数据区分度低的不应建立索引,比如sex就0、1,即区分50%。一般若rows大于总数据条数20%,则数据库走全表扫描。
  • 如果该表大部分是单条查询,则应使用hash索引,因为B-Tree索引时间复杂度O(log(n)),Hash索引为O(1)。
  • where子句的查询条件里有 != ,索引将无效。可以优化为in(xx, xx)
  • where子句使用了sql函数的时候,索引将无效,比如:select * from tb where YEAR(data) < '2017'; 可优化为 data < CURDATE()
  • LIKE查询必须是前缀固定的,否则无法使用索引。如:Title%可以使用索引,%Title和%Title%不能使用索引。
  • 索引列尽量避免NULL,应该指定列为NOT
    NULL或设置默认值。在MySQL中,含有NULL值的列很难进行查询优化,因为它们使得索引、索引的统计信息以及比较运算更加复杂。索引不存Null值,所以会导致 SELECT * FROM tb WHERE name != 'xxx' 不会返回name为Null的数据。
  • 对于复合索引(key1, key2),select * from tb where key1 = xxx and key2 = xxxselect * from tb where key1 = xxx 会走复合索引,而 select * from tb where key2 = xxx 不会走复合索引。即最左前缀匹配。
  • 当你需要在一篇大的文章中搜索一个词时,如: “WHERE content LIKE
    ‘%apple%’”,索引是没有意义的,这需要全文索引。InnoDB引擎对FULLTEXT索引的支持是MySQL5.6新引入的特性,可对CHAR、VARCHAR、TEXT类型的列创建全文索引,全文搜索的语法:MATCH(col1,col2,…) AGAINST (expr[search_modifier]),默认情况下全文搜索大小写不敏感。
  • 不要触发强制类型扫描,比如 select * from tb where phone = 18812345678,其中phone为varchar,这不会走索引。
  • 在col_1和col_2上建立索引,不要select * from tb col_1=2 or col_2=2,应优化为select * from tb where col_1=2 union select * from tb where col_2=2

索引覆盖(复合索引)

对于select key_1  from t where key_2 ·····;这样的查询,查询的处理过程为:首先去检索key_2索引找到主键id,然后根据主键id去检索正确的数据行。这样就是两次检索。
将key_1和key_2加到联合索引,InnoDB可以直接在索引中获取结果数据集,这就是索引覆盖。

以下情况,InnoDB无法覆盖查询:
1 select选择的字段中含有不在索引中的字段 ,也即索引没有覆盖全部的列。
2 where 条件中不能含有对索引进行like的操作。

Join的列索引化

如果应用程序有很多 JOIN 查询,你应该确认两个表中Join的字段是被建过索引的。这样,MySQL内部会启动为你优化Join的SQL语句的机制。Join的字段,应该是相同的类型的,对于STRING类型,还需要有相同的字符集才行。(两个表的字符集有可能不一样)

阅读 1k

rust-zero

68 声望
4 粉丝
0 条评论

rust-zero

68 声望
4 粉丝
文章目录
宣传栏