1. 复杂慢sql语句如何优化
很简单啊，优先索引，第二结构，第三算法。
索引最简单，如果是SQL server客户端或者toad可以提示有哪些需要进行优化的地方。
结构就是针对要查询的值，尽量集中到一个表，减少串表，函数查询，左链的表字段查询。
算法就是OR还是IN？串表时IN还是EXISTS ？oracle in 的限制。条件执行顺序等。
然后还有其他注意的，例如只查固定字段就不要 select * 只要注意以上步骤，千万级数据串10个秒也能1秒内显示出来。
有条件的话，当然是用归档数据进行查询，这样就不会占用业务数据IO了，最后一步就是“云计算”（解析有一百种，没有统一概念，我的意识其实就是归档过程中根据分组维度计算好，并根据日期放进相关的表，减少表粒度，只进行简单的select查询）
2. 有一个慢sql想知道哪个方法用到了
不知道你用的什么工具。如果是PLSQL的话
在PL/SQL Developer中写好一段SQL代码，按F5，或者点击“执行执行计划”图标，PL/SQL Developer会自动打开执行计划窗口，显示该SQL的执行计划。
可以看到窗口上方是sql语句，下方显示执行计划表格。表格的列主要包含描述、用户、对象、成本花费、IO开销等，表格，当然表格列还可以自定义。表格的行包含了查询逻辑的执行顺序和各个步骤信息。
3. 如何解决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 查询的优化，添加更合适的索引可以避免性能问题：执行计划使用索引并不意味着就能执行快。
4. 如何优化MySQL中查询慢的SQL语句啊
MySQL查询优化的5个好用方法
http://soft.chinabyte.com/database/254/11335754.shtml
原则上来说
在
FIND_IN_SET
typeid IN (35)
arcrank
加复合索引
在sortrank加索引
5. 如何优化慢查询的SQL语句
优化方法一般从几个方面这几个考虑：
1、根据业务情况，精简代码逻辑，
2、根据读写方式，降低数据表读写量
3、关键条件列增加合适的索引
4、对于碎片多的索引进行重建
多数情况下只需要考虑前两条就能解决很大的效率问题，业务模式可能在最初开发的时候，因需求分析不彻底，或者需求理解不深入，导致逻辑不合理，或者后续多次变动业务模式，新增功能与最初的开发理念发生变化，这时就应该对代码的逻辑进行重新优化改写。
6. sql语句查询很慢,如何解决
日期列 有索引吗？
储值卡明细 表 的列： 住院号
住院_安排医生 的 列： 住院号
都有索引吗？
没有的话，加上
7. SQL语句执行太慢，怎么优化
Try this:
select storage.prodcode, sum(case when billsale.prod_number is null then 0 else billsale.prod_number end) as '已销售数量'
from storage left join billsale on billsale.prodcode=storage.prodcode
group by storage.prodcode
8. 如何在mysql查找效率慢的SQL语句
查看慢SQL是否启用，查看命令：show variables like 'log_slow_queries';
如果结果为ON则是开启了，如果为OFF则表示禁用了。
开启慢查询命令：set global log_slow_queries = on;
查看是否开启：show variables like 'log_slow_queries';
查看慢查询参数，即设置超过多少秒的查询归为了慢查询。参数为：long_query_time，查询命令：showglobal variables like 'long_query_time';
mysql默认时间为10秒，即10秒及以上的查询被归为了慢查询。我们的实际项目中根本就不可能这么包容你，所以得提供查询效率优化sql，让程序更快的执行。
这里设置时间为1秒，即超过1秒就会被认为慢查询。设置命令：set global long_query_time =1;用命令设置的，会立即生效，不用重启mysql服务。但重启mysql服务后就会失效。
查看设置的时间，show global variables like 'long_query_time';即可看到现在已经变为1秒了
查看慢查询存放日志，命令：show variables like 'slow_query_log_file';
去相应目录下查看即可。