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 "%_" 百分号在最前面不走
