sql慢查询

⑴ 如何解决sql查询速度太慢

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 T.REL_DEVID = 000000025xxx >> AND T.REL_DEVID = '000000025xxx'

执行时间从 10s+ 降到 毫秒级别：
1 row in set (0.00 sec)
结论
一个典型的 order by 查询的优化，添加更合适的索引可以避免性能问题：执行计划使用索引并不意味着就能执行快。

⑵ 如何解决SQL Server查询速度缓慢的问题

你先看看绑定的时候代码有问题没。
然后注意取数据最好用存储过程，不仅快还好维护。分页查询百万级的数据我觉得不一定要用。
数据库的索引建立，以及旧数据归档也就是很有效地提高性能的方法。

⑶ MySQL怎么查询比较耗时的sql语句

一、MySQL数据库有几个配置选项可以帮助我们及时捕获低效SQL语句

1，slow_query_log
这个参数设置为ON，可以捕获执行时间超过一定数值的SQL语句。

2，long_query_time
当SQL语句执行时间超过此数值时，就会被记录到日志中，建议设置为1或者更短。

3，slow_query_log_file
记录日志的文件名。

4，log_queries_not_using_indexes
这个参数设置为ON，可以捕获到所

⑷ 如何查找MySQL中查询慢的SQL语句

你是指慢查询日志吗？
在my.ini中加上下面两句话
log-slow-queries = e:\mysql5.5\mysql_slow_query.log
long_query_time=10

前面一句是设置慢查询日志存放路径，第二句是指多少秒以上算慢查询，上面的语句，就是指10秒。然后show variables like '%slow%';就行了

⑸ sql查询 数据时，查询缓慢，无法查出情况

这个问题我也遇见过，慢的话也正常，因为数据比较多
解决办法啊，首先从表考虑，可以针对这个表建索引，
然后的话说优化查询语句，可以的话添加 with (nolock);即select * from A with (nolock) 这样
然后就是where条件了，尽量不要使用like,in这些。尽量添加where条件。
这样应该可以了，还不行的话，上网查查怎么优化DB。

⑹ SQL子查询过多查询速度太慢如何优化

先行转列行不行呢，以第一张表为例
select proctguid,
max(case when num=1 then description end) tz1,
max(case when num=2 then description end) tz2,
max(case when num=3 then description end) tz3,
max(case when num=4 then description end) tz4,
max(case when num=5 then description end) tz5
from proct_description
group by proctguid
然后再join，用proctguid和原表关联，这样上面就只需要写
select p.*,tz1,tz2,tz3,tz4,tz5 from 了

⑺ MYSQL慢查询里有一个SQL语句超慢，请求解决思路

严重影响性能时，不建议用*，这个*相当于一个函数，在实际的查询过程中是会先去根据表结构转换成具体的字段名的，这里是会消耗性能的。
想要查看具体脚本的性能可以去查看SQL的执行计划，分析性能主要耗在哪里，针对性优化。

希望能帮到你……

⑻ 求助 SQL 查询太慢

C表临时生成还大，然后再去查询一定会减慢速度，而且几乎没有能走索引或者其他条件的通道（一堆左右链接decode）。
语句优化几乎做不了什么，试试看查询结构优化吧，比如C建立为物化视图或者一张表等等，语句这块做不了什么了。

⑼ 如何优化慢查询的SQL语句

优化方法一般从几个方面这几个考虑：
1、根据业务情况，精简代码逻辑，
2、根据读写方式，降低数据表读写量
3、关键条件列增加合适的索引
4、对于碎片多的索引进行重建
多数情况下只需要考虑前两条就能解决很大的效率问题，业务模式可能在最初开发的时候，因需求分析不彻底，或者需求理解不深入，导致逻辑不合理，或者后续多次变动业务模式，新增功能与最初的开发理念发生变化，这时就应该对代码的逻辑进行重新优化改写。

⑽ sql语句查询很慢,如何解决

日期列 有索引吗？
储值卡明细 表 的列： 住院号
住院_安排医生 的 列： 住院号

都有索引吗？

没有的话，加上