如果mysql里面的数据过多，查询太慢怎么办

问题

我们有一个 SQL，用于找到没有主键 / 唯一键的表，但是在 MySQL 57 上运行特别慢，怎么办？

实验

我们搭建一个 MySQL 57 的环境，此处省略搭建步骤。

写个简单的脚本，制造一批带主键和不带主键的表：

执行一下脚本：

现在执行以下 SQL 看看效果：

执行了 1680s，感觉是非常慢了。

现在用一下 DBA 三板斧，看看执行计划：

感觉有点惨，由于 information_schemacolumns 是元数据表，没有必要的统计信息。

那我们来 show warnings 看看 MySQL 改写后的 SQL：

我们格式化一下 SQL：

可以看到 MySQL 将

select from A where Ax not in (select x from B) //非关联子查询

转换成了

select from A where not exists (select 1 from B where Bx = ax) //关联子查询

如果我们自己是 MySQL，在执行非关联子查询时，可以使用很简单的策略：

select from A where Ax not in (select x from B where ) //非关联子查询:1 扫描 B 表中的所有记录，找到满足条件的记录，存放在临时表 C 中，建好索引2 扫描 A 表中的记录，与临时表 C 中的记录进行比对，直接在索引里比对，

而关联子查询就需要循环迭代：

select from A where not exists (select 1 from B where Bx = ax and ) //关联子查询扫描 A 表的每一条记录 rA：     扫描 B 表，找到其中的第一条满足 rA 条件的记录。

显然，关联子查询的扫描成本会高于非关联子查询。

我们希望 MySQL 能先"缓存"子查询的结果（缓存这一步叫物化，MATERIALIZATION），但MySQL 认为不缓存更快，我们就需要给予 MySQL 一定指导。

可以看到执行时间变成了 067s。

整理

我们诊断的关键点如下：

\1 对于 information_schema 中的元数据表，执行计划不能提供有效信息。

\2 通过查看 MySQL 改写后的 SQL，我们猜测了优化器发生了误判。

\3 我们增加了 hint，指导 MySQL 正确进行优化判断。

但目前我们的实验仅限于猜测，猜中了万事大吉，猜不中就无法做出好的诊断。

1 执行计划中明明有使用到索引，为什么执行还是这么慢？

2 执行计划中显示扫描行数为 644，为什么 slow log 中显示 100 多万行？

a 我们先看执行计划，选择的索引 “INDX_BIOM_ELOCK_TASK3(TASK_ID)”。结合 sql 来看，因为有 "ORDER BY TASK_ID DESC" 子句，排序通常很慢，如果使用了文件排序性能会更差，优化器选择这个索引避免了排序。

那为什么不选 possible_keys:INDX_BIOM_ELOCK_TASK 呢？原因也很简单，TASK_DATE 字段区分度太低了，走这个索引需要扫描的行数很大，而且还要进行额外的排序，优化器综合判断代价更大，所以就不选这个索引了。不过如果我们强制选择这个索引（用 force index 语法），会看到 SQL 执行速度更快少于 10s，那是因为优化器基于代价的原则并不等价于执行速度的快慢；

b 再看执行计划中的 type:index，"index" 代表 “全索引扫描”，其实和全表扫描差不多，只是扫描的时候是按照索引次序进行而不是行，主要优点就是避免了排序，但是开销仍然非常大。

Extra:Using where 也意味着扫描完索引后还需要回表进行筛选。一般来说，得保证 type 至少达到 range 级别，最好能达到 ref。

在第 2 点中提到的“慢日志记录Rows_examined: 1161559，看起来是全表扫描”，这里更正为“全索引扫描”，扫描行数确实等于表的行数；

c 关于执行计划中：“rows：644”，其实这个只是估算值，并不准确，我们分析慢 SQL 时判断准确的扫描行数应该以 slow log 中的 Rows_examined 为准。

4 优化建议：添加组合索引 IDX_REL_DEVID_TASK_ID(REL_DEVID,TASK_ID)

优化过程：

TASK_DATE 字段存在索引，但是选择度很低，优化器不会走这个索引，建议后续可以删除这个索引：

select count(),count(distinct TASK_DATE) from T_BIOMA_ELOCK_TASK;+------------+---------------------------+| count() | count(distinct TASK_DATE) |+------------+---------------------------+| 1161559 | 223 |+------------+---------------------------+

在这个 sql 中 REL_DEVID 字段从命名上看选择度较高，通过下面 sql 来检验确实如此：

select count(),count(distinct REL_DEVID) from T_BIOMA_ELOCK_TASK;+----------+---------------------------+| count() | count(distinct REL_DEVID) |+----------+---------------------------+| 1161559 | 62235 |+----------+---------------------------+

由于有排序，所以得把 task_id 也加入到新建的索引中，REL_DEVID,task_id 组合选择度 100%：

select count(),count(distinct REL_DEVID,task_id) from T_BIOMA_ELOCK_TASK;+----------+-----------------------------------+| count() | count(distinct REL_DEVID,task_id) |+----------+-----------------------------------+| 1161559 | 1161559 |+----------+-----------------------------------+

在测试环境添加 REL_DEVID，TASK_ID 组合索引，测试 sql 性能：alter table T_BIOMA_ELOCK_TASK add index idx_REL_DEVID_TASK_ID(REL_DEVID,TASK_ID);

添加索引后执行计划：

这里还要注意一点“隐式转换”：REL_DEVID 字段数据类型为 varchar，需要在 sql 中加引号：AND TREL_DEVID = 000000025xxx >> AND TREL_DEVID = '000000025xxx'

执行时间从 10s+ 降到 毫秒级别：

1 row in set (000 sec)

结论

一个典型的 order by 查询的优化，添加更合适的索引可以避免性能问题：执行计划使用索引并不意味着就能执行快。

在安装有SQLServer数据库的计算机上，我们在使用数据库的过程中，有时候会在任务管理器里发现sqlservrexe这个进程的内存和CPU占用率较高。

接下来我们来看一下，如何解决上面这个问题，需要设置SQLServer数据库的内存配置。登录数据库，这里使用的是SQLServer2008,右键点击最上方的服务器名，在d出的菜单中，点击属性

打开服务器属性窗口。默认显示的是第一项常规内容，点击第二项内存进行内存配置。

点击内存后，打开服务器内存选项配置界面。这里的使用AWE分配内存可以对内存进行扩展支持，我们要做的是更改下方的最大服务器内存。这个数值根据自己服务器内存大小来做适当设置。

5

个人建议设置本机内存的一半或稍微高一点，如机器内存为2G，那么我们这里填写1000。需要注意的是内存设置调小以后，在数据库执行较复杂SQL语句的时候，可能会比较慢，出现这种情况，我们再适当上调最大内存配置大小。

以上就是关于如果mysql里面的数据过多，查询太慢怎么办全部的内容，包括:如果mysql里面的数据过多，查询太慢怎么办、如何解决SQL查询速度太慢、sql server数据库查询慢怎么优化等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！