① sql优化万能公式：5 大步骤 + 10 个案例
在应用开发的早期，数据量少，开发人员开发功能时更重视功能上的实现，随着生产数据的增长，很多SQL语句开始暴露出性能问题，对生产的影响也越来越大，有时可能这些有问题的SQL就是整个系统性能的瓶颈。
1、通过慢查日志等定位那些执行效率较低的SQL语句
2、explain 分析SQL的执行计划
type由上至下，效率越来越高
Extra
3、show profile 分析
了解SQL执行的线程的状态及消耗的时间。默认是关闭的，开启语句“set profiling = 1;”
4、trace
trace分析优化器如何选择执行计划，通过trace文件能够进一步了解为什么优惠券选择A执行计划而不选择B执行计划。
5、确定问题并采用相应的措施
案例1、最左匹配
索引
SQL语句
查询匹配从左往右匹配，要使用order_no走索引，必须查询条件携带shop_id或者索引( shop_id , order_no )调换前后顺序
案例2、隐式转换
索引
SQL语句
隐式转换相当于在索引上做运算，会让索引失效。mobile是字符类型，使用了数字，应该使用字符串匹配，否则MySQL会用到隐式替换，导致索引失效。
案例3、大分页
索引
SQL语句
对于大分页的场景，可以优先让产品优化需求，如果没有优化的，有如下两种优化方式， 一种是把上一次的最后一条数据，也即上面的c传过来，然后做“c < xxx”处理，但是这种一般需要改接口协议，并不一定可行。另一种是采用延迟关联的方式进行处理，减少SQL回表，但是要记得索引需要完全覆盖才有效果，SQL改动如下
案例4、in + order by
索引
SQL语句
in查询在MySQL底层是通过n*m的方式去搜索，类似union，但是效率比union高。in查询在进行cost代价计算时（代价 = 元组数 * IO平均值），是通过将in包含的数值，一条条去查询获取元组数的，因此这个计算过程会比较的慢，所以MySQL设置了个临界值(eq_range_index_pe_limit)，5.6之后超过这个临界值后该列的cost就不参与计算了。因此会导致执行计划选择不准确。默认是200，即in条件超过了200个数据，会导致in的代价计算存在问题，可能会导致Mysql选择的索引不准确。
处理方式，可以( order_status , created_at )互换前后顺序，并且调整SQL为延迟关联。
案例5、范围查询阻断，后续字段不能走索引
索引
SQL语句
范围查询还有“IN、between”
案例6、不等于、不包含不能用到索引的快速搜索。（可以用到ICP）
在索引上，避免使用NOT、!=、>、!、NOT EXISTS、NOT IN、NOT LIKE等
案例7、优化器选择不使用索引的情况
如果要求访问的数据量很小，则优化器还是会选择辅助索引，但是当访问的数据占整个表中数据的蛮大一部分时（一般是20%左右），优化器会选择通过聚集索引来查找数据。
查询出所有未支付的订单，一般这种订单是很少的，即使建了索引，也没法使用索引。
案例8、复杂查询
如果是统计某些数据，可能改用数仓进行解决；如果是业务上就有那么复杂的查询，可能就不建议继续走SQL了，而是采用其他的方式进行解决，比如使用ES等进行解决。
案例9、asc和desc混用
desc 和asc混用时会导致索引失效
案例10、大数据
对于推送业务的数据存储，可能数据量会很大，如果在方案的选择上，最终选择存储在MySQL上，并且做7天等有效期的保存。那么需要注意，频繁的清理数据，会照成数据碎片，需要联系DBA进行数据碎片处理。
② 通过分析SQL语句的执行计划优化SQL
如何干预执行计划
-
-
使用hints提示
基于代价的优化器是很聪明的，在绝大多数情况下它会选择正确的优化器，减轻了DBA的负担。但有时它也聪明反被聪明误，选择了很差的执行计划，使某个语句的执行变得奇慢无比。此时就需要DBA进行人为的干预，告诉优化器使用我们指定的存取路径或连接类型生成执行计划，从而使语句高效的运行。例如，如果我们认为对于一个特定的语句，执行全表扫描要比执行索引扫描更有效，则我们就可以指示优化器使用全表扫描。在Oracle中，是通过为语句添加hints(提示)来实现干预优化器优化的目的。
hints是oracle提供的一种机制，用来告诉优化器按照我们的告诉它的方式生成执行计划。我们可以用hints来实现：
1.
使用的优化器的类型
2.基于代价的优化器的优化目标，是all_rows还是first_rows。
3.
表的访问路径，是全表扫描，还是索引扫描，还是直接利用rowid。
4.
表之间的连接类型
5.
表之间的连接顺序
6.
语句的并行程度
除了”RULE”提示外，一旦使用的别的提示，语句就会自动的改为使用CBO优化器，此时如果你的数据字典中没有统计数据，就会使用缺省的统计数据。所以建议大家如果使用CBO或HINTS提示，则最好对表和索引进行定期的分析。
如何使用hints:
Hints只应用在它们所在sql语句块(statement
block，由select、update、delete关键字标识)上，对其它SQL语句或语句的其它部分没有影响。如：对于使用union操作的2个sql语句，如果只在一个sql语句上有hints，则该hints不会影响另一个sql语句。
我们可以使用注释(comment)来为一个语句添加hints，一个语句块只能有一个注释，而且注释只能放在SELECT,
UPDATE,
or
DELETE关键字的后面
使用hints的语法：
{DELETE|INSERT|SELECT|UPDATE}
/*+
hint
[text]
[hint[text]]...
*/
or
{DELETE|INSERT|SELECT|UPDATE}
--+
hint
[text]
[hint[text]]...
注解：
1.DELETE、INSERT、SELECT和UPDATE是标识一个语句块开始的关键字，包含提示的注释只能出现在这些关键字的后面，否则提示无效。
2.“+”号表示该注释是一个hints，该加号必须立即跟在”/*”的后面，中间不能有空格。
3.hint是下面介绍的具体提示之一，如果包含多个提示，则每个提示之间需要用一个或多个空格隔开。
4.text
是其它说明hint的注释性文本
如果你没有正确的指定hints，Oracle将忽略该hints，并且不会给出任何错误。
③ 【基于ORACLE数据库的SQL语句优化分析】 数据库查询语句的优化
【摘要】随着数据库应用范围及规模的不断扩大，数据库的性能问题逐渐显现，优化数据库有助于维持系统的稳定性以及运行的高效性。本文主要依据笔者在实际工作中的精坦敏拍英，对SQL语句优化的目的、SQL语句优化技术及原则进行全面分析和阐述。
【关键词】ORACLE数据库；SQL语句；优化
1前言
随着现代化信息技术的迅猛发展，互联网应用的日益普及，数据库技术的影响力越来越大。作为信息系统管理的核心，数据库的主要操作就是查询，数据库的应用效率在很大程度上是由查询速度决定的，特别是对于规模较大的数据库而言，查询速度十分关键。查询速度在SQL语句中占有很大比重，所以，通过对查询语句进行优化有助于促进应用系统性能及效率的进一步提升。
2SQL语句优化分析
2.1SQL语句优化的目的
对于一个数据库而言，在确保设计无误的前提下，要想避免出现性能问题必须确保其拥有合理的SQL语句拿唤结构。最简单的数据库寻找数据路径是对SQL语句进行调整，ORACLE数据库性能提升的主要途径就是对SQL语句进行适当的调整。从本质上讲，SQL语句优化就是确保所使用的语句可以被优化器识别，对索引进行有效利用以便控制表扫描的I/O次数，有效防止出现表搜索。用高性能的SQL语句替代低性能的SQL语句，确定最佳的数据查找路径，尽可能使CPU时间与I/O时间保持平衡是进行优化的主要目的。在对SQL语句进行优化的过程中，以系统需求为依据确定最有可能实现性能提升的语句并进行优化。
2.2SQL语句优化技术及原则
当数据量积累到一定程度之后，对于数据库全表SQL语句进行一次扫描，若查询策略较好，一般只用几秒钟，但如果SQL语句性能较低，就需要用几分钟甚至更多时间。从这点不难看出，SQL语句性能对于查询速度具有极大的影响，所以，对于应用系统而言，不仅能满足功能的实现，还要保证SQL语句的质量。
（1）采取适宜的索引。为达到优化查询的目的，一项重要工作就是确定相适应的索引，并严格依照原则加以使用，与此同时，为有效控制I/O竞争，不可以在同一个磁盘中同时建立索引和用户表空间。
语句1：SELECT CUS_NO, CUS_NAME FROM CUSTOMER WHERE CUS_NO NOT IN
(SELECT CUS_NO FROM SERVICE);
语句2： SELECT CUS_NO, CUS_NAME FROM CUSTOMER WHERE NOT EXISTS
(SELECT * FROM SERVICE WHERE SERVICE.CUS_NO=CUSTOMER.CUS_NO);
上述两个语句可以达到一致的查询结果，对二者进行对比，当执行语句1时，由于ORACLE未利用CUSTOMER 表上CUS_NO索引，所以就会扫描整表，在执行语句2的过让羡程中，ORACLE所扫描的只是CUSTOMER 表子查询中的联合查询，并且使用了CUS_NO索引，因此，在执行效率方面明显优于前者。
（2）避免在SELECT子句中出现“*”。ORACLE在进行解析时，需要按照一定顺序对“*”进行转换，该项转换工作的进行需要对数据库的数据字典进行查询，势必需要花费较多的时间，这样就会导致较低的效率，所以，要避免在SELECT子句中出现“*”。
（3）如果必要可以利用COMMIT提交事务。ORACLE能够自动提交DDL语句，而诸如DML等类型的语句的提交则是通过手动方式或者回滚事务实现的。在编写应用程序的过程中，在操作诸如insert、delete以及update 等较为复杂的语境的时候，利用COMMIT提交事务可以讲会话中持有的锁加以释放，将存在于缓存中的未经修改的数据块进行清除，进而将系统资源予以释放，促进系统性能的进一步提升，因此，如果有必要，可以利用COMMIT对相关事务进行提交。
（4）联合查询连接顺序的确定。如果查询操作涉及到多个表，基础表应当是交叉表，所谓交叉表具体是指被其他表引用的表。连接执行效果在很大程度上受到FROM语句中表的顺序的影响，对于FROM中所包含的表，ORACLE解析器进行处理的顺序是由右至左，SQL语句中所选择的基础表会因优化器的不同而有所区别，在使用CBO的情况下，优化器会对SQL语句中各个表的物理大小以及索引状态进行检查，在此基础上确定一个花费最小的执行路径；在使用RBO的情况下，如果全部的连接条件均有索引与之相对应，那么，FROM子句中位置最后面的表就是基础表。
（5）IN用EXISTS取代。在对数个基础表查询过程中，一般需要进行表的连接。因为利用IN的子查询过程中，ORACLE的扫描对象是全表，因此，出于提高查询效率目的的考虑，应当将IN用EXISTS取代。
（6）在索引列中不使用计算。当通过对函数进行引用在WHERE子句中进行计算的时候，假如索引列只是函数的一部分，优化器就会针对全表进行扫描，而不会使用索引，所以，在索引列中不能使用函数。
3结语
综上所述，随着现代化信息技术的迅猛发展，互联网应用的日益普及，数据库技术的影响力越来越大。在信息量迅速激增的形势下，数据库优化调整成为当前所面临的一大关键性问题，特别是对规模较大的数据库而言，及时进行优化的意义更加倍重大。对于数据库的运行性能而言，最主要的影响因素主要体现在以下几点：数据库系统架构的设计是否合理，资源配置是否科学以及SQL语句编写效率等。笔者从事的是电信企业的运营分析工作，每天都要从数据库取各种数据，可以说是离不开数据库，所以在实践中，我觉得严格遵守SQL语句优化原则及方法，并在实践中及时总结经验教训，可以实现对系统响应时间的有效控制，促进运行效率的提升。
参考文献
[1] 许开宇,胡文骅. 如何提高ORACLE数据库应用程序的性能[J]. 计算机应用与软件. 2002(10)
[2] 郑耀,吴建岚. 基于Oracle数据库的语句优化策略[J]. 信息与电脑(理论版). 2011(07)
[3] 高攀,施蔚然. 基于Oracle数据库的SQL语句优化[J]. 电脑编程技巧与维护. 2010(22)
[4] 钟小权,叶猛. Oracle数据库的SQL语句优化[J]. 计算机与现代化. 2011(03)
作者简介：
王勇军，男，（1981.1-），吉林通化人，就职于中国联合网络通信有限公司长春市分公司，通信工程师，本科，研究方向：SQL使用
（作者单位：中国联合网络通信有限公司长春市分公司）
④ 高手详解SQL性能优化十条经验
查询的模糊匹配
尽量避免在一个复杂查询里面使用 LIKE %parm % —— 红色标识位置的百分号会导致相关列的索引无法使用 最好不要用
解决办法:
其实只需要对该脚本略做改进 查询速度便会提高近百倍 改进方法如下
a 修改前台程序——把查询条件的供应商名称一栏由原来的文本输入改为下拉列表 用户模糊输入供拿禅旁应商名称时 直接在前台就帮忙定位到具体的供应商 这样在调用后台程序时 这列就可以直接用等于来关联了
b 直接修改后台——根据输入条件 先查出符合条件的供应商 并把相关记录保存在一个临时表里头 然后再用临时表去做复杂关联
索引问题
在做性能跟踪分析过程中 经常发现有不少后台程序的性能问题是因为缺少合适索引造成的 有些表甚至一个索引都没有 这种情况往往都是因为在设计表时 没去定义索引 而开发初期 由于表记录很少 索引创建与否 可能对性能没啥影响 开发人员因此也未多加重视 然一旦程序发布到生产环境 随着时间的推移 表记录越来越多
这时缺少索引 对性能的影响便会越来越大了
这个问题需要数据库设计人员和开发人员共消橡同关注
法则 不要在建立的索引的数据列上进行下列操作:
◆避免对索引字段进行计算操作◆避免在索引字段上使用not <> !=◆避免在索引列上使用IS NULL和IS NOT NULL ◆避免在索引列上出现数据类型转换◆避免在索引字段上使用函数 ◆避免建立索引的列中使用空值
复杂操作
部分UPDATE SELECT 语句 写得很复杂（经常嵌套多级子查询）——可以考虑适当拆成几步 先生成一些临时数据表 再进行关联操作
update
同一个表的修改在一个过程里出现好几十次 如
update table set col = where col = ;update table set col = where col =象这类脚本其实可以很简单就整合在一个UPDATE语句来完成（前些时候在协助xxx项目做性能问题分析时就发现存在这种情况）
在可以使用UNION ALL的语句里 使用了UNION
UNION 因为会将各查询子集的记录做比较 故比起UNION ALL 通常速度都会慢上许多 一般来说 如果使用UNION ALL能满足要求的话 务必使用UNION ALL 还有一种情况大家可能会忽略掉 就是虽然要求几个子集的并集需要过滤掉重复记录 但由于脚本的特殊性 不可能存在重复记录 这时便应该使用UNION ALL 如xx模块的某个查询程序就曾经存在这种情况 见 由于语句的特殊性 在这个脚本中几个子集的记录绝对不可能重复 故可以改用UNION ALL）
在WHERE 语句中 尽量避免对索引字段进行计算操作
这个常识相信绝大部分开发人员都应该知道 但仍有不少人这么使用 我想其中一个最主要的原因可能是为了编写写简单而损害了性能 那就不可取了
月份在对XX系统做性能分析时发现 有大量的后台程序存在类似用法 如
where trunc(create_date)=trunc(:date )虽然已对create_date 字段建了索引 但由于加了TRUNC 使得索引无法用上 此处正确的写法应该是
where create_date>=trunc(:date ) and create_date或者是
where create_date beeen trunc(:date ) and trunc(:date )+ /( * * )注意 因beeen 的范围是个闭区间（greater than or equal to low value and less than or equal to high value ） 故严格意义上应该再减去一个趋于 的小数 这里暂且设置成减去 秒（ /( * * )） 如果不要求这么精确的话 可以袭凳略掉这步
对Where 语句的法则
避免在WHERE子句中使用in not in or 或者having
可以使用 exist 和not exist代替 in和not in
可以使用表链接代替 exist Having可以用where代替 如果无法代替可以分两步处理
例子
SELECT * FROM ORDERS WHERE CUSTOMER_NAME NOT IN (SELECT CUSTOMER_NAME FROM CUSTOMER) 优化 SELECT * FROM ORDERS WHERE CUSTOMER_NAME not exist (SELECT CUSTOMER_NAME FROM CUSTOMER)不要以字符格式声明数字 要以数字格式声明字符值 （日期同样）否则会使索引无效 产生全表扫描 例子使用 SELECT emp ename emp job FROM emp WHERE emp empno = ;不要使用 SELECT emp ename emp job FROM emp WHERE emp empno =
对Select语句的法则
在应用程序 包和过程中限制使用select * from table这种方式 看下面例子
使用SELECT empno ename category FROM emp WHERE empno = 而不要使用SELECT * FROM emp WHERE empno =
排序
避免使用耗费资源的操作 带有DISTINCT UNION MINUS INTERSECT ORDER BY的SQL语句会启动SQL引擎 执行 耗费资源的排序(SORT)功能 DISTINCT需要一次排序操作 而其他的至少需要执行两次排序
临时表
lishixin/Article/program/SQL/201311/16379
⑤ 请简述项目中优化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的文件。
⑦ 一条sql执行过长的时间，你如何优化，从哪些方面
1、查看sql是否涉及多表的联表或者子查询，如果有，看是否能进行业务拆分，相关字段冗余或者合并成临时表（业务和算法的优化）
2、涉及链表的查询，是否能进行分表查询，单表查询之后的结果进行字段整合
3、如果以上两种都不能操作，非要链表查询，那么考虑对相对应的查询条件做索引。加快查询速度
4、针对数量大的表进行历史表分离（如交易流水表）
5、数据库主从分离，读写分离，降低读写针对同一表同时的压力，至于主从同步，mysql有自带的binlog实现 主从同步
6、explain分析sql语句，查看执行计划，分析索引是否用上，分析扫描行数等等
7、查看mysql执行日志，看看是否有其他方面的问题
个人理解：从根本上来说，查询慢是占用mysql内存比较多，那么可以从这方面去酌手考虑
⑧ sql优化的几种方法 如何优化
sql优化的方法是：设计数据库表结构时，物枝岁要对表做数量级和性能影响预测和评估，表的字段尽量都设置default值; sql条件中允许出现库函数和左模糊查询;单个事务的sql语句数量要有上限要求，不能前台一个提交操作，后台要去插入几十张表的数据等。
sql优化的几种方法
1、设计数据库表结构时，要对表做数量级和性能影响预测和评估，表的字段尽量都设置default值，尽量避免default为null，主要防止在执行sql查询时直接将查询条件设置为null或者not null而导致数据库放弃索引，直接全表扫描;
2、sql条件中允许出现库函数和左模糊查询，sql条件中库函搭念数会导致数据库执行时放弃索引，直接全表扫描，而左模糊也是，直接就全表扫描了;
3、原则上，sql条件中避免出现<>，in，not in，exists，not exists等操作符;
4、子查询中的实际查询结果要设置上限要求，且子查询必须要有索引支持，否则子查询也去扫描全表就悲剧了;
5、单个事务的sql语句数量要有上限要求，不能前台一个提交操作，后台要去插入几十张表的数据，那如果是千万级用户数，基本上就光去插入数据了;
6、同上一条类似，单条sql语句的数据影响量也要有上限要求，不能一个update操作更新了上千条数据;
7、尽量减少多表关联的sql，如果必须使用多表关联，也尽量减少关联的表数量，且多表关联时，关联字段必须包含在查询索引中。多表关联sql中尽量不要使用视图和代理表;
8、充分利用索引，严禁出现表扫描。同时，创建表时也注意索引的字段顺序。
sql语言具有什么功能
1、sql数据定义功能：能够定义数据库的三级模式结构，即外模式、全局模式和内模式结构。在sql中，外模式有叫做视图(View)，全局模式简称模式( Schema)，内模式由系统根据数据库模式罩睁自动实现，一般无需用户过问。
2、sql数据操纵功能：包括对基本表和视图的数据插入、删除和修改，特别是具有很强的数据查询功能。
3、sql的数据控制功能：主要是对用户的访问权限加以控制，以保证系统的安全性。