sql调优《二》

1.数据库设计(是否复合范式,是否合理归档、分区、分表等)

2.硬件基础架构 (设备规格,硬件性能,负载均衡,容灾等)

3.ql语句的写法、索引和统计信息,事务和锁,应用程序访问代码(连接过多、频繁开关等)]

1、 字段的设计

字段是数据库最基本的单位,其设计对性能的影响是很大的。需要注意如下:

A、数据类型尽量用数字型,数字型的比较比字符型的快很多。

B、 数据类型尽量小,这里的尽量小是指在满足可以预见的未来需求的前提下的。

C、 尽量不要允许NULL,除非必要,可以用NOT NULL+DEFAULT代替。

D、少用TEXT和IMAGE,二进制字段的读写是比较慢的,而且,读取的方法也不多,大部分情况下最好不用。

E、 自增字段要慎用,不利于数据迁移。

索引的设计

在设计阶段,可以根据功能和性能的需求进行初步的索引设计,这里需要根据预计的数据量和查询来设计索引,可能与将来实际使用的时候会有所区别。

2、关于索引的选择,应改主意:

A、 根据数据量决定哪些表需要增加索引,数据量小的可以只有主键。

B、根据使用频率决定哪些字段需要建立索引,选择经常作为连接条件、筛选条件、聚合查询、排序的字段作为索引的候选字段。

C、把经常一起出现的字段组合在一起,组成组合索引,组合索引的字段顺序与主键一样,也需要把最常用的字段放在前面,把重复率低的字段放在前面。

D、一个表不要加太多索引,因为索引影响插入和更新的速度。

F、不要对索引字段进行运算,而要想办法做变换

G、不要对索引字段进行格式转换

H、不要对索引字段使用函数

I、不要对索引字段进行多字段连接

3、 只返回需要的数据

返回数据到客户端至少需要数据库提取数据、网络传输数据、客户端接收数据以及客户端处理数据等环节,如果返回不需要的数据,就会增加服务器、网络和客户端的无效劳动,其害处是显而易见的,避免这类事件需要注意:

A、横向来看,不要写SELECT *的语句,而是选择你需要的字段。

B、 纵向来看,合理写WHERE子句,不要写没有WHERE的SQL语句。

C、 注意SELECT INTO后的WHERE子句,因为SELECT INTO把数据插入到临时表,这个过程会锁定一些系统表,如果这个WHERE子句返回的数据过多或者速度太慢,会造成系统表长期锁定,诸塞其他进程。

D、对于聚合查询,可以用HAVING子句进一步限定返回的行。

4、尽量少做重复的工作

A、 控制同一语句的多次执行,特别是一些基础数据的多次执行是很多程序员很少注意的。

B、 减少多次的数据转换,也许需要数据转换是设计的问题,但是减少次数是程序员可以做到的。

C、杜绝不必要的子查询和连接表,子查询在执行计划一般解释成外连接,多余的连接表带来额外的开销。

D、 合并对同一表同一条件的多次UPDATE

E、 UPDATE操作不要拆成DELETE操作+INSERT操作的形式,虽然功能相同,但是性能差别是很大的。

F、 不要写一些没有意义的查询

5、 注意事务和锁

事务是数据库应用中和重要的工具,它有原子性、一致性、隔离性、持久性这四个属性,很多操作我们都需要利用事务来保证数据的正确性。在使用事务中我们需要做到尽量避免死锁、尽量减少阻塞。具体以下方面需要特别注意:

A、事务操作过程要尽量小,能拆分的事务要拆分开来。

B、 事务操作过程不应该有交互,因为交互等待的时候,事务并未结束,可能锁定了很多资源。

C、 事务操作过程要按同一顺序访问对象。

D、提高事务中每个语句的效率,利用索引和其他方法提高每个语句的效率可以有效地减少整个事务的执行时间。

E、 尽量不要指定锁类型和索引,SQL SERVER允许我们自己指定语句使用的锁类型和索引,但是一般情况下,SQL SERVER优化器选择的锁类
型和索引是在当前数据量和查询条件下是最优的,我们指定的可能只是在目前情况下更有,但是数据量和数据分布在将来是会变化的。

F、 查询时可以用较低的隔离级别,特别是报表查询的时候,可以选择最低的隔离级别(未提交读)。

6、 注意临时表和表变量的用法

在复杂系统中,临时表和表变量很难避免,关于临时表和表变量的用法,需要注意:

A、如果语句很复杂,连接太多,可以考虑用临时表和表变量分步完成。

B、 如果需要多次用到一个大表的同一部分数据,考虑用临时表和表变量暂存这部分数据。

C、 如果需要综合多个表的数据,形成一个结果,可以考虑用临时表和表变量分步汇总这多个表的数据。

D、其他情况下,应该控制临时表和表变量的使用。

E、 关于临时表和表变量的选择,很多说法是表变量在内存,速度快,应该首选表变量,但是在实际使用中发现,这个选择主要考虑需要放在临时表的数据量,在数据量较多的情况下,临时表的速度反而更快。

F、 关于临时表产生使用SELECT INTO和CREATE TABLE + INSERT INTO的选择

7、 注意连接条件的写法

多表连接的连接条件对索引的选择有着重要的意义,所以我们在写连接条件条件的时候需要特别的注意。

A、多表连接的时候,连接条件必须写全,宁可重复,不要缺漏。

B、 连接条件尽量使用聚集索引

C、 注意ON部分条件和WHERE部分条件的区别

时间: 2024-10-27 17:30:18

sql调优《二》的相关文章

SQL调优日志--内存问题

SQL调优日志--内存问题排查入门篇 概述 很多系统的性能问题,是由内存导致的.内存不够会导致页面频繁换入换出,IO队列高,进而影响数据库整体性能. 排查 内存对数据库性能非常重要.那么我当出现问题的时候,我们怎么排查性能问题呢? 存在问题 主要查看2个部分.页生命周期 Page Life Expectancy,和  lazy writer /sec. 页生命周期 的参考值在很久很久以前,很多同学可能看到过,建议值是300s.但是这是基于32位操作系统,最大只能使用4GB内存给出的. Jonat

SQL调优

# 问题的提出 在应用系统开发初期,由于开发数据库数据比较少,对于查询SQL语句,复杂视图的的编写等体会不出SQL语句各种写法的性能优劣,但是如果将应用 系统提交实际应用后,随着数据库中数据的增加,系统的响应速度就成为目前系统需要解决的最主要的问题之一.系统优化中一个很重要的方面就是SQL语句的优 化.对于海量数据,劣质SQL语句和优质SQL语句之间的速度差别可以达到上百倍,可见对于一个系统不是简单地能实现其功能就可,而是要写出高质量的 SQL语句,提高系统的可用性. 在多数情况下,Oracle

Oracle SQL 调优健康检查脚本

Oracle SQL 调优健康检查脚本 我们关注数据库系统的性能,进行数据库调优的主要工作就是进行SQL的优化.良好的数据架构设计.配合应用系统中间件和写一手漂亮的SQL,是未来系统上线后不出现致命性能问题的有力保证. 在CBO时代,一个SQL的执行计划是多样的.影响执行计划的因素也从过去RBO时代的SQL书写规则变为综合性因素.这为我们生成更加优秀执行计划提供了基础,同时也给我们进行调优带来的很多麻烦. 目前我们通常的做法,是通过AWR报告或者调试手段,发现某某SQL有问题,之后从Librar

11g新特性-自动sql调优(Automatic SQL Tuning)

11g新特性-自动sql调优(Automatic SQL Tuning) 在Oracle 10g中,引进了自动sql调优特性.此外,ADDM也会监控捕获高负载的sql语句. 在Oracle 11g中,通过运行sql tuning advisor加强了自动sql调优功能.默认情况下是每天夜间通过自动任务的方式运行"自动sql调优". 自动sql调优的过程: 1.识别需要调优的sql语句  根据AWR中的CPU和I/O负载来识别 2.调优,生成新的sql profile 在维护窗口(mai

SQL调优常用方法

在使用DBMS时经常对系统的性能有非常高的要求:不能占用过多的系统内存和 CPU资源.要尽可能快的完成的数据库操作.要有尽可能高的系统吞吐量.如果系统开发出来不能满足要求的所有性能指标,则必须对系统进行调整,这个工作被称为调优.绝定DBMS的性能的因素有两个因素:硬件和软件.使用频率高的CPU.使用多处理器.加大内存容量.增加Cache.提高网络速度等这些都是非常有效的硬件调优方式,不过对硬件进行调优对系统性能的提高是有限的,如果有非常好的硬件条件但是如果编写的SQL质量非常差的话系统的性能并不

数据库学习——SQL调优

一.SQL调优与查询优化器 数据库性能调优一般从发现.分析和解决SQL语句执行中的问题着手,这个过程统称为SQL调优(SQL tuning). 1.了解查询优化器 例如,有些查询优化器对于连接操作,一般按连接对象在FROM子句中出现的先后次序进行连接.SQL程序设计者可以利用此特点将选择性高的小表放在前面,大表放在后面,以尽快淘汰无用的中间结果,从而节省查询处理开销.又如,有些查询优化器中,凡是查询条件用OR连接的,就一概不用索引,因而只能用全表扫描,可以考虑使用UNION ALL代替OR. 2

oracle sql调优集

************************************************************ 1.新建调优集对象 ************************************************************ ---授权 grant ADMINISTER ANY SQL TUNING SET to scott; ---删除存在的STS BEGIN DBMS_SQLTUNE.DROP_SQLSET( sqlset_name => 'OCPYAN

初次使用SQL调优建议工具--SQL Tuning Advisor

在10g中,Oracle推出了自己的SQL优化辅助工具: SQL优化器(SQL Tuning Advisor :STA),它是新的DBMS_SQLTUNE包. 使用STA一定要保证优化器是CBO模式下.可是我觉得使用这样的工具,仅适合全然不懂SQL的调优的人群,不要觉得工具能解决好问题. SQL说究竟是表达的是一个业务,工具怎么可能理解业务.SQL调优还是要用autotrace,10046,10053,display_cursor这些优秀的工具做诊断.然后依据业务和所具备的oracle基础的知识

Oracle技术沙龙《SQL调优-从手工到工业化》

 无dba 不调优 没有学过oracle能调优吗? 告诉你  YES I DO AWR出来好几年了,有关它的作用真正理解的有多少?ADDM能干啥?试一试就知道了! Oracle 10a 的出现,DBA会失业吗? SQL优化从传统模式进入工业化,你了解得有多少? SQL Tuning Advisor能够做哪些优化? SQL Access Advisor能够做哪些优化? 本次技术沙龙以上内容一锅端,使用真实的案例来一一的演绎SQL调优的乐趣 特邀讲师陈卫星:从2010至今,已经在Oracle总部做过

基于SQLServer2008的SQL调优(转)

1. 前言 SQL是程序设计人员与数据库进行沟通的标准语言,在数据库应用程序中,使用最多的访问数据库的方法就是SQL语言.SQL性能的调整涉及到SQLServer 2008的方方面面,优化器的选择.内存参数的设定.SQL语句的写法等.本文主要从SQL语句的优化方面进行阐述,给出了一些可行的调整数据库应用性能的策略与方法,并以SQLServer 2008为平台对列举规则给予了验证. 2. 实验环境 硬件环境:Inter(R) Core(TM)2 Duo CPU P7450 @2.12GHz .2G