前言

近几个月在华为实习的过程中，有个场景下取数，对于一个sn号的查询竟然长达几分钟的时间，批量查几十个sn时，则需要一二十分钟的sql查询时间，故专门对这个问题进行一些整理和思考。
首先，这个数据库是存在HIVE上，经过和一些前辈交流后，了解到企业中的数据库主要分为两大种：OLTP（on-line transaction processing）事务型、OLAP（On-Line Analytical Processing）分析型。

OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。
OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。

那么，事务型数据库OLTP主要以小的事务以及小的查询为主，评估其系统的时候，一般看其每秒执行的Transaction以及Execute SQL的数量。在这样的系统中，单个数据库每秒处理的Transaction往往超过几百个，或者是几千个，Select 语句的执行量每秒几千甚至几万个。OLTP系统最容易出现瓶颈的地方就是CPU与磁盘子系统。
OLAP，也叫联机分析处理（Online Analytical Processing）系统，有的时候也叫DSS决策支持系统，就是我们说的数据仓库。在这样的系统中，语句的执行量不是考核标准，因为一条语句的执行时间可能会非常长，读取的数据也非常多。所以，在这样的系统中，考核的标准往往是磁盘子系统的吞吐量（带宽），如能达到多少MB/s的流量。磁盘子系统的吞吐量则往往取决于磁盘的个数，这个时候，Cache基本是没有效果的，数据库的读写类型基本上是db file scattered read与direct path read/write。应尽量采用个数比较多的磁盘以及比较大的带宽，如4Gb的光纤接口。
在OLAP系统中，常使用分区技术、并行技术。

查询速度影响因素

回到正题，为什么我用了索引，查询速度还是很慢？到底会出现什么问题，以及如何去解决？本文来探究一二。

先给出结论：MySQL用到了索引和执行时间的长短没有必然关系，确定查询执行效率的是 “扫描行数”与“回表次数”。

扫描行数
回表次数

在实际的sql优化过程中，也是尽量去优化这两块影响因素。

举例

举例说明：

CREATE TABLE t
id int(11)NOT NULL
a varchar(64)DEFAULT NULL,
b int(11)DEFAULT NULL,
PRIMARY KEY (id)
KEY a(a) ENGINE-InnoDBQuery OK, O rows affected(0.02 sec)

先建一个表，InnoDB必须有一个主键索引，这里给id为主键，其次有a、b两个字段，再给a字段（姓名字段）一个普通索引，目前就有了主键索引和a索引树结构，如下图所示：

这里再回顾一下，InnoDB默认有主键索引，存储的是主键id1、2、3…，它是采用B+ tree的聚簇索引，所有的数据都存放在叶子结点中，而普通索引a的数据只包含对应的id，没有整行数据，所以如果通过普通索引找到了某个id，需要select别的字段，则还需要回表找主键索引中的整行数据取值！

慢查询:
sq中慢查询阈值为ong_ query time=10s
当sq执行后大于10s就会被记录到慢sq志
般建议缩小到1s，一般来说当并发系统中某一条sql查询时间大于1s了，对整体系统的性能影响就会比较大了。

情况1：

select * from t #全表扫描

其中，type=ALL表示扫描所有行，速度是最慢的，从头到尾扫描。

情况2：

select * from where id = 2 #主键索引快速过滤

根据主键id索引进行查询，这时采用了key也就是索引，速度是最快的，也不用回表

情况3：

select a from t #索引覆盖，无需回表

采用了索引覆盖，查询速度也是很快的，因为也不用回表，采用了索引为a，取的也是a字段，也是一步到位。

在MySQL大分页的过程中也用到了索引覆盖的方式进行了优化

情况4：

select * from t where id>0 #基于id扫描全表，且产生大量回表，速度慢

用*或者多个字段可能要全表扫描。
一般来说查询的数据量要是全表的25%以内，数据库才会判断有走索引的价值，这里不能光看key中有primary就认为走了索引就很快，而还要看row中扫描了多少行，这种情况下row中的行数就等于表的总行数，查询的速度并不快，是全表扫描！

情况5：

create index t on(a, b)
假设t表有1亿人,其中600万姓“张”select* from t where a=张三 and b=23
索引选择性就很好select from t where a like 5k%' and b =23
索引选择性较差,但仍会用到索引

作为联合索引，根据前面博客提到的最左前缀法则，我们必须在where中按照联合索引的顺序来查，在左索引基础上查右索引，所以第一句sql是比较快的，直接可以在联合索引树中找到张三这个人；而第二句由于使用了模糊查询，如果姓张的人超过了总数的10%、15%，MySQL就会认为这样的选择性太差，就不会给使用索引了！（没有使用索引的价值！）而转去走全表扫描了。这里的设计是1亿人中有600万人姓“张”，所以虽然索引选择性相对较差，但是MySQL认为还是可以用索引。
MySQL5.6之后做的优化：index condition pushdown，优化了回表数量级

mysq5.6以前,基于左侧列对600万张回表筛选23岁数据,速度比较慢
mysq5.6以后,基于联合索引左侧列a筛选“张"再去筛选“23岁”,再讲符
合条件的id回表提取,回表数量大幅度减少
这种新特性称为" index condition pushdown”

几种调优方式：

增加多种不同规格索引提高索引选择性(5~6组)
空间换时间,定时任务增加时报、日报、约报等中间结果
边缘运算数据压缩:物联网惯用伎俩
4硬件调优:增大 innodb buffer pool多利用内存,减少硬盘回表

解释：
2.每一个小时每一分钟去做计算，做汇总，而不是全量汇总，这样数据量就小很多了
3.边缘运算：比如几百万的基站给服务器去每秒上传数据，那么服务器的压力肯定是很大的，如果过往一个小时内数据没有任何异常，则可以用一个表达式把一个小时的数据状态记录压缩成一条记录，实现数据的压缩，再向上上报一次，压力大大降低
4.从硬件角度优化，增大内存！

mysql用了索引为什么还是查询很慢？相关推荐

mysql join on 索引_连接查询,表关联查询join on，索引,触发器,视图
一.连接查询 1.统计每一个部门的人数 "部门名,部门的人数" select department,count(eid) from employee group by depar ...
mysql查询是否走索引_探索MySQL是否走索引(一)——范围查询一定走索引吗？
首先,准备4个版本的数据库,5.5/5.6/5.7/8.0 然后,每个库中有一模一样的表,数据量一样,建立的索引一样,InnoDB引擎. 先看一看,各个版本中,索引统计信息(Cardinality代表 ...
mysql数值比中文检索快_MySQL 千万级数据量根据（索引）优化查询速度
一.索引的作用索引通俗来讲就相当于书的目录,当我们根据条件查询的时候,没有索引,便需要全表扫描,数据量少还可以,一旦数据量超过百万甚至千万,一条查询sql执行往往需要几十秒甚至更多,5秒以上就已经让 ...
mysql添加临时索引_mysql 中添加索引的三种方法
在mysql中有多种索引,有普通索引,全文索引,唯一索引,多列索引,小伙伴们可以通过不同的应用场景来进行索引的新建,在此列出三种新建索引的方法 mysql 中添加索引的三种方法 1.1 新建表中添加索 ...
10 mysql选错索引
10 mysql选错索引在mysql表中可以支持多个索引,有的sql不指定使用哪个索引,由mysql自己来决定,但是有时候mysql选错了索引,导致执行很慢. 例子 CREATE TABLE `t1 ...
mysql 强制使用索引 FORCE INDEX(idx_name)
mysql 在查询时如果查询语句中犹豫某些原因未使用到索引,导致查询很慢,可以强制使用索引. 如 EXPLAIN SELECT cr.id FROM car_record cr LEFT JOIN ...
高性能Mysql——创建高性能索引详解
索引(在MySQL中也叫做"键(key)")是存储引擎用于快速找到记录的一种数据结构.这是索引的基本功能,除此之外,本章还将讨论索引其他一些方面有用的属性. 索引对于良好的性能非常 ...
mysql 中添加索引的三种方法
在mysql中有多种索引,有普通索引,全文索引,唯一索引,多列索引,小伙伴们可以通过不同的应用场景来进行索引的新建,在此列出三种新建索引的方法 mysql 中添加索引的三种方法 1.1 新建表中添加索 ...
MySQL Sending data导致查询很慢的问题详细分析
这两天帮忙定位一个MySQL查询很慢的问题,定位过程综合各种方法.理论.工具,很有代表性,分享给大家作为新年礼物:) [问题现象] 使用sphinx支持倒排索引,但sphinx从mysql查询源数据的 ...

mysql用了索引为什么还是查询很慢？

前言