㈠ sql语句多表联查，查询速度太慢，超过10s，由于是菜鸟，不知道怎样优化
确定是菜鸟，sql 写成这样 证明你逻辑很清楚啊，建议如果是初学者，代码规范一定要保持
不知道代码规范，可以去窗口format一下。。。
言归正传 你这个优化的话 可以把
AND p.mediatypeinfoid in (
select
id
from
fn_get_mediatype_infor(5)
)
上面这部分 换成 inner join
㈡ 最近我的数据库(sql)查询速度很慢，这是什么原因
查询慢是和表结构，语句，系统等相关的建索引等方法都可以改善表结构，另外如果返回数据量很大，当然会慢，所以你尽量查询相对有用的数据再就是查询语句了比如用in查询没有jion查询快，还有
between
改成
>
<会快再还有，用子查询也会慢很多，如果是一些很复杂的查询，可以改用存储过程会好点，有时用临时表会慢但，从海量数据中查询取数进行子查询又不如用临时表快，不同的问题用不同的解决方法，看你要哪种了，单看你的问题无法直接判断。不过，优化查询句是关键的了。
㈢ mysql多表连接查询很慢，有更好的解决方案吗
设备运行数据表才千万级，说明实时数据量应该不会太大，为什么不再建立一个实时数据表（当然如果有需要，这个表你也可以按区域之类的分表），表中就三字段，比如就设备ID，区域ID（这以两个为唯一索引）和当前最大monitor_value，然后在设备运行数据表中建立触发器，当插入新数据时就去更新那个实时数据表（或者说如果设备ID区域ID没出现就新建，如果有并且数据比那个还大就更新）
㈣ 如何解决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 查询的优化，添加更合适的索引可以避免性能问题：执行计划使用索引并不意味着就能执行快。
㈤ mysql 联表查询 巨慢
问题
我们有一个 SQL，用于找到没有主键 / 唯一键的表，但是在 MySQL 5.7 上运行特别慢，怎么办?
实验
我们搭建一个 MySQL 5.7 的环境，此处省略搭建步骤。
写个简单的脚本，制造一批带主键和不带主键的表：
可以看到执行时间变成了 0.67s。
整理
我们诊断的关键点如下：
1. 对于 information_schema 中的元数据表，执行计划不能提供有效信息。
2. 通过查看 MySQL 改写后的 SQL，我们猜测了优化器发生了误判。
3. 我们增加了 hint，指导 MySQL 正确进行优化判断。
但目前我们的实验仅限于猜测，猜中了万事大吉，猜不中就无法做出好的诊断。
㈥ MySQL多表联合查询很慢
根据需要建立索引，根据情况更改链接的匹配模式，把全表扫描得低效率扫描改为高效率的索引扫描，主要索引一般是根据查询条件来创建
㈦ 如何解决SQL Server查询速度缓慢的问题
SQL Server查询速度慢的原因有很多，常见的有以下几种：
1、没有索引或者没有用到索引(这是查询慢最常见的问题，是程序设计的缺陷)
2、I/O吞吐量小，形成了瓶颈效应。
3、没有创建计算列导致查询不优化。
4、内存不足
5、网络速度慢
6、查询出的数据量过大(可以采用多次查询，其他的方法降低数据量)
7、锁或者死锁(这也是查询慢最常见的问题，是程序设计的缺陷)
8、sp_lock,sp_who，活动的用户查看，原因是读写竞争资源。
9、返回了不必要的行和列
10、查询语句不好，没有优化
㈧ mysql 多表连接查询速度超级慢
问题
我们有一个 SQL，用于找到没有主键 / 唯一键的表，但是在 MySQL 5.7 上运行特别慢，怎么办？
实验
我们搭建一个 MySQL 5.7 的环境，此处省略搭建步骤。
写个简单的脚本，制造一批带主键和不带主键的表：
可以看到执行时间变成了 0.67s。
整理
我们诊断的关键点如下：
1. 对于 information_schema 中的元数据表，执行计划不能提供有效信息。
2. 通过查看 MySQL 改写后的 SQL，我们猜测了优化器发生了误判。
3. 我们增加了 hint，指导 MySQL 正确进行优化判断。
但目前我们的实验仅限于猜测，猜中了万事大吉，猜不中就无法做出好的诊断。
㈨ sql语句查询速度慢
可以分时操作呀，你把一部分数据融合之后做成视图或者把你的SQL语句写成存储过程。在条件里面尽量少使用“<>”不等于，或者not in,其实这也是告诉你不仅仅从数据结构的方面考虑问题哦
㈩ mysql 多表关联查询慢怎么处理
一般查询性能是从表结构优化、索引优化、服务器参数优化三个方面着手。
1、表结构优化：能用数值型的字段就避免用字符型，能用字符型就不要用TEXT型，能确定字段值长度的就尽量指定长度；
2、索引优化：通过Explain查看SQL语句性能，需要创建索引的就建索引；
3、服务器参数优化：需要调整内存值、缓存值等的就调整。