索引（BTree索引）的正确使用，可以大大提升SQL查询的效率。但是索引并不是添加后，每次查询都会生效，下面演示一些场景下索引的使用。
现有一张测试表，字段信息如下，下面的案例都是基于这张表的数据进行演示：
如何查看是否使用索引
使用explain关键字，可以查看当前SQL是否使用索引。
#explain是解释计划,说明SQL的执行情况
explain select * from t_content where content_id = 17076710;
可以看到上面的结果中，key字段值为PRIMARY，是用到了主键索引。
当type值为ALL时，表示全表扫描，没有使用任何索引。
新增索引
create index idx_uid on t_content(uid);
idx_uid是索引的名称，一般索引用idx_开头，这样看名字就知道是索引。
t_content是表名称，uid是字段名称。
上面的语句表示在t_content表的uid字段上添加索引，索引的名称为idx_uid。
删除索引
drop index idx_uid on t_content;
idx_uid是索引的名称
t_content是表名称
上面的语句表示删除t_content上面的名称为idx_uid的索引。
下面的文章介绍了如何使用工具，找出冗余索引：
https://blog.csdn.net/liangmengbk/article/details/155753591
索引使用情况统计
#索引使用情况
SELECT
object_type,object_schema,object_name,index_name,
count_read,count_fetch, count_insert,
count_update,count_delete
FROM
performance_schema.table_io_waits_summary_by_index_usage
ORDER BY
sum_timer_wait desc;
上面的SQL可以快速查询出数据库用到的索引情况，查询结果如下：
object_type：数据库对象类型，table指数据表
object_schema：数据库名称
object_name：表名称
index_name：索引名称
count_read：索引在执行过程中，读取了多少行
count_fetch：查询结果的总行数
count_insert：通过索引新增的行数
count_update：通过索引修改的行数
count_delete：通过索引删除的行数
查询结果中，后面的几个数字字段，如果都是0，则说明索引没有被使用过（冗余索引），可以考虑删除该索引。
当index_name为null时，说明之前执行的SQL中，有SQL没有使用到索引，进行了全表扫描。也就是说对于index_name为null的记录越少，说明性能越好，因为用到了索引。
减少表与索引的碎片
索引重新统计
用于对MySQL底层，数据状况进行重新统计，让查询解释器在选择时，执行最优的方案。
analyze table 表名;
例如： analyze table t_content;
optimize优化表空间,释放表空间
对表数据进行重新排列，让表以最优的形式进行排列和存储。
该操作会锁表，一定要在维护期间，否则会造成IO阻塞。
optimize table 表名;
例如： analyze table t_content;
索引有效的场景
下面的使用方式，索引会起到作用，加快查询效率。
精准匹配
范围匹配
类型转换
这种情况，虽然执行计划显示用到了索引，但是不推荐这样写法，因为uid是bigint类型，转成字符串，本身就会消耗资源，降低查询速度。最好的做法就是查询条件与定义相符的类型。
前缀查询
当使用like做模糊检索时，如果模糊检索的字符串，前面没有%，后面使用了%，这种情况也是可以用到索引。
IS NULL
当字段上创建了索引，使用is null，索引会起作用。
复合索引查询条件包含左侧列
上面的查询中，用到了复合索引（多个字段组合形成一个索引），复合索引的字段顺序很重要，在上面的例子中，uid是第复合索引中的第一个字段（左侧列），在查询语句中，uid被放在了查询条件里面，此时索引生效。
复合索引排序只有索引的左侧列
当使用复合索引的左侧列字段，进行order by排序时，也会用到索引，排序效率较高（同时支持正序和倒序）。
复合索引排序与索引字段顺序一致
order by排序的字段，与索引字段的顺序一致，uid在前，source_id在后，该方式会使用索引排序，效率高。
复合索引查询条件同时包含索引列
查询SQL中的where条件里面，同时用到了uid和source_id，这种情况索引有效。
如果是复合索引，查询条件中必须包含索引的左侧列字段。
索引失效的场景
下面的使用方式，索引会失效，即使添加了索引，也不会提升查询效率。
后缀查询
在like查询中，字符串开头使用了%，这种情况索引会失效。
模糊匹配
在like查询中，字符串开头和结尾都使用了%，这种情况索引会失效。
不等号
查询条件中使用不等号（<>）会导致索引失效。
NOT IN
查询条件中使用not in会导致索引失效。
IS NOT NULL
is not null不会用到索引
对索引列进行计算
uid字段上面，已经创建了索引，但是用运算后，查询时，就不会用到索引。
对索引列使用函数
uid字段上面，已经创建了索引，但是用CAST函数对字段值进行处理，查询时，就不会用到索引。
复合索引查询条件只含右侧列
在上面的示例中，复合索引包含了两个字段，uid和source_id，uid在第一位，source_id在第二位。
查询SQL中只用source_id作为查询条件，并没有使用uid，导致索引失效。
如果是复合索引，查询条件中必须包含索引的左侧列字段。
复合索引排序用右侧列
在上面的语句中，source_id字段是复合索引右侧列字段，在排序时仅用右侧列进行排序，那么排序就是Using filesort，也就是比较慢的排序方式。
复合索引排序列顺序颠倒
在上面的语句中，uid和source_id字段组成了复合索引，uid是索引的左侧字段，当使用order by进行排序时，如果source_id（索引右侧列）在前面，不会使用索引，排序就是Using filesort方式，比较慢的排序方式。
复合索引排序列左侧字段为降序
在上面的语句中，uid和source_id字段组成了复合索引，uid是索引的左侧字段，当使用order by进行排序时，如果uid（索引左侧列）为desc(降序)，不会使用索引，排序就是Using filesort方式，比较慢的排序方式。