第10章数据库运行维护与优化
10.1 数据库运行维护基本工作①数据库的转储与恢复②数据库的安全性、完整性控制③检测并改善数据库的性能④数据库的重组和重构
10.2 运行状态监控与分析：管理员借助相应工具在数据库运行过程中监测数据库系统的运行情况，掌握系统当前或以往的负荷、配置、应用和其他相关信息，并对监测数据进行分析。
①自动监控机制②手动监控机制③对数据库构架体系的监控④对数据库性能的监控
10.3 数据库存储空间管理：数据库的存储结构一般分为逻辑存储结构和物理存储结构，其物理存储结构决定了数据库存储数据时数据文件所占用空间的大小及分布。不同的数据库对空间的管理是不一样的。空间不足可扩大存储容量或合理备份转储。10.4 数据库性能优化：数据库应用系统最常见的运行维护任务之一。10.4.1 数据库运行环境与参数调整
1 外部调整：①CPU：在空闲是使用率超过90%，说明服务器缺乏CPU资源；若高峰期时CPU 使用率依然很低，说明CPU资源充足。②网络：大量SQL数据会使网络速度变慢，调整网络。
2 调整内存分配
3 调整磁盘I/O：响应时间的最大组成部分。
4 调整竞争：方法
①修改参数以控制连接到数据库的最大进程数②减少调度进程的竞争
③减少多线程服务进程竞争④减少重做日志缓冲区竞争⑤减少回滚段竞争。
10.4.2 模式调整与优化1 增加派生性冗余列：指表中增加的列由表中的一些数据项经过计算生成。2 增加冗余列：是指在多个表中增加具有相同语义的列，它常用来查询时避免连接操作。3 重新组表：经常查看的某些数据是由多个表连接之后才能得到，就可考虑重新组表。
4 分割表：表分割有两种方式，水平分割和垂直分割。水平分割是根据数据行的使用特点进行分割，分割之后所得的所有表结构都相同，而存储的数据不同。增加查询复杂度，查询数据时需用Union（并）操作。垂直分割根据数据列的特点进行分割，分割之后所得的所有表中除了都含有主码列外其余列都不同。数据行变小，减少I/O次数，而且大多数据操作只在少数或者一个表中进行，提高系统性能，查询所有数据需要Jion(连接)操作。
5 新增汇总表：为了降低这些操作的时间，可以根据统计操作的使用情况，将频繁使用的统计操作的中间结果或最终结果存储在汇总表中，当用户发出汇总需求时，即可直接从汇总表中获取数据，降低了数据访问量以及汇总操作的CPU计算量。
10.4.3 存储优化1物化视图：包括一个查询结果的数据库对象，是预先计算并保存表连接或聚集等耗时较多的操作结果，提高了读取速度，还可以进行远程数据的本地复制。特别适用抽取大数据量表中某些信息以及分布式环境中跨节点进行多表数据连接的场合。
2 聚集：是物理存储表中数据的可择的方法。
10.4.4 查询优化1 合理使用索引：建立索引的目的就是为了提高查询效率。决策：①是否为一个属性建立索引②在哪些属性上建立索引③是否建立聚簇索引④使用散列索引还是树索引。使用原则：①经常在查询中作为条件被使用的列，应为其建立索引②频繁进行排序或分组的列，应为其建立索引③一个列的值域很大时，应为其建立索引④如果待排序的列有多个，应在这些列上建立复合索引⑤可以使用系统工具来检查索引的完整性，必要时进行修复。
2 避免或简化排序：避免或简化对大型表进行重复的排序。
3 消除对大型表数据的顺序存取：避免这种情况的主要方法就是对连接的列进行索引。
4 避免复杂的正则表达式
5 使用临时表加速查询：把表的一个子集进行排序并创建临时表，有时能加速查询。
6 用排序来取代非排序磁盘存取：非顺序磁盘存取是最慢的操作。
7 不充分的连接条件：左(右)连接消耗的资源非常之多。8 存储过程9 不要随意使用游标：游标会较占用多的系统资源。10 事务处理
10.4.5 SQL Server 性能工具 1 SQLServer Profiler
2 数据库引擎优化顾问：通过对数据库的工作负荷测试，由数据库引擎优化顾问给出优化建议，然后再通过管理员进行相应的修改，使数据库达到一个比较优化的状态。
小结
数据库建立并投入运行后，必须对系统的运行情况进行有效监控分析，以便在出现问题的时候对数据库进行维护和管理。本章结合数据库运行维护日常工作，简要介绍了包括监控分析、空间管理、参数调整、系统性能优化以及查询优化涉及的一些方法和技术。
龙源期刊网 https://www.doczj.com/doc/f19019718.html, 如何优化数据库，提高查询效率 作者：代鸿彬 来源：《学习与科普》2019年第10期 摘要：随着信息时代的到来，生活和工作当中已经无法避免的需要和计算机打交道，和 计算机打交道的同时就必须要用到数据库。数据库系统是计算机当中的一项重要系统，储存在用户的关键信息，不仅对个人影响很大，同时对企事业单位也有着重要影响。 关键词：信息时代；数据库；索引 数据库是信息的载体也是数据的最佳表现形式，它的共享性导致了数据会被大量的搜索查询，为了提高查询的效率，就不得不对数据库进行优化。 一、利用索引进行优化。 索引是数据库的重要组成部分，也是使用者根据需要进行查询最直接的方法，优化索引可以提高查询的效率。当前的数据库当中大部分还是使用国际商业机器公司以前的索引顺序存取方法，对于用户来说肯定会选择方便、快捷的索引方式，怎么方便怎么来。在建立索引的时候针对不同的内容，需要建立不同的连接方式，但是随着用户的增多，查询内容和方向的多元化，这就造成了在实际工作当中经常会有使用频率很少的索引出现，甚至也会出现没有查询所需的索引，这种情况可以通过查询优化器进行自动生成的索引进行查询。对于使用频率较为频繁的列，需要对其进行排序或者分组的列上建立索引时，要优化索引提高效率，对于使用频率很少的列可以不建立索引。 二、简化排序进行优化。 对于部分企事业单位需要排序的内容很多时，就要使用大型数据表来满足查询需求，但是大型数据表涉及的内容很多，为了避免出现重复排序的现象需要对数据表进行简化。在大型数据表当中有一部分的内容可以自动进行排序的次序输出，这时就可以直接利用查询优化器进行优化，将复杂的排序简单化，从而提高索引查询效率。需要排序的列对索引优化影响较大，就像语言当中的ORDER BY 或者GROUP BY句子当中的列次序和索引当中的列次序基本是不同的，但是排序的列可通过表的不同形式表现出来。通过简化排序避免了重复的排序，并且将数据库进行了合理的合并。如果不进行简化排序，就需要将排序的范围进行缩小简化，从而提高查询使用的效率。 三、大型表行数据库存取的合理消除。 数据库系统的存储量是有上限的，所有的索引内容都占有数据库空间，尤其是大型数据表占有的空间更大，将会造成索引时间变长。但是大型表行数据有些内容是不必要的，在进行索引查詢时，数据表当中的存取顺序对查询的效率有直接的影响。例如需要采用存取策略时，通
SQL SERVER性能优化综述 近期因工作需要，希望比较全面的总结下SQL SERVER数据库性能优化相关的注意事项，在 网上搜索了一下,发现很多文章,有的都列出了上百条,但是仔细看发现，有很多似是而非或 者过时(可能对SQL SERVER6.5以前的版本或者ORACLE是适用的)的信息，只好自己根据以 前的经验和测试结果进行总结了。 我始终认为，一个系统的性能的提高，不单单是试运行或者维护阶段的性能调优的任务，也不单单是开发阶段的事情，而是在整个软件生命周期都需要注意，进行有效工作才能达到的。所以我希望按照软件生命周期的不同阶段来总结数据库性能优化相关的注意事项。 一、分析阶段 一般来说，在系统分析阶段往往有太多需要关注的地方，系统各种功能性、可用性、可靠性、安全性需求往往吸引了我们大部分的注意力，但是，我们必须注意，性能是很重要的非功能 性需求，必须根据系统的特点确定其实时性需求、响应时间的需求、硬件的配置等。最好能 有各种需求的量化的指标。 另一方面，在分析阶段应该根据各种需求区分出系统的类型，大的方面，区分是OLTP（联机事务处理系统）和OLAP（联机分析处理系统）。 二、设计阶段 设计阶段可以说是以后系统性能的关键阶段，在这个阶段，有一个关系到以后几乎所有性能 调优的过程—数据库设计。 在数据库设计完成后，可以进行初步的索引设计，好的索引设计可以指导编码阶段写出高效 率的代码，为整个系统的性能打下良好的基础。 以下是性能要求设计阶段需要注意的： 1、数据库逻辑设计的规范化 数据库逻辑设计的规范化就是我们一般所说的范式，我们可以这样来简单理解范式： 第1规范：没有重复的组或多值的列，这是数据库设计的最低要求。 第2规范: 每个非关键字段必须依赖于主关键字，不能依赖于一个组合式主关键字的某些组 成部分。消除部分依赖，大部分情况下，数据库设计都应该达到第二范式。 第3规范: 一个非关键字段不能依赖于另一个非关键字段。消除传递依赖，达到第三范式应该是系统中大部分表的要求，除非一些特殊作用的表。 更高的范式要求这里就不再作介绍了，个人认为，如果全部达到第二范式，大部分达到第三
1.1、数据库及SQL代码优化方案 （1）每周检查统计信息是否及时更新。 （2）每周检查各索引是否有效。 （3）每周检查分区是否正确。 （4）每周检查执行计划是否正确。 （5）每天检查RAC和ASM是否正常运行。 （6）每天检查相关日志是否正常备份。 （7）每天检查相关文件系统和表空间的占用率是否在国家税务总局规定的阀值以下。 （8）在每月申报高峰等业务繁忙期采样并找出消耗I/O资源和CPU资源较多的SQL语句。 （9）分析上述SQL语句，与软件服务商充分沟通后，提出优化建议。 （10）在每月申报高峰期每隔15分钟检查一次数据库连接数，发现异常及时处理。 1.1.1、系统数据库索引、表分区和对象优化方案 数据库对象的优化主要包括：表、索引和sequence等对象，通过优化对象参数、调整对象属性（例如分区表、分区索引、反转索引等等）等方法来实现对数据库对象的优化改造。 1.1.1.1表和索引并行参数优化 数据库的表和索引的并行参数值的设置对相关的sql语句的执行计划会造成影响，表和索引的degree值大于1，执行计划就偏向于使用全表和全索引扫描，另外如果并行参数值过大，短时间内也会对主机和数据库的资源造成很大的压力，因此在oltp的数据库下建议将表和索引的degree值设为1。 1.1.1.2热点大表的分区改造 对访问量很大、表的记录数很多、存在热块争用的表，可以考虑对表和索引进行适当的分区改造，分散访问压力，提高数据访问的性能。 对以下表的记录数超过1000万并且记录数持续增长的大表，建议进行分区
改造（地区+时间）： 1.1.1.3分区索引的清理 对最近30天数据库分区索引访问情况进行统计，对访问次数为0的分区索引和应用部门进行确认，若确认为多余的索引，建议进行删除清理。 1.1.1.4Sequence序列优化 加大sequence 的 cache，并使用noorder选项。在RAC中经常会遇到SQ 锁等待，这是因为在RAC环境下，sequence也成为全局性的了，不同节点要生成序列号，就会产生对sequence资源的争用。而目前大多数系统中，sequence 大多数被作为主键发生器来使用，使用的频率十分高，在RAC环境中，需要设置较大的 sequence cache，否则会造成较为严重的争用，从而影响业务。 1.1.2、SQL硬解析优化方案 1.1. 2.1相关知识点介绍 1.1. 2.1.1Oracle的硬解析和软解析 Oracle对sql的处理过程：当发出一条sql语句交付Oracle，在执行和获取结果前，Oracle对此sql将进行几个步骤的处理过程： 1、语法检查(syntax check) 检查此sql的拼写是否语法。 2、语义检查(semantic check) 诸如检查sql语句中的访问对象是否存在及该用户是否具备相应的权限。 3、对sql语句进行解析(prase) 利用内部算法对sql进行解析，生成解析树(parse tree)及执行计划(execution plan)。 4、执行sql，返回结果(execute and return) 其中，软、硬解析就发生在第三个过程里。 Oracle利用内部的hash算法来取得该sql的hash值，然后在library cache
SQL 性能监控及SQL 语句优化 性能监控 作为SQL的数据库服务器，我们可以将其比作一个人，而SQL则是他的心脏，管理员就是他的大脑。要监控心脏是否健康首先要看他这个人是否健康。这两者是相辅相成的，少了一方都是不健康的。 数据库服务器的性能监视器 性能监视器 性能工具的介绍 性能监视器是一种简单而功能强大的可视化工具，用于实时收集系统状态并从日志文件中查看性能数据。 使用性能监视器可以: 获得对诊断系统问题和规划系统资源增长有用的性能数据、了解工作负载及其对系统资源的影响、观察工作负载和资源使用情况的变化和趋势，以便计划未来的升级、通过监视结果来测试配置变化、诊断问题并确定需要优化的组件或进程。 现在，可以开始选择这些对象和要监视的计数器了。 https://www.doczj.com/doc/f19019718.html, 应用程序性能计数器有关https://www.doczj.com/doc/f19019718.html, 应用程序性能计数器的大部分信息最近已被合并到一个题为“改善 .NET 应用程序的性能和伸缩性”的综合文档中。下表描述了一些可用于监视和优化 https://www.doczj.com/doc/f19019718.html, 应用程序（包括 Reporting Services）性能的重要计数器。
除了上表中介绍的这些核心监视要素之外，在您试图诊断 https://www.doczj.com/doc/f19019718.html, 应用程序具有的特定性能问题时，下表中的性能计数器也可对您有所帮助。
Reporting Services 性能计数器 Reporting Services 包括一组它自己的性能计数器，用于收集有关报告处理和资源消耗方面的信息。可通过 Windows 性能监视器工具中出现的两个对象来监视实例和组件的状态和活动：MSRS 2005 Web Service 和 MSRS 2005 Windows Service 对象。 MSRS 2005 Web Service 性能对象包括一组用来跟踪 Report Server 处理过程的计数器，这些处理过程通常通过在线交互式报告浏览操作而引发。这些计数器在https://www.doczj.com/doc/f19019718.html, 停止该 Web 服务后被重设。下表列出了可用于监视 Report Server 性能的计数器，并描述了它们的目的。 性能对象：RS Web Service
1性能优化基本步骤 1.1定位跟踪耗费资源较多的SQL语句步骤 1.1.1 通过SQL查询 (1): 查询出最耗费资源的SQL语句 select t1.SID, t1.SERIAL#, tt.HASH_VALUE, tt.ADDRESS, tt.BUFFER_GETS, --读内存次数 tt.DISK_READS, --磁盘物理读次数 tt.EXECUTIONS, --语句的执行次数 tt.BUFFER_GETS / tt.EXECUTIONS, --平均读内存次数 tt.SQL_FULLTEXT from v$sqlareatt, v$session t1 where (tt.BUFFER_GETS>100000 or tt.DISK_READS>100000) and tt.HASH_VALUE = t1.SQL_HASH_VALUE and tt.ADDRESS = t1.SQL_ADDRESS and t1.STATUS = 'ACTIVE' orderby tt.BUFFER_GETS desc (2)：根据客户端程序发出的SQL来定位需要跟踪的session select s.sid sid, s.SERIAL# "serial#", https://www.doczj.com/doc/f19019718.html,ername, s.machine, s.program, s.server, s.LOGON_TIME from v$session s 1.1.2 通过Oracle提供的SQL TRACE进行SQL跟踪 (1)：跟踪前设定相应参数 1．查询得到需要跟踪的session 2．打开时间开关
Show parameter timed_statistics alter session set timed_statistics=true; execsys.dbms_system.set_bool_param_in_session(sid => 8,serial# => 3,parnam => 'timed_statistics',bval => true); 3．设置跟踪文件存放位置 Show parameter user_dump_dest alter system set user_dump_dest='c:\temp'; (2)：启动跟踪功能并让系统运行一段时间 alter session set sql_trace=true; execsys.dbms_system.set_sql_trace_in_session(8, 3, true); (3)：关闭跟踪功能 alter session set sql_trace=false; execsys.dbms_system.set_sql_trace_in_session(8, 3, false); (4)：格式化跟踪数据文件，并分析跟踪结果文件 tkprof dsdb2_ora_18468.trc dsdb2_trace.txt EXPLAIN=SCOTT/TIGER tkprof各参数含义： ' traced_file ' 指定输入文件，即oracle产生的trace文件 'formatted_file'指定输出文件，即我们想得到的易于理解的格式化文件 'EXPLAIN' 利用哪个用户对trace文件中的sql进行分析得到该sql语句的执行计划1.2查看分析执行计划 1.2.1查看执行计划 (1)：Sqlplus中可按F5查看执行计划 (2)：使用执行计划表进行查看 使用语句将SQL语句的执行计划装入plan_table表，然后进行分析查看explainplansetstatement_id = 'dd'into plan_table for select t.type_name,t.source_value,t.standard_value from ODS_STD_COMP t,ODS_STD_COMP_BAK t1 where t.system_id = t1.system_id and t.type = t1.type and t.source_value = t1.source_value (3)：示例演示 1．让ORALCE自动选择最优的执行计划，不人为干预 explainplansetstatement_id = 'dd'into plan_table for select t.type_name,t.source_value,t.standard_value from ODS_STD_COMP t,ODS_STD_COMP_BAK t1 where t.system_id = t1.system_id and t.type = t1.type and t.source_value = t1.source_value
Sql优化方案 一．数据库优化技术 1.索引（强烈建议使用） 1.1优点 创建索引可以大大提高系统的性能。 第一，通过创建唯一性索引，可以保证数据库表中每一行数据的唯一性。 第二，可以大大加快数据的检索速度，这也是创建索引的最主要的原因。 第三，可以加速表和表之间的连接，特别是在实现数据的参考完整性方面特别有意义。 第四，在使用分组和排序子句进行数据检索时，同样可以显著减少查询中分组和排序的时间。 第五，通过使用索引，可以在查询的过程中，使用优化隐藏器，提高系统的性能。 1.2 缺点 第一，创建索引和维护索引要耗费时间，这种时间随着数据量的增加而增加。第二，索引需要占物理空间，除了数据表占数据空间之外，每一个索引还要占一定的物理空间，如果要建立聚簇索引，那么需要的空间就会更大。 第三，当对表中的数据进行增加、删除和修改的时候，索引也要动态的维护，这样就降低了数据的维护速度。 1.3 使用准则 索引是建立在数据库表中的某些列的上面。因此，在创建索引的时候，应该仔细考虑在哪些列上可以创建索引，在哪些列上不能创建索引。 一般来说，应该在这些列上创建索引。 第一，在经常需要搜索的列上，可以加快搜索的速度；
第二，在作为主键的列上，强制该列的唯一性和组织表中数据的排列结构； 第三，在经常用在连接的列上，这些列主要是一些外键，可以加快连接的速度；第四，在经常需要根据范围进行搜索的列上创建索引，因为索引已经排序，其指定的范围是连续的； 第五，在经常需要排序的列上创建索引，因为索引已经排序，这样查询可以利用索引的排序，加快排序查询时间； 第六，在经常使用在WHERE子句中的列上面创建索引，加快条件的判断速度。 同样，对于有些列不应该创建索引。一般来说，不应该创建索引的的这些列具有下列特点： 第一，对于那些在查询中很少使用或者参考的列不应该创建索引。这是因为，既然这些列很少使用到，因此有索引或者无索引，并不能提高查询速度。相反，由于增加了索引，反而降低了系统的维护速度和增大了空间需求。 第二，对于那些只有很少数据值的列也不应该增加索引。这是因为，由于这些列的取值很少，例如人事表的性别列，在查询的结果中，结果集的数据行占了表中数据行的很大比例，即需要在表中搜索的数据行的比例很大。增加索引，并不能明显加快检索速度。 第三，对于那些定义为text, image和bit数据类型的列不应该增加索引。这是因为，这些列的数据量要么相当大，要么取值很少。 第四，当修改性能远远大于检索性能时，不应该创建索引。这是因为，修改性能和检索性能是互相矛盾的。当增加索引时，会提高检索性能，但是会降低修改性能。当减少索引时，会提高修改性能，降低检索性能。因此，当修改性能远远大于检索性能时，不应该创建索引。 1.4 总结 1）索引提高了数据库的检索性能，但一定程度上牺牲了修改性能。因此适用于“多查询少修改”（insert，update，delete）的表。 2）对此类表中的外键，需要分组，排序或作为检索条件的字段建立索引 3）对此类表中查询使用少，字段取值少，字段数据量大的不应创建索引
SQL数据库优化方法
目录 1 系统优化介绍 (1) 2 外围优化 (1) 3 SQL优化 (2) 3.1 注释使用 (2) 3.2 对于事务的使用 (2) 3.3 对于与数据库的交互 (2) 3.4 对于SELECT *这样的语句， (2) 3.5 尽量避免使用游标 (2) 3.6 尽量使用count(1) (3) 3.7 IN和EXISTS (3) 3.8 注意表之间连接的数据类型 (3) 3.9 尽量少用视图 (3) 3.10 没有必要时不要用DISTINCT和ORDER BY (3) 3.11 避免相关子查询 (3) 3.12 代码离数据越近越好 (3) 3.13 插入大的二进制值到Image列 (4) 3.14 Between在某些时候比IN 速度更快 (4) 3.15 对Where条件字段修饰字段移到右边 (4) 3.16 在海量查询时尽量少用格式转换。 (4) 3.17 IS NULL 与IS NOT NULL (4) 3.18 建立临时表， (4) 3.19 Where中索引的使用 (5) 3.20 外键关联的列应该建立索引 (5) 3.21 注意UNion和`UNion all 的区别 (5) 3.22 Insert (5) 3.23 order by语句 (5) 3.24 技巧用例 (6) 3.24.1 Sql语句执行时间测试 (6)
1系统优化介绍 在我们的项目中，由于客户的使用时间较长或客户的数据量大，造成系统运行速度慢，系统性能下降就容易造成数据库阻塞。这是个非常痛苦的事情，用户的查询、新增、修改等需要花很多时间，甚至造成系统死机的现象。速度慢的原因主要是来自于资源不足。 数据库的优化通常可以通过对网络、硬件、操作系统、数据库参数和应用程序的优化来进行。最常见的优化手段就是对硬件的升级。根据统计，对网络、硬件、操作系统、数据库参数进行优化所获得的性能提升，全部加起来最多只占数据库系统性能提升的40%左右(我将此暂时称之为外围优化)；其余大部分系统性能提升来自对应用程序的优化，对于应用程序的优化可以分为对源代码的优化及数据库SQL语句的优化。在本文档只介绍外围优化及SQL语句的优化，对于源代码的优化需要相关方面的专家，形成统一的规范。 一个数据库系统的生命周期可以分成：设计、开发和成品三个阶段。在设计阶段进行数据库性能优化的成本最低，收益最大。在成品阶段进行数据库性能优化的成本最高，收益最小。规范的代码和高性能的语句，功在平时，利在千秋。 2外围优化 1、将操作系统与SQL数据库的补丁打到最高版本，WIN2003最高补丁是SP4， SQL SERVER2000最高补丁是SP4(版本号：2039)。 2、在服务器上不要安装与VA程序任何无相关的软件，甚至一些与VA运行 无关的服务都可以停掉。一般只安装SQL数据库、VA服务端服务及杀毒 软件。 3、杀毒软件避免对大文件进行扫描，特别是数据库（MDF和LDF）文件，一 定要从杀毒软件的范围内排除掉。 4、在进行服务器分区时，分区不要太多，两三个分区就可以了。分区最好 都使用NTFS格式。
SQL Server 2008数据查询的优化方法研究摘要 随着数据存储需求的日益增长，对关系数据的管理和访问就成为数据库技术必须解决的问题。本文主要论述关系数据库查询优化技术，并从它的优化技术进行深入探讨，对系统实现做了一定的论述，并进行了部分的程序实现。 关键词：数据库查询系统优化 引言 SQLServer是是由微软公司开发的基于Windows操作系统的关系型数据库管理系统，它是一个全面的、集成的、端到端的数据解决方案，为企业中的用户提供了一个安全、可靠和高效的平台用于企业数据管理和商业智能应用。目前，许多中小型企业的数据库应用系统都是用SQLServer作为后台数据库管理系统设计开发的。设计一个应用系统并不难，但是要想使系统达到最优化的性能并不是一件容易的事。根据多年的实践，由于初期的数据库中表的记录数比较少，性能不会有太大问题，但数据积累到一定程度，达到数百万甚至上千万条，全面扫描一次往往需要数十分钟，甚至数小时。20％的代码用去了80％的时间，这是程序设计中的一个著名定律，在数据库应用程序中也同样如此。如果用比全表扫描更好的查询策略，往往可以使查询时间降为几分钟。而且我们知道，目前数据库系统应用中，查询操作占了绝大多数，查询优化成为数据库性能优化最为重要的手段之一。 影响查询效率的因素 SQLServer处理查询计划的过程是这样的：在做完查询语句的词法、语法检查之后，将语句提交给SQLServer的查询优化器，查询优化器通过检查索引的存在性、有效性和基于列的统计数据来决定如何处理扫描、检索和连接，并生成若干执行计划，然后通过分析执行开销来评估每个执行计划，从中选出开销最小的执行计划,由预编译模块对语句进行处理并生成查询规划，然后在合适的时间提交给系统处理执行，最后将执行结果返回给用户。所以，SQLServer中影响查询效率的因素主要有以下几种： 1．没有索引或者没有用到索引。索引是数据库中重要的数据结构，使用索引的目的是避免全表扫描，减少磁盘I/O，以加快查询速度。 2．没有创建计算列导致查询不优化。 3．查询出的数据量过大（可以采用多次查询，其他的方法降低数据量）。 4．返回了不必要的行和列。 5．查询语句不好，没有优化。其中包括：查询条件中操作符使用是否得当;查询条件中的数据类型是否兼容;对多个表查询时,数据表的次序是否合理;多个选择条件查询时,选择条件的次序是否合理;是否合理安排联接选择运算等。 SQLServer数据查询优化方法 1、避免使用不兼容的数据类型。例如float和int、char和varchar、binary和varbinary 是不兼容的。数据类型的不兼容可能使优化器无法执行一些本来可以进行的优化操作。例如: select name from employee where salary ＞60000
1.列出数据库服务器、Web服务器的基本的硬件配置，如CPU、内存等。 2.检查数据库服务器是否真正启用了AWE内存。 (1) 启用AWE：数据库服务器检查C:\boot.ini文件,需要配置"/PAE"(*重启电脑才能生效),如下： [boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS [operating systems] multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows Server 2003, Enterprise" /noexecute=optout /fastdetect /PAE (2) 开启sql server 服务用户的，内存中锁定页面权限 (*重启电脑才能生效)在“服务管理”中查看 SQL SERVER 服务登录账户，默认是本地系统帐户（System）。然后在运行 gpedit.msc ，选择计算机配置->windows 设置->安全设置->本地策略->用户权限分配->内存中锁定页面。添加SQL SERVER服务的登录用户到里面去。 (3)启用数据库AWE内存，以服务器8G内存为例，一般设置如下，最小2G，最大6G(重启SQL SERVER服务即可)： (4)跟踪数据库性能“Total Server Memory ”的使用情况，看看数据库真正使 用的内存，越接近为数据库分配的最大内存越好。 或使用如下语句，查询数据库的内存使用情况： use master go select * from sysperfinfo where counter_name like '%Total Server Memory(KB)%' go 3.Web服务器监控项：
关于数据库优化方面的文章很多，但是有的写的似是而非，有的不切实际，对一个数据库来说，只能做到更优，不可能最优，并且由于实际需求不同，优化方案还是有所差异，根据实际需要关心的方面（速度、存储空间、可维护性、可拓展性）来优化数据库，而这些方面往往又是相互矛盾的，下面结合网上的一些看法和自己的一些观点做个总结。 一个系统的性能的提高，不单单是试运行或者维护阶段的性能调优，也不单单是开发阶段的事情，而是在整个软件生命周期都需要注意。所以我希望按照软件生命周期的不同阶段来总结数据库性能优化相关的注意事项。 一、分析阶段 一般来说，在系统分析阶段往往有太多需要关注的地方，系统各种功能性、可用性、可靠性、安全性需求往往吸引了我们大部分的注意力，但是，我们必须注意，性能是很重要的非功能性需求，必须根据系统的特点确定其实时性需求、响应时间的需求、硬件的配置等。最好能有各种需求的量化的指标。 另一方面，在分析阶段应该根据各种需求区分出系统的类型，大的方面，区分是OLTP(联机事务处理系统)和OLAP(联机分析处理系统)。 二、设计阶段 设计阶段可以说是以后系统性能的关键阶段，在这个阶段，有一个关系到以后几乎所有性能调优的过程—数据库设计。 在数据库设计完成后，可以进行初步的索引设计，好的索引设计可以指导编码阶段写出高效率的代码，为整个系统的性能打下良好的基础。 以下是性能要求设计阶段需要注意的： 1、数据库逻辑设计的规范化 数据库逻辑设计的规范化就是我们一般所说的范式，我们可以这样来简单理解范式：第1规范：没有重复的组或多值的列，这是数据库设计的最低要求。 第2规范: 每个非关键字段必须依赖于主关键字，不能依赖于一个组合式主关键字的某些组成部分。消除部分依赖，大部分情况下，数据库设计都应该达到第二范式。 第3规范: 一个非关键字段不能依赖于另一个非关键字段。消除传递依赖，达到第三范式应该是系统中大部分表的要求，除非一些特殊作用的表。 更高的范式要求这里就不再作介绍了，个人认为，如果全部达到第二范式，大部分达到第三范式，系统会产生较少的列和较多的表，因而减少了数据冗余，也利于性能的提高。 2、合理的冗余 完全按照规范化设计的系统几乎是不可能的，除非系统特别的小，在规范化设计后，有计划地加入冗余是必要的。 冗余可以是冗余数据库、冗余表或者冗余字段，不同粒度的冗余可以起到不同的作用。 冗余可以是为了编程方便而增加，也可以是为了性能的提高而增加。从性能角度来说，冗余数据库可以分散数据库压力，冗余表可以分散数据量大的表的并发压力，也可以加快特殊查询的速度，冗余字段可以有效减少数据库表的连接，提高效率。 3、主键的设计 主键是必要的，SQL SERVER的主键同时是一个唯一索引，而且在实际应用中，我们往往选择最小的键组合作为主键，所以主键往往适合作为表的聚集索引。聚集索引对查询的影响是比较大的，这个在下面索引的叙述。 在有多个键的表，主键的选择也比较重要，一般选择总的长度小的键，小的键的比较速度快，同时小的键可以使主键的B树结构的层次更少。 主键的选择还要注意组合主键的字段次序，对于组合主键来说，不同的字段次序的主键的性能差别可能会很大，一般应该选择重复率低、单独或者组合查询可能性大的字段放在前
查询速度慢如何解决 ------主要针对SQL 2005 为例 引起查询或更新的执行时间超过预期时间的原因有多种。查询运行慢，可能是由与运行 SQL Server 的网络或计算机相关的性能问题引起的，也可能是由物理数据库设计问题引起的。 查询和更新运行慢的最常见原因有： ?网络通讯速度慢。 ?服务器的内存不足，或者没有足够的内存供 SQL Server 使用。 ?索引列上缺少有用的统计信息。 ?索引列上的统计信息过期。 ?缺少有用的索引。 ?缺少有用的索引视图。 ?缺少有用的数据条带化。 ?缺少有用的分区。 1、用于对运行慢的查询进行故障排除的清单 当查询或更新花费的时间比预期时间长时，请考虑以下问题，找到可解答前一节中列出的查询运行慢的原因： ①. 是与组件而不是与查询相关的性能问题吗？例如，是网络性能低的问题吗？有其他可能引起或造成性能降低的组件吗？ Windows 系统监视器可用于监视与 SQL Server 和非 SQL Server 相关的组件的性能。有关详细信息，请参阅监视资源使用情况（系统监视器）。 ②. 如果性能问题与查询相关，那么涉及到的是哪个或哪组查询？ 首先使用 SQL Server Profiler来帮助找出运行慢的查询。有关详细信息，请参阅使用 SQL Server Profiler。 在找出运行慢的查询后，可以使用 SET 语句启用 SHOWPLAN、STATISTICS IO、STATISTICS TIME 和 STATISTICS PROFILE 选项，进一步分析查询的性能，相关描述如下： ?SET SHOWPLAN_XML ON 描述 SQL Server 查询优化器选择用来检索完善的 XML 文档数据的方法。有关详细信息，请参阅 SET SHOWPLAN_XML (Transact-SQL)。在 Microsoft SQL Server 2005 中，建议使用这种方法。此 SET 选项生成的信息比 SHOWPLAN_ALL 和 SHOWPLAN_TEXT SET 选项生成的信息详细。 ?SET SHOWPLAN_ALL ON 描述 SQL Server 查询优化器选择的数据检索方法。有关详细信息，请参阅 SET SHOWPLAN_ALL (Transact-SQL)。此 SET 选项生成的信息比 SHOWPLAN_TEXT SET 选项生成的信息详细。 ?SET SHOWPLAN_TEXT ON 返回每条 Transact-SQL 语句的执行信息，但不执行它们。有关详细信息，请参阅SET SHOWPLAN_TEXT (Transact-SQL)。
SELECT语句的性能调优有时是一个非常耗时的任务，在我看来它遵循帕累托原则。20%的努力很可能会给你带来80%的性能提升，而为了获得另外20%的性能提升你可能需要花费80%的时间。除非你在金星工作，那里的每一天都等于地球上的243天，否则交付期限很有可能使你没有足够的时间来调优SQL查询。 根据我多年编写和运行SQL语句的经验，我开始开发一个检查列表，当我试图提高查询性能时供我参考。在进行查询计划和阅读我使用的数据库文档之前，我会参考其中的内容，数据库文档有时会很复杂。我的检查列表绝对说不上全面或科学，它更像是一个保守计算，但我可以说，遵循这些简单的步骤大部分时间我确实能得到性能提升。检查列表如下。 检查索引 在SQL语句的WHERE和JOIN部分中用到的所有字段上，都应该加上索引。进行这个3分钟SQL性能测试。不管你的成绩如何，一定要阅读那些带有信息的结果。 限制工作数据集的大小 检查那些SELECT语句中用到的表，看看你是否可以应用WHERE子句进行过滤。一个典型的例子是，当表中只有几千行记录时，一个查询能够很好地执行。但随着应用程序的成长，查询慢了下来。解决方案或许非常简单，限制查询来查看当前月的数据即可。 当你的查询语句带有子查询时，注意在子查询的内部语句上使用过滤，而不是在外部语句上。 只选择你需要的字段 额外的字段通常会增加返回数据的纹理，从而导致更多的数据被返回到SQL客户端。另外： •使用带有报告和分析功能的应用程序时，有时报告性能低是因为报告工具必须对收到的、带有详细形式的数据做聚合操作。 •偶尔查询也可能运行地足够快，但你的问题可能是一个网络相关的问题，因为大量的详细数据通过网络发送到报告服务器。 •当使用一个面向列的DBMS时，只有你选择的列会从磁盘读取。在你的查询中包含的列越少，IO开销就越小。 移除不必要的表 移除不必要的表的原因，和移除查询语句中不需要的字段的原因一致。 编写SQL语句是一个过程，通常需要大量编写和测试SQL语句的迭代过程。在开发过程中，你可能将表添加到查询中，而这对于SQL代码返回的数据可能不会有任何影响。一旦SQL运行正确，我发现许多人不会回顾他们的脚本，不会删除那些对最终的返回数据没有任何影响和作用的表。通过移除与那些不必要表的JOINS操作，你减少了大量数据库必须执行的流程。有时，就像移除列一样，你会发现你减少的数据又通过数据库返回来了。 移除外部连接查询 这说起来容易做起来难，它取决于改变表的内容有多大的影响。一个解决办法是通过在两个表的行中放置占位符来删除OUTER JOINS操作。假设你有以下的表，它们通过定义OUTER JOINS来确保返回所有的数据： customer_idcustomer_name 1John Doe 2Mary Jane 3Peter Pan 4Joe Soap
近期因工作需要，希望比较全面的总结下SQL SERVER数据库性能优化相关的注意事项，在网上搜索了一下,发现很多文章,有的都列出了上百条,但是仔细看发现，有很多似是而非或者过时(可能对SQL 以前的版本或者ORACLE是适用的)的信息，只好自己根据以前的经验和测试结果进行总结了。 我始终认为，一个系统的性能的提高，不单单是试运行或者维护阶段的性能调优的任务，也不单单是开发阶段的事情，而是在整个软件生命周期都需要注意，进行有效工作才能达到的。所以我希望按照软件生命周期的不同阶段来总结数据库性能优化相关的注意事项。 一、分析阶段 一般来说，在系统分析阶段往往有太多需要关注的地方，系统各种功能性、可用性、可靠性、安全性需求往往吸引了我们大部分的注意力，但是，我们必须注意，性能是很重要的非功能性需求，必须根据系统的特点确定其实时性需求、响应时间的需求、硬件的配置等。最好能有各种需求的量化的指标。 另一方面，在分析阶段应该根据各种需求区分出系统的类型，大的方面，区分是OLTP（联机事务处理系统）和OLAP（联机分析处理系统）。 二、设计阶段 设计阶段可以说是以后系统性能的关键阶段，在这个阶段，有一个关系到以后几乎所有性能调优的过程—数据库设计。 在数据库设计完成后，可以进行初步的索引设计，好的索引设计可以指导编码阶段写出高效率的代码，为整个系统的性能打下良好的基础。 以下是性能要求设计阶段需要注意的： 1、数据库逻辑设计的规范化 数据库逻辑设计的规范化就是我们一般所说的范式，我们可以这样来简单理解范式： 第1规范：没有重复的组或多值的列，这是数据库设计的最低要求。 第2规范: 每个非关键字段必须依赖于主关键字，不能依赖于一个组合式主关键字的某些组成部分。消除部分依赖，大部分情况下，数据库设计都应该达到第二范式。 第3规范: 一个非关键字段不能依赖于另一个非关键字段。消除传递依赖，达到第三范式应该是系统中大部分表的要求，除非一些特殊作用的表。 更高的范式要求这里就不再作介绍了，个人认为，如果全部达到第二范式，大部分达到第三范式，系统会产生较少的列和较多的表，因而减少了数据冗余，也利于性能的提高。
Oracle SQL性能优化方法探讨 Oracle性能优化方法(SQL篇) (1) 1综述 (2) 2表分区的应用 (2) 3访问Table的方式 (3) 4共享SQL语句 (3) 5选择最有效率的表名顺序 (5) 6WHERE子句中的连接顺序． (6) 7SELECT子句中幸免使用’*’ (6) 8减少访问数据库的次数 (6) 9使用DECODE函数来减少处理时刻 (7) 10整合简单,无关联的数据库访问 (8) 11删除重复记录 (8) 12用TRUNCATE替代DELETE (9) 13尽量多使用COMMIT (9) 14计算记录条数 (9) 15用Where子句替换HAVING子句 (9) 16减少对表的查询 (10) 17通过内部函数提高SQL效率 (11)
18使用表的不名(Alias) (12) 19用EXISTS替代IN (12) 20用NOT EXISTS替代NOT IN (13) 21识不低效执行的SQL语句 (13) 22使用TKPROF 工具来查询SQL性能状态 (14) 23用EXPLAIN PLAN 分析SQL语句 (14) 24实时批量的处理 (16)
1综述 ORACLE数据库的性能调整是个重要，却又有难度的话题，如何有效地进行调整，需要通过反反复复的过程。在数据库建立时，就能依照顾用的需要合理设计分配表空间以及存储参数、内存使用初始化参数，对以后的数据库性能有专门大的益处，建立好后，又需要在应用中不断进行应用程序的优化和调整，这需要在大量的实践工作中不断地积存经验，从而更好地进行数据库的调优。 数据库性能调优的方法 ●调整内存 ●调整I/O ●调整资源的争用问题 ●调整操作系统参数 ●调整数据库的设计 ●调整应用程序 本文针对应用程序的调整，来讲明对数据库性能如何进行优化。 2表分区的应用 关于海量数据的表，能够考虑建立分区以提高操作效率。建
一、实验目的 1.熟悉查询查询处理的过程； 2.掌握查询优化的概念，理解查询优化的必要性； 3.了解数据库的查询计划； 4.掌握查询代价的分析方法，并且能通过配置参数或者修改SQL语句来降低 查询代价。 二、实验环境 SQL Server 三、实验学时 2学时 四、实验要求 1）求选修了00002号课程的学生姓名。用SQL表达： SELECT Student.Sname FROM Student，SC WHERE Student.Sno=SC.Sno AND https://www.doczj.com/doc/f19019718.html,o=‘00002’ 2）三种实现方法： Q1=πSname(σStudent.Sno=SC.Sno∧https://www.doczj.com/doc/f19019718.html,o='2' (Student×SC)) Q2=πSname(σhttps://www.doczj.com/doc/f19019718.html,o='2' (Student SC)) Q3=πSname(Student σhttps://www.doczj.com/doc/f19019718.html,o='2'(SC)) 3）要求：本实验旨在说明查询优化的必要性，只要求把法一Q1与法二Q2和法三 Q3比较，从而说明查询优化的重要性 五、实验内容及步骤 （一）实验数据的准备 -- 1.创建数据库 create database stu_optimization ON ( NAME = stu_opti, FILENAME = 'E:\stu_opti\stu_opti.mdf', SIZE = 100, MAXSIZE = 500, FILEGROWTH = 10 ) LOG ON ( NAME = 'stu_opti_log', FILENAME = 'E:\stu_opti\stu_opti_log.ldf', SIZE = 50MB,
数据库优化查询计划的方法 数据库系统是管理信息系统的核心，基于数据库的联机事务处理（OLTP）以及联机分析处理(OLAP)是银行、企业、政府等部门最为重要的计算机应用之一。从大多数系统的应用实例来看，查询操作在各种数据库操作中所占据的比重最大，而查询操作所基于的SELECT语句在SQL语句中又是代价最大的语句。举例来说，如果数据的量积累到一定的程度，比如一个银行的账户数据库表信息积累到上百万甚至上千万条记录，全表扫描一次往往需要数十分钟，甚至数小时。如果采用比全表扫描更好的查询策略，往往可以使查询时间降为几分钟，由此可见查询优化技术的重要性。 在应用项目的实施中发现，许多程序员在利用一些前端数据库开发工具（如PowerBuilder、Delphi等）开发数据库应用程序时，只注重用户界面的华丽，并不重视查询语句的效率问题，导致所开发出来的应用系统效率低下，资源浪费严重。因此，如何设计高效合理的查询语句就显得非常重要。本文以应用实例为基础，结合数据库理论，介绍查询优化技术在现实系统中的运用。 分析问题 许多程序员认为查询优化是DBMS（数据库管理系统）的任务，与程序员所编写的SQL语句关系不大，这是错误的。
一个好的查询计划往往可以使程序性能提高数十倍。查询计划是用户所提交的SQL语句的集合，查询规划是经过优化 处理之后所产生的语句集合。DBMS处理查询计划的过程是这样的：在做完查询语句的词法、语法检查之后，将语句提交给DBMS的查询优化器，优化器做完代数优化和存取路径的优化之后，由预编译模块对语句进行处理并生成查询规划，然后在合适的时间提交给系统处理执行，最后将执行结果返回给用户。在实际的数据库产品(如Oracle、Sybase等)的高版本中都是采用基于代价的优化方法，这种优化能根据从系统字典表所得到的信息来估计不同的查询规划的代价，然后选择一个较优的规划。虽然现在的数据库产品在查询优化方面已经做得越来越好，但由用户提交的SQL语句是系统优 化的基础，很难设想一个原本糟糕的查询计划经过系统的优化之后会变得高效，因此所写语句的优劣至关重要。下面重点说明改善查询计划的解决方案。 解决问题 下面以关系数据库系统Informix为例，介绍改善用户查询计划的方法。 1．合理使用索引 索引是数据库中重要的数据结构，它的根本目的就是为了提高查询效率。现在大多数的数据库产品都采用IBM最先提出的ISAM索引结构。索引的使用要恰到好处，其使用原则如
ＳＱＬＳｅｒｖｅｒ数据查询的优化方法聂文燕 摘要：SQLServer是一种功能强大的数据库管理系统，许多数据库应用系统都是以它作为后台数据库。本文在分析影响SQLSERVER数据查询效率的因素的基础上，提出了几种优化数据查询的方法。 关键词：SQLServer，数据，查询，优化 一、引言 SQLServer是是由微软公司开发的基于Windows操作系统的关系型数据库管理系统，它是一个全面的、集成的、端到端的数据解决方案，为企业中的用户提供了一个安全、可靠和高效的平台用于企业数据管理和商业智能应用。目前，许多中小型企业的数据库应用系统都是用SQLServer作为后台数据库管理系统设计开发的。设计一个应用系统并不难，但是要想使系统达到最优化的性能并不是一件容易的事。根据多年的实践，由于初期的数据库中表的记录数比较少，性能不会有太大问题，但数据积累到一定程度，达到数百万甚至上千万条，全面扫描一次往往需要数十分钟，甚至数小时。20％的代码用去了80％的时间，这是程序设计中的一个著名定律，在数据库应用程序中也同样如此。如果用比全表扫描更好的查询策略，往往可以使查询时间降为几分钟。而且我们知道，目前数据库系统应用中，查询操作占了绝大多数，查询优化成为数据库性能优化最为重要的手段之一。 二、影响查询效率的因素 SQLServer处理查询计划的过程是这样的：在做完查询语句的词法、语法检查之后，将语句提交给SQLServer的查询优化器，查询优化器通过检查索引的存在性、有效性和基于列的统计数据来决定如何处理扫描、检索和连接，并生成若干执行计划，然后通过分析执行开销来评估每个执行计划，从中选出开销最小的执行计划,由预编译模块对语句进行处理并生成查询规划，然后在合适的时间提交给系统处理执行，最后将执行结果返回给用户。所以，SQLServer中影响查询效率的因素主要有以下几种：1．没有索引或者没有用到索引。索引是数据库中重要的数据结构，使用索引的目的是避免全表扫描，减少磁盘I/O，以加快查询速度。 2．没有创建计算列导致查询不优化。 3．查询出的数据量过大（可以采用多次查询，其他的方法降低数据量）。 4．返回了不必要的行和列。 5．查询语句不好，没有优化。其中包括：查询条件中操作符使用是否得当;查询条件中的数据类型是否兼容;对多个表查询时,数据表的次序是否合理;多个选择条件查询时,选择条件的次序是否合理;是否合理安排联接选择运算等。 三、SQLServer数据查询优化方法 3.1建立合适的索引索引是数据库中重要的数据结构，它的根本目的就是为了提高查询效率。当根据索引码的值搜索数据时，索引提供了对数据的快速访问。事实上，没有索引,数据库也能根据SELECT语句成功地检索到结果，但随着表变得越来越大，使用“适当”的索引的效果就越来越明显。索引的使用要恰到好处，其使用原则有： (1)对于基本表，不宜建立过多的索引； (2)对于那些查询频度高，实时性要求高的数据一定要建立索引，而对于其他的数据不考虑建立索引； (3)在经常进行连接，但是没有指定为外键的列上建立索引； (4)在频繁进行排序或分组（即进行groupby或orderby操作）的列上建立索引；