‘壹’ 2020-10-11：一条sql语句执行时间过长，应该如何优化从哪些方面进行优化
改进数据库sql语句进行优化的理由 应用程序之优化通常可分为两个方面：源代码之优化和sql语句之优化。源代码之优化在时间成本和风险上代价很高；另一方面，源代码之优化对数据库系统性能之提升收效有限。 优化之理由 1)sql语句是对数据库(数据)进行操作之惟一途径； 2)sql语句消耗了70%~90%之数据库资源； 3)sql语句独立于程序设计逻辑，相对于对程序源代码之优化，对sql语句之优化在时间成本和风险上之代价都很低； 4)sql语句可以有不同之写法； 5)sql语句易学，难精通。 优化技术之发展 第一代之sql优化工具是执行计划分析工具。这类之工具对输入之sql语句从数据库提取执行计划，并解释执行计划中关键字之含义；第二代之sql优化工具只能提供增加索引之建议，它通过对输入之sql语句之执行计划之分析来产生是否要增加索引之建议。该类工具存在着致命之缺点——只分析了一条sql语句就得出增加某个索引之结论，根本不理会(实际上也无法评估到)增加之索引对整体数据库系统性能之影响。其破坏性在于： 1、不理会增加之索引对其他增、删、改sql语句之负面影响； 2、没有考虑增加之索引可能导致数据库判断失误； 3、对由于增加索引引起之数据库系统负担忽略不计。 同时，这些工具由于技术水平之限制存在着以下缺点： 1、无法保证建议或改写之正确性； 2、无法进行重写，仅仅提供了建议或有限程度之改写，重写工作还是需要人工完成，优化工作所需之时间和工作量同人工进行优化差不多； 3、改写之规则和hints有限，难以处理复杂之sql语句； 4、必须人手逐条进行测试。 这类工具曾经盛极一时，直到人工智能自动sql优化之出现。
‘贰’ 从哪些方面，sql语句性能如何分析
一段SQL代码写好以后，可以通过查看SQL的执行计划，初步预测该SQL在运行时的性能好坏，尤其是在发现某个SQL语句的效率较差时，我们可以通过查看执行计划，分析出该SQL代码的问题所在。
1、 打开熟悉的查看工具：PL/SQL Developer。
在PL/SQL Developer中写好一段SQL代码后，按F5，PL/SQL Developer会自动打开执行计划窗口，显示该SQL的执行计划。
2、 查看总COST，获得资源耗费的总体印象
一般而言，执行计划第一行所对应的COST(即成本耗费)值，反应了运行这段SQL的总体估计成本，单看这个总成本没有实际意义，但可以拿它与相同逻辑不同执行计划的SQL的总体COST进行比较，通常COST低的执行计划要好一些。
3、 按照从左至右，从上至下的方法，了解执行计划的执行步骤
执行计划按照层次逐步缩进，从左至右看，缩进最多的那一步，最先执行，如果缩进量相同，则按照从上而下的方法判断执行顺序，可粗略认为上面的步骤优先执行。每一个执行步骤都有对应的COST,可从单步COST的高低，以及单步的估计结果集（对应ROWS/基数），来分析表的访问方式，连接顺序以及连接方式是否合理。
4、 分析表的访问方式
表的访问方式主要是两种：全表扫描（TABLE ACCESS FULL）和索引扫描(INDEX SCAN)，如果表上存在选择性很好的索引，却走了全表扫描，而且是大表的全表扫描，就说明表的访问方式可能存在问题；若大表上没有合适的索引而走了全表扫描，就需要分析能否建立索引，或者是否能选择更合适的表连接方式和连接顺序以提高效率。
5、 分析表的连接方式和连接顺序
表的连接顺序：就是以哪张表作为驱动表来连接其他表的先后访问顺序。
表的连接方式：简单来讲，就是两个表获得满足条件的数据时的连接过程。主要有三种表连接方式，嵌套循环（NESTED LOOPS）、哈希连接（HASH JOIN）和排序-合并连接（SORT MERGE JOIN）。我们常见得是嵌套循环和哈希连接。
嵌套循环：最适用也是最简单的连接方式。类似于用两层循环处理两个游标，外层游标称作驱动表，Oracle检索驱动表的数据，一条一条的代入内层游标，查找满足WHERE条件的所有数据，因此内层游标表中可用索引的选择性越好，嵌套循环连接的性能就越高。
哈希连接：先将驱动表的数据按照条件字段以散列的方式放入内存，然后在内存中匹配满足条件的行。哈希连接需要有合适的内存，而且必须在CBO优化模式下，连接两表的WHERE条件有等号的情况下才可以使用。哈希连接在表的数据量较大，表中没有合适的索引可用时比嵌套循环的效率要高。
‘叁’ 数据库的性能优化有哪些
在数据库优化上有两个主要方面：
安全：数据可持续性。
性能：数据的高性能访问。
优化的范围有哪些
存储、主机和操作系统方面：
主机架构稳定性
I/O 规划及配置
Swap 交换分区
OS 内核参数和网络问题
应用程序方面：
应用程序稳定性
SQL 语句性能
串行访问资源
性能欠佳会话管理
这个应用适不适合用 MySQL
数据库优化方面：
内存
数据库结构(物理&逻辑)
实例配置
说明：不管是设计系统、定位问题还是优化，都可以按照这个顺序执行。
数据库优化维度有如下四个：
硬件
系统配置
数据库表结构
SQL 及索引
优化选择：
优化成本：硬件>系统配置>数据库表结构>SQL 及索引。
优化效果：硬件<系统配置<数据库表结构
‘肆’ sql语句性能如何优化
如何加快查询速度?
1、升级硬件
2、根据查询条件,建立索引,优化索引、优化访问方式，限制结果集的数据量。
3、扩大服务器的内存
4、增加服务器CPU个数
5、对于大的数据库不要设置数据库自动增长，它会降低服务器的性能
6、在查询Select语句中用Where字句限制返回的行数,避免表扫描,如果返回不必要的数据，浪费了服务器的I/O资源，加重了网络的负担降低性能。如果表很大，在表扫描的期间将表锁住，禁止其他的联接访问表,后果严重。
7、查询时不要返回不需要的行、列
8、用select
top
100
/
10
Percent
来限制用户返回的行数或者SET
ROWCOUNT来限制操作的行
9、在IN后面值的列表中，将出现最频繁的值放在最前面，出现得最少的放在最后面，减少判断的次数
10、一般在GROUP
BY
个HAVING字句之前就能剔除多余的行，所以尽量不要用它们来做剔除行的工作。他们的执行顺序应该如下最优：
select的Where字句选择所有合适的行，Group
By用来分组个统计行，Having字句用来剔除多余的分组。这样Group
By
个Having的开销小，查询快.对于大的数据行进行分组和Having十分消耗资源。如果Group
BY的目的不包括计算，只是分组，那么用Distinct更快
11、一次更新多条记录比分多次更新每次一条快,就是说批处理好
‘伍’ 如何对数据库性能进行优化
1.数据库I/O方面硬件性能
最有可能影响性能的是磁盘和网络吞吐量。解决办法：
扩大虚拟内存，并保证有足够可以扩充的空间
把数据库服务器上的不必要服务关闭掉
把SQL数据库服务器的吞吐量调为最大
若对该表的查询频率比较高，则建立索引。
分区（如MySQL，按时间分区）
尽量使用固定长度字段和限制字段长度（如 varchar(10)）优势：
降低物理存储空间
提高数据库处理速度
附带校验数据库是否合法功能优化sql语句，减少比较次数
限制返回条目数(mysql中使用limit)
尽可能的少创造对象
合理摆正系统设计的位置。大量数据操作，和少量数据操作一定是分开的。
合理利用内存，有的数据要缓存。让数据流起来，而不是全部读到内存再处理，而是边读取边处理。
2.调整数据库
3.使用存储过程
应用程序的实现过程中，能够采用存储过程实现的对数据库的操作尽量通过存储过程来实现。
因为存储过程是存放在数据库服务器上的一次性被设计、编码、测试，并被再次使用，需要执行该任务的应用可以简单地执行存储过程，并且只返回结果集或者数值。
这样不仅可以使程序模块化，同时提高响应速度，减少网络流量，并且通过输入参数接受输入，使得在应用中完成逻辑的一致性实现。
4.SQL语句方面
建立查询条件索引仅仅是提高速度的前提条件，响应速度的提高还依赖于对索引的使用。不良的SQL往往来自于不恰当的索引设计、不充份的连接条件和不可优化的where子句。
5.Java方面
‘陆’ SQL优化的几个方面
① 为查询缓存优化查询
② EXPLAIN 我们的SELECT查询(可以查看执行的行数)
③ 当只要一行数据时使用LIMIT 1
④ 为搜索字段建立索引
⑤ 在Join表的时候使用相当类型的列，并将其索引
⑥ 千万不要 ORDER BY RAND ()
⑦ 避免SELECT *
⑧ 永远为每张表设置一个ID
⑨ 可以使用ENUM 而不要VARCHAR
⑩ 尽可能的使用NOT NULL
⑪ 固定长度的表会更快
⑫ 垂直分割
⑬ 拆分打的DELETE或INSERT语句
⑭ 越小的列会越快
⑮ 选择正确的存储引擎
⑯ 小心 "永久链接"
‘柒’ 一条sql执行过长的时间，你如何优化，从哪些方面
1、查看sql是否涉及多表的联表或者子查询，如果有，看是否能进行业务拆分，相关字段冗余或者合并成临时表（业务和算法的优化）
2、涉及链表的查询，是否能进行分表查询，单表查询之后的结果进行字段整合
3、如果以上两种都不能操作，非要链表查询，那么考虑对相对应的查询条件做索引。加快查询速度
4、针对数量大的表进行历史表分离（如交易流水表）
5、数据库主从分离，读写分离，降低读写针对同一表同时的压力，至于主从同步，mysql有自带的binlog实现 主从同步
6、explain分析sql语句，查看执行计划，分析索引是否用上，分析扫描行数等等
7、查看mysql执行日志，看看是否有其他方面的问题
个人理解：从根本上来说，查询慢是占用mysql内存比较多，那么可以从这方面去酌手考虑
‘捌’ sql调优的几种方式
你好，
SQL优化的一些方法
1.对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。
2.应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描。
3.应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。
4.应尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描。
5.in 和 not in 也要慎用，否则会导致全表扫描，
6.下面的查询也将导致全表扫描：
select id from t where name like '%abc%'
7.应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。
8.应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。
9.不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。
10.在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致。
‘玖’ 请简述项目中优化sql语句执行效率的方法,从哪些方面,sql语句性能如何分析
1. SQL优化的原则是：将一次操作需要读取的BLOCK数减到最低,即在最短的时间达到最大的数据吞吐量。
调整不良SQL通常可以从以下几点切入：
? 检查不良的SQL，考虑其写法是否还有可优化内容
? 检查子查询 考虑SQL子查询是否可以用简单连接的方式进行重新书写
? 检查优化索引的使用
? 考虑数据库的优化器
2. 避免出现SELECT * FROM table 语句，要明确查出的字段。
3. 在一个SQL语句中，如果一个where条件过滤的数据库记录越多，定位越准确，则该where条件越应该前移。
4. 查询时尽可能使用索引覆盖。即对SELECT的字段建立复合索引，这样查询时只进行索引扫描，不读取数据块。
5. 在判断有无符合条件的记录时建议不要用SELECT COUNT （*）和select top 1 语句。
6. 使用内层限定原则，在拼写SQL语句时，将查询条件分解、分类，并尽量在SQL语句的最里层进行限定，以减少数据的处理量。
7. 应绝对避免在order by子句中使用表达式。
8. 如果需要从关联表读数据，关联的表一般不要超过7个。
9. 小心使用 IN 和 OR，需要注意In集合中的数据量。建议集合中的数据不超过200个。
10. <> 用 < 、 > 代替，>用>=代替，<用<=代替，这样可以有效的利用索引。
11. 在查询时尽量减少对多余数据的读取包括多余的列与多余的行。
12. 对于复合索引要注意，例如在建立复合索引时列的顺序是F1，F2，F3，则在where或order by子句中这些字段出现的顺序要与建立索引时的字段顺序一致，且必须包含第一列。只能是F1或F1，F2或F1，F2，F3。否则不会用到该索引。
13. 多表关联查询时，写法必须遵循以下原则，这样做有利于建立索引，提高查询效率。格式如下select sum（table1.je） from table1 table1, table2 table2, table3 table3 where (table1的等值条件（=）) and (table1的非等值条件) and (table2与table1的关联条件) and (table2的等值条件) and (table2的非等值条件) and (table3与table2的关联条件) and (table3的等值条件) and (table3的非等值条件)。
注:关于多表查询时from 后面表的出现顺序对效率的影响还有待研究。
14. 子查询问题。对于能用连接方式或者视图方式实现的功能，不要用子查询。例如：select name from customer where customer_id in ( select customer_id from order where money>1000)。应该用如下语句代替：select name from customer inner join order on customer.customer_id=order.customer_id where order.money>100。
15. 在WHERE 子句中，避免对列的四则运算，特别是where 条件的左边，严禁使用运算与函数对列进行处理。比如有些地方 substring 可以用like代替。
16. 如果在语句中有not in（in）操作，应考虑用not exists（exists）来重写,最好的办法是使用外连接实现。
17. 对一个业务过程的处理，应该使事物的开始与结束之间的时间间隔越短越好，原则上做到数据库的读操作在前面完成，数据库写操作在后面完成，避免交叉。
18. 请小心不要对过多的列使用列函数和order by,group by等，谨慎使用disti软件开发t。
19. 用union all 代替 union，数据库执行union操作，首先先分别执行union两端的查询，将其放在临时表中，然后在对其进行排序，过滤重复的记录。
当已知的业务逻辑决定query A和query B中不会有重复记录时，应该用union all代替union，以提高查询效率。
‘拾’ 如何进行SQL性能优化
这里分享下mysql优化的几种方法。
1、首先在打开的软件中，需要分别为每一个表创建 InnoDB FILE的文件。
