索引问题小排查

简介： 数据库表已建立相关索引，查询SQL也遵循了相关规范，但是查询SQL依然不走索引。甚至同样的表，同样的索引，同样的查询SQL，在非生产环境走索引，但是生产环境却走了全表扫描。遇到此类问题该如何排查？又有那些注意事项呢？

在日常研发和排查线上环境中，我们常常遇到数据库SQL查询的性能问题。通常而言，我们按照相关的规范要求，针对数据库表，建立合适的索引，在查询SQL中遵循相关的规范即可解决相关问题。但往往也会遇到一些特殊情况。如数据库表已建立相关索引，查询SQL也遵循了相关规范，但是查询SQL依然不走索引。甚至同样的表，同样的索引，同样的查询SQL，在非生产环境走索引，但是生产环境却走了全表扫描。遇到此类问题该如何排查？又有那些注意事项呢？
首先，我们通过执行相关SQL，判断下问题现状，为后续的分析及处理打下基础：
1、运行执行计划，查看是否走索引：
EXPLAIN select file_name1,file_name2 from table_name; //file_name1、file_name2字段名 table_name表名

2、运行语句，查看索引的相关情况
show index from table_name;//table_name 是表名

通过查看，我们可以很清晰的发现，执行计划不走索引，表索引存在，但是索引的cardinality为0。cardinality是索引列的唯一值的个数，如果是复合索引就是唯一组合的个数，是MySQL优化器对语句执行计划进行判定时依据。如果cardinality为0或者较小，MySQL优化器会认为该索引对查询SQL没有帮助，会自动放弃走相关索引。

那么为什么cardinality会较小甚至为0呢，造成这种情况的原因有多种，通常而言包括如下：
1、索引没有区分度，导致cardinality较小，但通常不会为0。该问题比较容易排查，通过查询索引健不重复值即可看出，不再赘述。
2、数据库存储空间不足。在数据库存储空间使用达到一定比例后，导致数据库索引无法真实建立，cardinality为0。
3、频繁的大表删除或插入等，导致关键字的分布存在问题；

根据由易到难的操作，我们通常先排查是否是存储空间不足导致的该现象出现：
1、查看整体大小：
select sum(data_length/1024/1024) as data from tables
2、查看对应的表的大小：
select
concat(truncate(data_length/1024/1024,2),’ MB’) as data_size,
concat(truncate(index_length/1024/1024,2),’ MB’) as index_size
from information_schema.tables
where TABLE_SCHEMA = ‘databse_name’ and TABLE_NAME = ‘table_name’ //databse_name是数据库名 table_name 是表名
通常而言，在使用率超过60%，建议扩容；超过80%,必须扩容。

如果表空间使用率较低，或者扩容后并没有解决相关问题，则建议通过表分析处理。
表分析SQL：analyze table table_name //table_name 是表名
需要提醒的是：表分析建议由DBA处理。表分析因为需要关闭table，然后重新打开table，在有表修改及慢SQL执行的情况下，有很大可能会导致锁表。