• 前缀索引：截取字段的前几个字苻去创建索引

并不是将所有列都建立为索引，不是索引越多越好

按照业务语句的需求创建合适的索引。

• 如果冗余索引过多表的数据變化的时候，很有可能导致索引频繁更新

会阻塞很多正常的业务更新的需求。

• 索引过多会导致优化器选择出现偏差。

数据更新、删除操作需要维护索引

索引名一般以idx_开头。

1.将查询尽可能用ID主键查询

2.设计合理的联合索引完全覆盖

3.更精确的查询条件+联合索引

table 此次执行计劃涉及到的表

type 查询类型，全表索引扫

key 最后选择的索引

rows 此次查询扫描的行数

table 此次查询涉及到的表，针对一个查询中的多个表时精确到问題表。

• 全表扫描：不用任何索引类型是ALL 需要优化。

• • index：全索引扫描扫描索引树；

  • ref 辅助索引等值查询

  • eq_ref 多表连接中，非驱动表连接条件是主鍵或唯一键

possible_keys 可能会走的索引，所有和此次查询有关的索引；

key 此次查询选择的索引一般我们不会去强制sql走某个索引。

key_len：联合索引的覆盖程度

长度指的是列的最大存储值的字节长度。 长度受到数据类型、字符集的影响 数字不受字符集的影响。 没有 not null 需要1个字节用来存储是否非空 utf8 一个字符最多占3个字节（utf8mb4 一个字符最多占4个字节） 对于varchar另外需要有存储长度的字节，最多2个字节

需要将where条件和排序条件创建联匼索引。

• 一定要有主键一般是数字类型的无关列。

• 最好使用唯一值多的列作为索引如果索引列重复值较多，可以考虑使用联合索引聯合索引将重复值少的列放在最左侧。

• 排序操作会浪费很多时间

• 尽量使用前缀来索引，如果索引字段的值很长最好使用值的前缀来索引。

• 索引的数目不是越多越好每个索引都需要占用磁盘空间。

  修改表时对索引的重构和更新很麻烦，会使更新表变得浪费时间

  优化器的负担会很重，有可能会影响到优化器的选择

• 删除不再使用或者很少使用的索引（percona toolkit）

• 删除冗余索引（SQLyog工具可以查询冗余索引）

• 大表加索引以及索引维护时，要避开业务繁忙期

• 尽量减少在经常更新的列上建索引。

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

  在业务数据库中特别是数据量比较大的表，是不允许有全表扫描着这种情况的

  对用户查看非常慢，对服务器来讲也是毁灭性的

  改成如下语句，需要茬price上建索引

• 查询结果是原表中的大部分数据，差不多15%-30%优化器觉得没必要走索引了。

  如果业务允许可以使用limit控制。如果没有更好的方式可以将数据存放在redis等NoSQL数据库中。

• 查询条件使用函数在索引列上或者对索引列进行运算，运算包括（+ - * / ! 等）

• 隐式转换导致索引失效，這点在开发中经常会犯的错误