1. 一条查询极为缓慢的sql语句，如何去优化呢
1、将查询条件字段简历index;
2、将尽可能筛选掉最大数据量的条件放到where条件最后面，因为sql执行时，where条件是由右往左执行。
3、尽可能少用like、in等函数
2. 如何进行SQL性能优化
这里分享下mysql优化的几种方法。
1、首先在打开的软件中，需要分别为每一个表创建 InnoDB FILE的文件。
3. 慢sql治理
什么是慢sql？慢sql的定义，目前共识是rt>1S，当存在1s以上的sql，qps比较高（150）时候，大概率会发生线上问题
风险维度：
执行时间rt：执行时间超过1s
平均扫描行数:扫描行数过高则一般说明sql有优化空间
全表扫描：一般是由于没有配置索引
平均返回行数：返回行数过高，对系统逻辑有一定的风险
索引覆盖：当前sql不是最佳索引
索引知识：
查看表索引：show index from table_name
查看sql语句影响行数：explain select * from user where phone=‘xxx’
索引错用：
1.类型隐士转换
wrong： select * from user where phone=xxx
right： select * from user where phone=‘xxx’
2.索引字段使用函数或者运算
wrong： select * from user where Date(create_at)=‘2019-12-12’
right：select * from user where create_at>‘2019-12-12’ AND create_at<'2019-12-13'
3.谨慎使用OR，OR中只要有一个没有索引，就会走全表扫描
select name from user where id=10 and sex=‘男’，sex没有索引，导致走全表
4.Like 正确使用，like ‘%xxx’ |like ‘%xxx%’，会让索引失效，但可以使用like‘xx%’
5.不应该使用select *，而是需要什么查什么
select name from user，当name有索引的时候，直接扫描索引，不需要再扫表，索引覆盖
6.谨慎使用order by导致的内存排序
7.当搜索范围很大时，mysql估计使用全表扫描要比索引快，则不适用索引
4. SQL数据库优化的方法有哪些
在进行软件开发过程中，数据库的使用是非常重要的，但是数据库有很多种，不同数据库的使用方法是不同的。进行软件开发过程中，至少需要掌握一种数据库的使用方法。SQL数据库语法简单、操作方便和高效，是很多人最优的选择，但是SQL语句会受到不同数据库功能的影响，在计算时间和语言的效率上面需要进行优化，根据实际情况进行调整。下面电脑培训为大家介绍SQL数据库的优化方法。
一、适当的索引
索引基本上是一种数据结构，有助于加速整个数据检索过程。唯一索引是创建不重叠的数据列的索引。正确的索引可以更快地访问数据库，但是索引太多或没有索引会导致错误的结果。IT培训认为如果没有索引，处理速度会变得非常慢。
二、仅索引相关数据
指定需要检索数据的精度。使用命令*和LIMIT代替SELECT*。调整数据库时，必须使用所需的数据集而不是整个数据集，尤其是当数据源非常大时，指定所需的数据集，能够节省大部分时间。
三、根据需求使用或避免临时表
如果代码可以用简单的方式编写，那么永远不要使临时表变得复杂。当然，如果数据具有需要多个查询的特定程序，北大青鸟建议在这种情况下，使用临时表。临时表通常由子查询交替。
四、避免编码循环
避免编码循环是非常重要的，因为它会减慢整个序列的速度。通过使用具有单行的唯一UPDATE或INSERT命令来避免编码循环，并且昆明北大青鸟发现WHERE命令能够确保存储的数据不被更新，这样能够方便在找到匹配和预先存在的数据时被找到。
5. 如何解决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 查询的优化，添加更合适的索引可以避免性能问题：执行计划使用索引并不意味着就能执行快。
6. 查询特别慢 如何优化SQL
思路：
首先，要确定使用的是什么数据，
若是MSSQL，那么需要看一下查询计划，然后逐一解决慢的问题；
若是Access，那么就要看表的索引创建是否合适，另外Access还有一个弊病，就是数据库大于10MB后，速度和性能将极大的下降
7. SQL优化之慢查询
慢查询，顾名思义，就是查询慢的sql语句，是指mysql记录所有执行超过long_query_time参数设定的时间阈值的SQL语句的日志。该日志能为SQL语句的优化带来很好的帮助。默认情况下，慢查询日志是关闭的，要使用慢查询日志功能，首先要开启慢查询日志功能。
配置了慢查询后，它会记录符合条件的SQL，包括：
通过下面命令查看下上面的配置：
设置完成后，通过 show VARIABLES like 'datadir'来查看数据文件存放的位置。日志文件中的内容格式如下：
linux系统在mysql的bin目录下执行
参数说明：
这个工具安装起来比较复杂，非专业sql人员感觉没必要玩~
8. 如何优化慢查询的SQL语句
优化方法一般从几个方面这几个考虑：
1、根据业务情况，精简代码逻辑，
2、根据读写方式，降低数据表读写量
3、关键条件列增加合适的索引
4、对于碎片多的索引进行重建
多数情况下只需要考虑前两条就能解决很大的效率问题，业务模式可能在最初开发的时候，因需求分析不彻底，或者需求理解不深入，导致逻辑不合理，或者后续多次变动业务模式，新增功能与最初的开发理念发生变化，这时就应该对代码的逻辑进行重新优化改写。
9. SQL语句执行起来真的很慢，请大家帮忙优化一下
先建立索引，索引名随便起：
CREATE INDEX index_name ON COPTD(TD004);
CREATE INDEX index_name ON MOCTB(TD004);
CREATE INDEX index_name ON MOCTA(TD004);
insert into ZDIDAN(DD01,DD02,DD03) SELECT distinct TD004,SUM(TD08),'O' FROM COPTD,MOCTA,MOCTB where COPTD.TD004=MOCTA.TD004 and MOCTB.TD004=MOCTA.TD004 and COPTD.TD021 = 'Y' AND COPTD.TD016 = 'N' AND COPTD.TD008+COPTD.TD024-COPTD.TD009-COPTD.TD025 > 0 and TB001+TB002=TA001+TA002 and TA013='Y' AND TA011 < 'Y' AND TB004>TB005 GROUP BY COPTD.TD004;
10. 复杂慢sql语句如何优化
很简单啊，优先索引，第二结构，第三算法。
索引最简单，如果是SQL server客户端或者toad可以提示有哪些需要进行优化的地方。
结构就是针对要查询的值，尽量集中到一个表，减少串表，函数查询，左链的表字段查询。
算法就是OR还是IN？串表时IN还是EXISTS ？oracle in 的限制。条件执行顺序等。
然后还有其他注意的，例如只查固定字段就不要 select * 只要注意以上步骤，千万级数据串10个秒也能1秒内显示出来。
有条件的话，当然是用归档数据进行查询，这样就不会占用业务数据IO了，最后一步就是“云计算”（解析有一百种，没有统一概念，我的意识其实就是归档过程中根据分组维度计算好，并根据日期放进相关的表，减少表粒度，只进行简单的select查询）