2020-02-27索引2

possible key

可能会走索引

key:显示走的索引键

key_len: 索引长度

utf8mb4 varchar(10)  以最大的存储长度计算

10 中文 40

10英文 10 

10个数据 10

联合索引的长度：

add  index idx_name(a,b,c)

select * from ten where a='aa' and b='bb' and c='cc';

联合索引  的key_len越大越好

联合索引的优化细节：

utfmb4  最大预留长度是4

utf8 最大预留长度是3

gbk 最大预留长度是2

1 查询情况下  所有的索引都是等值的情况下无关顺序

（abc）

查询只有ac的时候只能走a

唯一值多的放在最左侧

where出现 > < like  放到最右侧  重新创建索引

select * from  ten where k1 ='aa' order by k2    alter table ten add index idx_k1k2(k1,k2)

extra:

Using filesort  说明索引设计不合理  

order by 

group by

distinct

union

索引优化

公司业务慢 从数据库的角度分析原因：

1 show processlist 获取导致数据库慢的语句

2 explain 分析执行计划 有没有走索引

3 建索引，改语句

一段时间慢（应急性的资源耗尽）还是持续性的慢 

数据库卡了  维护性的动作还是可以做的

show processlist  我发现是一个很大查询语句

desc 看看查询计划

建立索引的 应用规范

1  必须要有主键

2  经常为where条件列 order by group by join on distinct

3  索引避开业务繁忙时期

4 不要盲目创建索引 降低条目数

5 小表不要建立索引

9.2.1 没有查询条件，或者查询条件没有建立索引   

9.2.2 查询结果集是原表中的大部分数据，应该是25％以上。

9.2.3 索引本身失效，统计数据不真实   ：索引数据更新不及时导致的

9.2.4 查询条件使用函数在索引列上，或者对索引列进行运算，运算包括(+，-，*，/，! 等)  :where id-99=2

9.2.5 隐式转换导致索引失效.这一点应当引起重视.也是开发中经常会犯的错误.

9.2.6 <> ，not in 不走索引（辅助索引）

9.2.7 like "%_" 百分号在最前面不走