数据库优化创新

数据库优化创新（共8篇）

数据库优化创新 篇1

说明：插入之前建立的话，在表插入数据的过程中，索引也随着更新，这样的话需要较大的日志空间，因此速度会比较慢，可以采用不计日志的方式插入;数据插完之后再建立索引的话，该表的日志统计信息没有更新，因此执行计划会很差，用不到索引，runstats on tabble asiainfo.aaaa and indexes all之后，索引统计信息就会更新，这样执行计划会考虑到使用索引，因此速度快。

2、将比较大的表建在多节点的表空间上，同时建好索引

说明：现有的db2数据仓库每个节点使用2个CPU，4G内存，DIM表空间计划是存放维表的表空间，因此是单节点的。在使用这个表空间中的表的时候，最多只会用到2个CPU，4G内存，加上其他的表空间也都要用到这两个CPU和这4G内存，因此资源比较有限。建议较大的表不要放在这个表空间中，而是建立好分区键，放在多节点的表空间中，这样检索这个表的时候32个节点同时检索，最后汇总到0节点上进行展现，速度当然会非常的快。另外，虽然32节点并行性好，但是如果建立好索引的话，速度会更快!!

3、将插入的表使用不计日志的方式插入

说明：数据库为了保证数据的一致性和可回退性，插入、更新或者删除数据的时候要计日志，这样在失败的时候可以回退，但是如果并发较多或者操作非常大的话，会导致争抢日志的情况，导致操作非常缓慢。如果使用不计日志的方式进行插入、更新或者删除操作的话，日志使用极少，但是如果操作失败的话是无法回退的，这样一致性得不到保证，这个表只能删除重建!!!!

4、将表建立表级锁，减少锁数量的使用

说明：数据库的锁的最大数量是有限制的，并且每个锁都要占一定的内存，因此如果锁的数量非常多，使用的内存也就多，导致资源紧张。

5、建立临时表的时候尽量只插入用的到的数据，不插用不到的数据

说明：程序中好多地方为了提高速度，将用到的数据先插入到一个临时表中，但是插入了非常多的没有使用的数据，这样导致临时表也非常大，所以尽可能的只向临时表中插入用的到的数据，并且尽可能的使用索引，可以大大的提高速度。

6、关于左关联的一点使用心得

说明：在on的条件里面尽量的只写关联条件和对左关联的表作限制，而对主表的限制不要写在这里。如果写在里面的话，不但速度非常慢，而且可能会出现莫名其妙的结果。

数据库优化创新 篇2

1 提升能力, 增强编辑创新水平

1.1 搜集数据过程中的编辑能力

新闻编辑展开报道的前提是数据信息的搜集和处理。目前, 网络为新闻编辑提供了海量的数据和信息, 具有复杂多样的特点, 容易对公众产生误导, 因此新闻编辑通过搜集数据的方式为公众提供有价值的信息显得十分必要。数据信息的搜集渠道主要包括搜索引擎 (百度、谷歌) 、网络论坛站点 (天涯、猫扑) 、专业数据中心 (MDC福地数据中心、国家统计局数据管理中心) 三种。当然, 新闻编辑搜集数据的渠道还相当广泛, 各类专题网站和数据库也是行之有效的选择, 例如百度数据中心、易观国际等专业机构, 能为用户提供媒体、游戏、视频、广告等许多内容的相关数据, 为新闻编辑的搜集工作提供参考。此外, 新闻编辑要从细节部分入手, 对外部环境的变化时刻保持敏感度, 紧密跟进事件发展状态, 扩大新闻的挖掘范围, 满足公众对新闻的多样化需求。

1.2 加工数据过程中的编辑能力

搜集海量数据是新闻编辑工作的第一步, 新闻报道的内容通过对数据进行加工整理而来, 在引用数据的过程中, 可能出现以下问题:1) 数据缺乏准确性;2) 数据缺乏说服力;3) 数据过多, 整理困难。因此, 新闻编辑在对数据信息进行加工处理时, 首先要具备明辨是非的能力, 从搜集到的海量信息中挖掘事件真相, 经过分析加工后及时报道, 去除不必要的干扰数据信息, 做到精准无误, 量少而精;其次, 将数据格式进行统一, 包括完备性的测试和计算, 对于一些抽象数据, 可通过对比换算的方法实现数据信息的灵活运用, 针对统计表中的数据, 则还需考虑到数据的可比性以及是否具有条理;最后, 在加工数据的过程中还需注意逻辑性和概念性数据容易产生的错误, 例如百分比表述不当, 将“30%~70%”表述成“30~70%”;数值区间表述不当, 将“2万~5万”表述成“2~5万”等等。

1.3 呈现数据过程中的编辑能力

在大数据时代的背景下, 数据和新闻可通过可视化技术进行完美结合, 从而以动态信息的方式进行发布, 丰富了新闻的表现形式, 例如You Tbe网站, 可为用户提供免费的视频服务, 谷歌也推出了谷歌数据融合表等可视化数据服务, 能更加高效的对数据进行批量操作 (分门、别类、聚合) , 新闻编辑可借助这些工具和软件将数据生成各类图表, 充分利用计算机技术和艺术数据, 将抽象复杂、枯燥单调的数据转化为具体生动、有说服力的新闻报道, 挖掘数据在新闻报道过程中的价值。

2 多元视角, 优化新闻宣传内容

2.1 新闻内容要满足公众需求

新闻的主要服务对象是广大公众, 因此新闻内容必须要符合共同的价值观和思想观, 让公众在最短时间内理解内涵。例如, 新闻编辑可在艰涩难懂的政治新闻中多增加一些具体的画面解说, 在有关民生的新闻中尽量保持口语化, 在社会新闻中多使用图像和视频等。此外, 要增加新闻内容中的信息含量, 在完成数据信息的搜集和加工后, 尽量挑选贴近实际生活, 具有价值的信息进行报道, 可借助网络媒体, 建立新闻同步信息平台, 增加新闻报道的深度和广度。

2.2 新闻编辑要更新知识结构

新闻编辑要深入公众生活, 不断积累素材, 增加知识储备, 更新知识结构, 提高编辑能力和突发事件的应对能力, 新闻编辑只有具备丰厚的文化底蕴, 才能不断激发灵感, 拓展思维。在数据发掘和新闻报道的过程中, 涉及范围较广, 需要具备各领域的知识才能为公众提供高质量的新闻, 这就需要新闻编辑博采众长, 对各专业、各领域的核心知识都有一定程度的了解。此外, 新闻涵盖了文学、政治、历史、法律、军事等内容。新闻编辑只有不断积累、更新知识, 才能找准公众的关注重点, 在各领域的新闻报道中挥洒自如。

3 全面发展, 丰富新闻表达形式

随着科技发展, 更多新颖的符号和其他表现方式层出不穷, 例如Flash短动画、屏幕动态文字等。因此, 新闻编辑要不断推陈出新, 丰富新闻形式, 吸引公众注注意力, 例如在录制电视新闻节目时增加公众互动环节, 让公众能通过微博、微信参与讨论, 提升新闻的影响力。基于新闻信息量过大的特点, 在进行播报时可采用“单元式”的方法——将新闻按照信息重要程度进行合理划分, 或者将新闻按照世界、国家、地区进行等级划分, 让公众能准确找到重点新闻或自己感兴趣的新闻。同时, 新闻编辑要充分利用线条, 制作出有画面感的新闻, 增添让人耳目一新的标题, 将新闻的语言功能最大限度的呈现在公众面前, 更好的展现出新闻编辑的创新优化能力。

总之, 在大数据时代背景下, 新闻编辑的能力和知识结构将得到进一步的扩展与提升, 新闻从业人员需要深刻领悟, 大数据新闻的产生和传播并非编辑的个人之功, 其数据来源包含了广大媒体人员的辛勤劳作, 新闻编辑要与时俱进、不断创新, 丰富新闻内容, 优化报道形式, 在新闻媒体传播中发挥积极作用, 才能促使我国新闻报道质量的整体提升, 实现媒体的优质发展。

参考文献

[1]王素荣.新闻编辑的创新意识和编辑能力分析[J].新闻研究导刊, 2014 (15) :92-92.

浅析数据库的优化设计 篇3

关键词：ORACLE数据库优化设计

中图分类号：TP311.13 文献标识码：A文章编号：1007-9599 (2010) 13-0000-01

Optimal Design of Database

Liu Lifeng 1, Bao Wei 2, Zhang Rui3

(1.Tonghua Erdaojiang Government Website,Tonghua 134002,China; 2.Tonghua Erdaojiang Human Resources and Social Council,Tonghua 134002,China;3.Erdaojiang Office of Information Center,Tonghua 134002,China)

Abstract:This article from the large database ORACLE environment analysis of four different levels of adjustment,analyzes the ORACLE system structure and working mechanism of optimization is to adjust for a purpose to improve the performance component level,that increase throughput and reduce response time.If the DBA into account the following aspects from the optimization program,I believe that most ORACLE application can be done by the best ways to access the data.

Keywords:ORACLE Database Optimization

对数据库进行调整、优化，数据库的整体性能会得到很大的改善。下面从几个不同方面介绍数据库优化设计方案。

一、数据库优化自由结构OFA（OptimalflexibleArchitecture）

数据库的逻辑配置对数据库性能有很大的影响，为此，ORACLE公司对表空间设计提出了一种优化结构OFA。使用这种结构进行设计会大大简化物理设计中的数据管理。优化自由结构OFA，简单地讲就是在数据库中可以高效自由地分布逻辑数据对象，因此首先要对数据库中的逻辑对象根据他们的使用方式和物理结构对数据库的影响来进行分类，这种分类包括将系统数据和用户数据分开、一般数据和索引数据分开、低活动表和高活动表分开等等。

二、规范与反规范设计数据库

（一）规范化。范式是符合某一级别的关系模式的集合，根据约束条件的不同，一般有1NF、2NF、3NF三种范式。规范化理论是围绕这些范式而建立的。规范化的基本思想是逐步消除数据依赖中不合适的部分，使模式中的各关系模式达到某种程度的“分离”，即采用“一事一地”的模式设计原则，因此，所谓规范化实质上就是概念的单一化。数据库中数据规范化的优点是减少了数据冗余，节约了存储空间，相应逻辑和物理的I/O次数减少，同时加快了增、删、改的速度。但是一个完全规范化的设计并不总能生成最优的性能，因为对数据库查询通常需要更多的连接操作，从而影响到查询的速度。故有时为了提高某些查询或应用的性能而有意破坏规范规则，即反规范化。

（二）反规范化。在进行反规范设计之前，要充分考虑数据的存取需求，常用表的大小、特殊的计算、数据的物理存储等。常用的反规范技术有合理增加冗余列、派生列，或重新组表几种。反规范化的好处是降低连接操作的需求、降低外码和索引数目，减少表的个数，从而提高查询速度，这对于性能要求相对较高的数据库系统来说，能有效地改善系统的性能，但相应的问题是可能影响数据的完整性，加快查询速度的同时降低修改速度。

（三）数据库设计中的优化策略。数据应当按两种类别进行组织：频繁访问的数据和频繁修改的数据。对于频繁访问但是不频繁修改的数据，内部设计应当物理不规范化。对于频繁修改但并不频繁访问的数据，内部设计应当物理规范化。比较复杂的方法是将规范化的表作为逻辑数据库设计的基础，然后再根据整个应用系统的需要，物理地非规范化数据。规范与反规范都是建立在实际的操作基础之上的约束，脱离了实际两者都没有意义。只有把两者合理地结合在一起，才能相互补充，发挥各自的优点。

三、索引Index的优化设计

（一）管理组织索引。索引可以大大加快数据库的查询速度，索引把表中的逻辑值映射到安全的RowID，因此索引能进行快速定位数据的物理地址。但是有些DBA发现，对一个大型表建立的索引，并不能改善数据查询速度，反而会影响整个数据库的性能。这主要是和SGA的数据管理方式有关。ORACLE在进行数据块高速缓存管理时，索引数据比普通数据具有更高的驻留权限，在进行空间竞争时，ORACLE会先移出普通数据。对一个建有索引的大型表的查询时，索引数据可能会用完所有的数据块缓存空间，ORACLE不得不频繁地进行磁盘读写来获取数据，因此在对一个大型表进行分区之后，可以根据相应的分区建立分区索引。如果对这样大型表的数据查询比较频繁，或者干脆不建索引。另外，DBA创建索引时，应尽量保证该索引最可能地被用于where子句中，如果对查询只简单地制定一个索引，并不一定会加快速度，因为索引必须指定一个适合所需的访问路径

（二）聚簇的使用。Oracle提供了另一种方法来提高查询速度，就是聚簇（Cluster）。所谓聚簇，简单地说就是把几个表放在一起，按一定公共属性混合存放。聚簇根据共同码值将多个表的数据存储在同一个Oracle块中，这时检索一组Oracle块就同时得到两个表的数据，这样就可以减少需要存储的Oracle块，从而提高应用程序的性能。

（三）优化设置的索引，就必须充分利用才能加快数据库访问速度。ORACLE要使用一个索引，有一些最基本的条件：1）、where子名中的这个字段，必须是复合索引的第一个字段；2）、where子名中的这个字段，不应该参与任何形式的计算。

四、使用最优的数据库连接和SQL优化方案

（一）使用直接的OLEDB数据库连接方式。通过ADO可以使用两种方式连接数据库，一种是传统的ODBC方式，一种是OLEDB方式。ADO是建立在OLEDB技术上的，为了支持ODBC，必须建立相应的OLEDB到ODBC的调用转换，而使用直接的OLEDB方式则不需转换，从而提高处理速度。

（二）使用ConnectionPool机制。在数据库处理中，资源花销最大的是建立数据库连接，而且用户还会有一个较长的连接等待时间。解决的办法就是复用现有的Connection，也就是使用ConnectionPool对象机制。

ConnectionPool的原理是：IIS+ASP体系中维持了一个连接缓冲池，这样，当下一个用户访问时，直接在連接缓冲池中取得一个数据库连接，而不需重新连接数据库，因此可以大大地提高系统的响应速度。

（三）高效地进行SQL语句设计。通常情况下，可以采用下面的方法优化SQL对数据操作的表现：

1.减少对数据库的查询次数，即减少对系统资源的请求，使用快照和显形图等分布式数据库对象可以减少对数据库的查询次数。

2.尽量使用相同的或非常类似的SQL语句进行查询，这样不仅充分利用SQL共享池中的已经分析的语法树，要查询的数据在SGA中命中的可能性也会大大增加。

3.限制动态SQL的使用，虽然动态SQL很好用，但是即使在SQL共享池中有一个完全相同的查询值，动态SQL也会重新进行语法分析。

4.避免不带任何条件的SQL语句的执行。没有任何条件的SQL语句在执行时，通常要进行FTS，数据库先定位一个数据块，然后按顺序依次查找其它数据，对于大型表这将是一个漫长的过程。

5.如果对有些表中的数据有约束，最好在建表的SQL语句用描述完整性来实现，而不是用SQL程序中实现。

五、结束语

总之，对所有的性能问题，没有一个统一的解决方法，但ORACLE提供了丰富的选择环境，可以从ORACLE数据库的体系结构、软件结构、模式对象以及具体的业务和技术实现出发，进行统筹考虑。提高系统性能需要一种系统的整体的方法，在对数据库进行优化时，应对应用程序、I/O子系统和操作系统（OS）进行相应的优化。优化是有目的地更改系统的一个或多个组件，使其满足一个或多个目标的过程。

参考文献：

[1]瓮正科王新英Oracle8.XForWindowsNT实用教程[M].清华大学出版社,1999

数据库优化创新 篇4

南方某省级电信运营商的计费业务营账系统在上线运行后不久即出现性能问题。主要问题表现在最终用户的交互响应达不到预期，特别是在业务繁忙时段无法做出及时响应。从主机系统的角度观察，问题主要集中在系统的I/O(输入/输出)等待较大。而该营账系统由业务应用程序、甲骨文数据库、IBM AIX主机、IBM企业级存储服务器等部件构成，性能瓶颈的定位和优化过程均较为复杂。

数据库专家通过应用性能监测工具分析系统运行状况，在对主机和存储系统进行调优、并确保其能够满足现阶段生产系统的处理需求后，对甲骨文数据库的优化提出了针对性的建议。建议包括，为了应用系统扩容后处理压力的增大，对甲骨文数据库的性能参数进行修改;通过监测软件排查资源消耗最大的SQL语句的逻辑设计，将这些SQL语句的表结构与索引分别存储，建立合适的分区索引;通过监测软件对数据库和应用的数据分析，准确定位应用系统运行瓶颈，并做出相应的检查和调整。

这一典型案例浓缩了数据库性能优化过程中的几个关键步骤，及其在整体IT管理流程中的角色定位。在数据库成熟应用的时代，数据库的性能优化已经演变为一项相当严密的系统工程。作为企业IT基础设施的核心部件之一，数据库并不是孤立的系统，它与网络、操作系统、存储等硬件系统紧密相连，这种与其他IT部件的多重连接特性决定了数据库性能优化是一门综合技术。

在应用丛生、高度分布式的环境中，要总结出一套“放之四海皆准”的数据库性能优化方法论并不容易。但结合企业自身特色的性能优化流程却是有据可循的。在流程确立的过程之中，企业首先需要明确的问题就是，无论从什么样的角度切入，都要确保优化行为能够与IT系统的整体管理框架保持协调地联动，因为数据库的性能问题不仅仅局限在数据库内部。在大部分情况下，其优化行为都要围绕IT整体性能调优的思路展开。

路径全局谋划

古语云：“不谋全局者，不足谋一域。”说的是如果不从全局角度考虑问题，是无法获得局部智慧的。具体到数据库性能优化，通常包含针对应用、参数、存储、硬件、网络、操作系统的优化操作。有统计显示，对网络、硬件、操作系统、数据库参数进行优化所获得的性能提升，只占数据库系统性能提升的40%左右，其余60%的系统性能提升则来自于对应用程序的优化。作为金融、电信行业的资深数据库顾问，庄梁科技(北京)有限公司数据库专家牛新庄博士指出，数据库性能优化在很多时候都需要解决数据库以外的问题，这要求实践者具有完整的知识体系，是一项非常具有挑战性的工作。

“系统资源紧张是导致数据库性能问题的根本原因。”牛新庄博士说。针对常见的来自CPU、内存、磁盘I/O、网络的系统资源损耗，他总结了一套常规的问题流程。具体包含定位性能瓶颈、判断最消耗资源的应用或SQL，对逻辑资源的重新划分、、分析性能问题是否局限于数据库、追溯问题原因等步骤。

在阐述数据库性能优化的整体性时，海关数据库专家王翔强调，单点调优对数据库性能的提升意义不大。他指出，在针对常见的分布式数据库引擎的优化过程中，DBA(数据库管理员)的主要任务包括网络、架构、存储的调优和业务应用的优化，除此之外，还有通常被IT部门所忽视的用户体验的优化。“数据库性能优化存在很多程式化的内容，每一个的DBA都有自己解决问题的套路，而这些套路的共同点是从全局角度出发实施具体操作。”王翔说。

现阶段，用户反馈和运行监控是DBA发现数据库性能问题的主要来源。发现故障后，DBA需要用手动指令或专业的监控分析软件排查系统故障点，并确定合理的性能优化步骤。其基本的指导原则为，通过尽可能少的磁盘访问获取所需要的数据(常规的调优策略如图1所示)。数据库系统外的应用优化通常涉及源代码和SQL语句的调整。比较而言，源代码修改存在较高的时间成本，同时可获得的性能提升收益有限;由于应用程序对数据库的操作通常最终表现为SQL语句对数据库的操作，因此SQL语句的优化能够以提升SQL执行效率的方式实现数据库性能的提升。

图1：数据库性能优化常规策略

每个DBA眼中都有一条数据库最佳优化路径。而企业间IT应用的天然差异是导致这一结果的根本原因。同时，数据库性能优化方法还具有浓重的行业色彩。“银行的数据库应用以短交易为主，即主要涉及银行内部的固定数据处理流程，数据库优化主要以集成式优化操作为主;而税务行业的主营业务以长交易为主，一些审批流程需要在系统外部运转，其数据库故障的定位和优化将与短交易优化操作有所区别。”牛新庄说。

王翔在分析海关数据库应用特色时指出，海关数据库应用主要集中在甲骨文和SQL Server平台，数据处理以短交易为主，强调数据交换能力，但数据总体容量不如金融、电信等行业，同时数据交换以内部为主，不存在大量用户基础对数据库系统的访问。围绕这些特性，在实际的操作中，海关IT部门的数据库性能优化操作主要围绕基于快照、单双向复制的集成式优化展开。应用优化方面，主要涉及数据库参数的合理配置、数据库端缓冲调整，以及对频繁调用应用服务的打包处理。王翔介绍，中国海关专门成立了IT优化小组，负责制定和执行包括数据库在内的IT整体优化策略。

而在行业应用内部，不同系统对数据库性能的要求也不尽相同。以电信应用为例，某省级电信公司就从实际需要出发，将计费系统和销账系统分离，各自独立承载不同的数据处理任务。之所以进行这样的划分，是由于承载原始话单采集计费系统的特点表现在用户数少、数据库连接数少，数据存储量大，磁盘I/O高，但对响应时间的要求不高;而负责缴费的销账系统面对的是柜台营业员和电信用户，用户数量多，数据库连接数量大，但数据存储量和磁盘I/O都相比计费系统小得多，同时对系统响应时间要求高，要做到不超过3秒的时间响应。考虑到两种应用对数据库资源的需求存在很大差异，采用一个数据库会导致容量过大和管理不利，而I/O数据量过大时可直接降低响应时间。出于保证应用可靠性和系统安全的需要，该电信用户最终决定在设计时对两种功能的支持系统进行了明确划分。

谈到不同品牌的数据库优化流程是否存在差异的问题时，牛新庄和王翔两位数据库专家均表示，主流关系型数据库的优化基本遵循固定的流程。在具体的操作过程中，都是通过分析数据库对CPU、内存、磁盘I/O和网络的占用情况，与具体的应用相结合做出最终的性能瓶颈定位。但是，不同类型数据库的优化则会体现出明显的差异性。王翔指出，关系型数据库和XML数据库在数据库参数配置时就会涉及完全不同的技术细节。“关系型数据库的优化主要涉及索引的合理使用、I/O改造等内容，而XML数据库的磁盘I/O表现不同，数据存储以大字段为主，与应用的结合更为紧密。针对XML特性，DBA需要运用介于数据仓库和关系型数据库之间的数据库参数进行调整。”王翔说。

设计规避风险

和其他IT基础组件一样，数据库性能下降很大一部分的风险是能够在数据库的设计阶段予以规避的。因此，设计优化也就成为了数据库性能优化技术的源头和方向，

牛新庄指出，目前企业的数据库应用普遍表现出对设计阶段优化的忽视。根据多年的行业服务经验，他表示，企业对设计优化的不够重视主要体现在，工期紧张，开发时间短，以及系统匆忙上线后未经过充分优化和测试。“数据库逻辑结构的不合理、索引设计不合理，开发阶段的技术冲突无法调适，多种因素的累积作用导致了许多数据库系统上线后不久即出现性能故障”牛新庄说。

完整的数据库性能优化周期可以分为两个阶段，一是设计与开发阶段，主要负责对数据库逻辑和物理结构的优化设计，使其在满足具体业务需求的前提下，系统性能达到最佳，同时系统开销最小;二是数据库的运行阶段，其优化手段以数据库级、操作系统级、网络级为主。比较生命周期的调优成本与调优收益曲线，我们发现性能调优的成本随软件生命周期进程而增加，但调优收益却随软件生命周期进程而减少。由此可见，数据库上线之前的早期测试和调优工作不仅是日后数据库健康运维的基础，同时也可以有效避免那些应用后期不必要或需要付出高昂代价的优化操作。

为了减少因为数据库“被动”设计而导致的性能问题，王翔所在中国海关信息中心采用了DBA主动参与项目设计评审过程的方法，及早找出数据库的设计缺陷。项目协作方面，数据库专家还会与存储专家共同规划统一集中式存储架构，依据主干业务、其他业务等应用职能对数据库应用结构进行分割，并参与确立IT基础设施的备份、监控流程，力求将数据库的存储问题、物理布局等问题“消灭”在项目设计阶段。

术业有专攻

利器善事。数据库性能优化不能缺少有着丰富经验和严密知识体系的数据库专家，同样不能缺少完整的数据库性能保障框架和专业化的优化工具。伴随着关系型数据库三十余年的稳定发展，数据库性能优化已经成为商业IT管理软件供应商繁衍生息的乐土。老牌系统管理软件厂商BMC和CA都拥有数据库优化的产品工具;同时，这一领域还催生出很多以数据库优化为主营业务的软件公司，例如分布式数据库优化的领导者Quest Software、应用性能管理厂商Precise(被VERITAS公司以6亿美元的价格收购，并随VERITAS被赛门铁克连环收购，其i3产品系列并入赛门铁克旗下)，以及提供图形化异构数据库管理工具厂商Embarcadero(相关产品及关键特性如附表所示)等。与此同时，数据库原厂商也向用户提供相关的优化工具。

“专业优化工具可以改变黑箱操作模式，为DBA呈现一张数据库实时运行状态的全息图。” Quest虹天软件(北京)有限公司高级经理田三稳说。据介绍，Quest Software的数据库优化工具Quest Central可支持甲骨文、DB2、SQL Server和MySQL平台, 能够快速诊断和解决多种数据库性能问题。通过直观的图形化用户界面，可以快速定位性能瓶颈，追溯问题根源，针对应用过程对最常见的SQL问题进行优化。Quest Central提供的自动化SQL优化机制，可以在不执行应用的前提下，通过代码扫描找出低效率查询并加以优化，消除SQL语句中的性能瓶颈。而待优化语句还会被自动重写为备份语句供DBA调整使用。

从甲骨文数据库优化起家的Quest Software，已经将其数据库性能优化产品扩展到多种关系型数据库平台。谈到以Quest为代表的专业优化软件的优势，田三稳表示，原厂商工具的局限性体现在缺乏跨平台的监控和诊断能力，而跨平台的数据库应用优化恰恰是企业的普遍需求。他坦言Quest Software正面临着来自原厂商工具的竞争。“随着甲骨文数据库的不断升级，它所附带的优化工具也开始提供一些与我们类似的功能，同时价格更低，但我们的优势是对跨平台数据库环境的透明支持，我们为客户提供了搭建集成化通用数据库性能优化平台的技术和方案”他说。他同时强调，与同类厂商相比，Quest Software的特色之处包括，具有亲和力的图形化诊断界面、独特的表空间重组技术、完善的底层专家知识库、自动化SQL优化以及对系统性能的实时诊断能力。

Quest Software拥有自己的数据库性能优化方法论，由监控、诊断和问题解决三个连贯的环节所构成，在兼容用户个性化管理需求的同时，可以为客户构建集中式、跨平台的数据库管理解决方案。目前，其优化工具已经在北京移动、上海移动、北京地税、北京电力、山西网通、海关总署、中国工商银行、东芝复印机等客户环境中得到部署。

一线数据库专家对专业优化软件持有自己的看法。牛新庄就指出，这些软件的主要功能是监控，能够定位问题却不能进行调整，当最后发现性能故障与应用或数据库设计有关后，还是需要DBA做出手工调整。在现阶段，市场上的专用软件仍无法替代数据库专家手中基于脚本的定制优化工具;海关的王翔则表示仍然习惯于脚本操作方式，大部分的数据库并没有安装图形化管理界面。“甲骨文的Web监控工具在实际的操作中还是不够实用，对于DBA来说，管理工具越轻量级约好。”王翔说。而很多DBA没有采用专用软件还有一个原因，就是在系统宕机时，这些工具是无法使用的，DBA必须通过脚本语句查看数据库内部状况。

针对DBA对手工操作和脚本方式的偏爱，田三稳表示，专用工具的很大一部分价值体现在对性能故障的预见和主动管理能力，以Quest Software工具为例，它既提供事先预警机制，还提供实时诊断、历史回放和性能参数的分析报告功能。“数据库高手可以凭经验或编写脚本来解决问题，但大部分中小企业的DBA并不具备这样的能力。Quest可以为这些企业提供一个功能齐全、使用方便的数据库监控管理平台，帮助他们建立起性能管理机制。”他说。他同时指出，一些企业具有非常高的IT审计要求，限制使用手工编写管理脚本或对数据库进行修改，这时专业工具的优势就显现出来。另外，在发现空间问题、空间重组和容量规划等数据库存储优化领域，Quest等工具也具备预防性维护和问题预测的能力。

经验、工具和全局观是做好数据库性能优化必不可少的三要素。今天的数据库性能优化不再是一个狭义的话题，当我们越来越深入其中，就会发现其覆盖了相当广阔的技术和管理领域。数据库应用的复杂性决定了DBA智慧和专用工具的协同作战将成为未来应用的方向，而作为一个垂直的优化流程，数据库性能优化将与新一代的IT管理框架实现更加透彻和更深层次的融合。

编看编想

这是个不断变化的话题，因为在IT应用快速进化的今天，数据库的职能和在IT系统架构中的角色定位在不停地变化着。这是我们仍会感觉这个话题如此鲜活而又充满探索可能的原因。

对每个DBA而言，这个话题所覆盖的庞大技术疆域都是极具诱人和挑战性的。在经验和专用工具之间，DBA们需要找到一条能够最快速发现问题和解决问题的路线图。必须承认，我们真的很难为这种处在不断变化中的技术应用绘制一幅“百战百胜”的路线图，但是可以针对可能出现的数据库故障建立相对固化的处理流程。所以，在DBA的脑海中，这幅路线图不一定有多么清晰或严谨，但它必须能够在你遇到问题时指引你该如何行动。

从某种意义上说，数据库性能优化是一项没有尽头的任务，因为用户对数据库性能的要求没有止境。在SOA时代，这一切会改变吗?很难预测重大架构变革所引发的具体技术的联动效应，但可以肯定的是，SOA框架下的数据库性能优化所面对的挑战比今天毫不逊色。王翔表示，SOA所强调服务自治性，是原有性能调优技术非常适用的;而在SOA的交互方面，应用对于服务编排和XML数据处理在交互过程中的重要性将进一步凸现，DBA需要根据应用“补补课”。

当数据库变身为数据服务，在成为独立服务的同时还要服务于众多的服务节点，这种超越以往的应用复杂性要求DBA刷新自己的知识体系、专用工具提供的管理功能更加精细化，同时也要求实践者在这个前所未有的开阔视野下，从崭新的战略全局观突破性能瓶颈。

数据库优化创新 篇5

一般数据分页方式有：

2.1.1、客户端(应用程序或浏览器)分页

将数据从应用服务器全部下载到本地应用程序或浏览器，在应用程序或浏览器内部通过本地代码进行分页处理

优点：编码简单，减少客户端与应用服务器网络交互次数

缺点：首次交互时间长，占用客户端内存

适应场景：客户端与应用服务器网络延时较大，但要求后续操作流畅，如手机GPRS，超远程访问(跨国)等等。

2.1.2、应用服务器分页

将数据从数据库服务器全部下载到应用服务器，在应用服务器内部再进行数据筛选。以下是一个应用服务器端Java程序分页的示例：

List list=executeQuery(“select * from employee order by id”);

Int count= list.size;

List subList= list.subList(10, 20);

优点：编码简单，只需要一次SQL交互，总数据与分页数据差不多时性能较好。

缺点：总数据量较多时性能较差。

适应场景：数据库系统不支持分页处理，数据量较小并且可控。

2.1.3、数据库SQL分页

采用数据库SQL分页需要两次SQL完成

一个SQL计算总数量

一个SQL返回分页后的数据

优点：性能好

缺点：编码复杂，各种数据库语法不同，需要两次SQL交互。

oracle数据库一般采用rownum来进行分页，常用分页语法有如下两种：

直接通过rownum分页：

select * from (

select a.*,rownum rn from

(select * from product a where company_id=? order by status) a

where rownum<=20)

where rn>10;

数据访问开销=索引IO+索引全部记录结果对应的表数据IO

采用rowid分页语法

优化原理是通过纯索引找出分页记录的ROWID，再通过ROWID回表返回数据，要求内层查询和排序字段全在索引里。

create index myindex on product(company_id,status);

select b.* from (

select * from (

select a.*,rownum rn from

(select rowid rid,status from product a where company_id=? order by status) a

where rownum<=20)

where rn>10) a, product b

where a.rid=b.rowid;

数据访问开销=索引IO+索引分页结果对应的表数据IO

实例：

一个公司产品有1000条记录，要分页取其中20个产品，假设访问公司索引需要50个IO，2条记录需要1个表数据IO。

那么按第一种ROWNUM分页写法，需要550(50+1000/2)个IO，按第二种ROWID分页写法，只需要60个IO(50+20/2);

2.2、只返回需要的字段

通过去除不必要的返回字段可以提高性能，例：

调整前：select * from product where company_id=?;

调整后：select id,name from product where company_id=?;

优点：

1、减少数据在网络上传输开销

2、减少服务器数据处理开销

3、减少客户端内存占用

4、字段变更时提前发现问题，减少程序BUG

5、如果访问的所有字段刚好在一个索引里面，则可以使用纯索引访问提高性能。

缺点：增加编码工作量

由于会增加一些编码工作量，所以一般需求通过开发规范来要求程序员这么做，否则等项目上线后再整改工作量更大。

如 果你的查询表中有大字段或内容较多的字段，如备注信息、文件内容等等，那在查询表时一定要注意这方面的问题，否则可能会带来严重的性能问题。如果表经常要 查询并且请求大内容字段的概率很低，我们可以采用分表处理，将一个大表分拆成两个一对一的关系表，将不常用的大内容字段放在一张单独的表中。如一张存储上 传文件的表：

T_FILE(ID,FILE_NAME,FILE_SIZE,FILE_TYPE,FILE_CONTENT)

我们可以分拆成两张一对一的关系表：

T_FILE(ID,FILE_NAME,FILE_SIZE,FILE_TYPE)

T_FILECONTENT(ID, FILE_CONTENT)

数据库优化创新 篇6

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near “EXTENDED” at line 1 ( 1064 )

因不影响正常使用，也就没太在意。今日偶然想起，打开 PHPWind 程序的此文件，解决了问题，现分享方法如下。

打开“安装目录/admin/repair.php文件”，将下面一行中的 EXTENDED 删除：

$query = $db->query(“OPTIMIZE TABLE $tableEXTENDED”);

参考了相关资料，EXTENDED 参数用在 MySQL 数据库修复数据表时(只对MyISAM和ARCHIVE类型的表有效)，起逐行重建索引的效果，同样的参数有：

QUICK：最快的选项，只修复索引树，

管理资料

EXTENDED：最慢的选项，需要逐行重建索引。

USE_FRM：只有当MYI文件丢失时才使用这个选项，全面重建整个索引。

我也是知其然不知其所以然，抱着试一试的想法去掉 OPTIMIZE 一行中的 EXTENDED 参数，一测试竟然好了。

难道 OPTIMIZE TABLE 不支持 EXTENDED 参数?希望熟悉的朋友留言告诉我一下，我的数据库版本是 5.0.67，谢谢!

作者：匪际

分析数据库优化技术 篇7

一、良好数据库性能的标准

对于同一个系统的实施可以设计出多个数据库模型, 但是, 这些模型由于性能目标的差异而显示出不同的效果。而且, 对于同一需求、不同数据库的设计人员来说, 也会设计出不同的模型。其中, 数据库性能的高低一般用两个方面的指标来衡量:响应时间和吞吐量。而且, 响应越快, 吞吐量越大, 数据库性能越好。下面是一般大型系统数据库的性能标准: (1) 单条记录的更新应当在1秒之内。而多条记录的更新不超过10秒。 (2) 对于少于4个表的数据有一定限度的查询应在5秒内完成。 (3) 对于有一定限度的查询多表查询应在10秒内完成。但是, 整个表的查询时间应在30秒内完成。

二、数据库优化应遵循的方法

数据库优化是指进行有目的地调整组件及改善性能, 使得数据库的吞吐量增加, 减少相应处理时间。下面是数据库性能优化所遵循的一些方法:1、设立合理的性能目标。在优化之前, 需要确定专门合理的目标。而且, 设立目标最重要的一点是可量化和可达到。其中, 可量化是指在量化中需要的性能值。而可达到是指必须定义当前性能指标。2、确定影响数据库性能的瓶颈。当数据库运行了一段时间后, 会发生性能低下, 此时不能猜测并随便做一些更改, 这可能造成更大的瓶颈或资源浪费。3、弄清影响数据库性能的因素。由于改善数据库性能所采用的方法都可能带来严重的负面影响, 因此在达到预定目标时, 应停止所有的工作。

三、数据库优化技术的方法

数据库优化技术的方法有很多, 而且, 不同的数据库又有不同的方法。下面具体列出几种主要的技术方法。

1、数据库服务器内存空间的分配。

足够的内存可以加快数据库的运行速度和提高CPU的利用率。而且, 内存不够的话将会严重降低CPU的利用率。

2、合理的物理存储路径。

数据库在处理海量数据时, 首先要考虑物理存储路径。其中, 物理存储路径主要包括:数据在磁盘组上的分布状态、索引文件的组织、日志文件的分布等。而且, 数据在磁盘组上的分布有几种方法:静态数据与业务数据相分离。其中, 数据库中的静态数据主要是一些数据字典, 这些数据修改的频率比较低, 但是, 查询率较高。其中, 使用索引有助于快速访问表中的数据, 它可以大大减少找到特定数据行所需的I/O操作。设计索引时应遵循如下原则: (1) 在建立索引时, 如果对一个经常被更新的列建立索引, 则会严重影响数据库性能。一张表的索引过多会影响该表的更新性能, 因为一旦发生更新行为, 该表所有的索引都必须作相应的调整, 这就会延误运行时间。 (2) 对小型表不必建立索引, 因为对于小表来说直接扫描往往更快而且维护费用低。 (3) 对重复值非常大的列, 应建立位图索引, 不要建立普通索引。因为为这样的列建立普通索引, 其查询效率不高, 反而增加索引的维护量。

3、使用SQL语句的优化技术来提高数据库运行效率。

SQL语句的运用可以大大优化数据库的性能。一个良好的应用程序允许数据库支持上万个并发用户, 由于网络上的传输是会话式的传输, 在数据库与客户端之间传送每个批处理和结果集, 为了减轻客户端与数据库系统间过量的网络传输, 必须采用大型数据库所提供的存储过程和触发器来最小化信息的往来传输, 以减轻网络I/O的负载。

4、其他策略。

随着Internet的飞速发展, 人类对信息管理和信息交换的需求更是空前强烈和迫切, 使得已在传统的商业处理领域内趋于成熟的数据库技术面临着许多新的问题和挑战。

四、结束语

在这个不断发展与进步的时代中, 数据库的优化是一个系统工程。而且, 在数据库实施的过程当中, 影响其性能优良的因素有很多。并且, 不同项目的应用要求又各不相同, 这就使得我们要不断找出完全通用的优化技术, 但是, 需要注意的是, 要想把所有的通用技术完全找到是不现实的。因此, 在数据库开发和维护的过程中, 我们必须要针对数据库运行的具体情况加以分析和调整。

摘要：数据库的优化是指通过对数据库参数、网络、硬件、操作系统和应用程序的优化来避免存储器I/O瓶颈、提高CPU利用率和减少资源竞争。其中, 数据库的优化是一个非常复杂的问题, 因为, 这不仅需要潜心研究数据库的理论知识, 还需要数据库系统的实践经验。因此, 本文将针对数据库的各种优化技术进行分析与研究。

关键词：数据库,优化,技术

参考文献

[1]童亚凤, 王庆君.数据库的查询优化策略.计算机应用.2009

数据库优化创新 篇8

关键词：Oracle；数据库；性能优化

中图分类号：TP311.138 文献标识码：A 文章编号：1006-8937（2015）15-0073-02

Oracle是一种大型的关系数据库，在多个行业中都得到较好的应用，并是一个重要的数据库平台。随着Oracle的不断应用，其规模也有所扩大，使用的人数不断增加，在这个过程中，Oracle数据库存在的问题也越来越明显。工作人员对这种数据库进行优化，让其能够在合理的条件下，更好的发挥作用，优化系统的使用性能，降低系统的支出，为数据库的推广奠定了良好的基础。

1 性能优化目标

1.1 缩短系统响应时间

该数据库的系统响应时间是指在SQL语句到数据库结果集时所用的时间。相关人员可以适当缩短这个时间，从而降低系统的服务时间，让人们的等待时间减短。该时间单位一般用ms表示，这种做法能够减小处理用户请求的时间，由此提高系统的利用效率。

1.2 提升吞吐量

数据库的吞吐量会受到SQL语句的影响，数据库能够完成的SQL语句数量越多，那么在单位时间内，该吞吐量越大。吞吐量=SQL语句数量/时间，其单位用TPS表示。相关人员要想提高数据库的吞吐量，可以增加单位时间处理SQL语句的数量。

1.3 提升数据库指标命中率

相关人员要制定数据库指标，例如缓冲区的命中率、软解析率等。在数据库工作中，最常用的指标是高速缓冲区命中率，这种指标主要是衡量Oracle数据库的性能，相关人员结合这种情况进行分析。

1.4 优化磁盘

Oracle数据库将数据存储在磁盘和内存中，这种过程与I/O操作有关，所以要合理规划磁盘，通过高速缓存技术，增加系统的吞吐量，从而在一定程度上缩短用户的响应时间，多使用系统内存，避免使用磁盘I/O进行操作。

1.5 合理的应用内存

在大量并发用户的影响下，如果Oracle数据库的存储量不够，会影响程序的处理效率。相关人员要尽量缩短数据库的响应时间，然后确保内存得到合理应用，判断最大回报和最小损失的标准，通过内存的有效使用，提高系统的性能。

1.6 减少磁盘的排序

如果用户提交的SQL语句中有排序或聚合函数，那么要保证这些排序可以在内存上进行，也可以在物理磁盘上。系统的物理磁盘有独特的结构，所以其读写速度比内存读写速度慢，所以相关人员要尽量减小物理操作。

2 影响因素分析

很多因素都会影响Oracle的性能，例如操作系统或CPU性能等，所以相关人员合理设置这些具体方面，降低其对数据库性能的影响。

①在操作系统上，Oracle数据库与系统的服务器运行有非常密切的联系，如果操作系统没有合理设置就会导致Oracle性能的降低。

②CPU占用过高：在系统运行中，CPU是非常关键的资源。如果该资源被占用，那么很可能导致整体数据库的停止运行。

③内存没有合理分配：Oracle性能会受到内存配置的影响，内存分配不合理会导致计算机减少系统的缓冲控制，操作系统频繁转换。

④I/O冲突：因为在系统运行中，磁盘在同一时间段只能满足一个进程的需求，所以当拥有多个进程，就会造成读写冲突，从而降低整个系统的运行速度。

⑤SQL常见错误：应用Oracle数据库，有大量的SQL语句，相关人员容易出现配置和数据迁移的错误。经过长时间的全表扫描，数据库没有得到合理的设置，I/O没有合理规划，SQL语句执行效率较差。

3 优化技术

3.1 数据库优化

应用Oracle数据库中，增加索引是最常见的调优方法，数据库对象是索引。相关人员应充分利用索引对系统中的扫描情况进行描述，通过查询索引能够节省大面积描述。在设置索引内容时，要重视SQL语句的使用，具体情况要结合查询条件。相关人员要比对直接全表的检索情况，然后通过相关数据对I/O进行分析。

工作人员可以完善数据库的数据，掌握这个逻辑关系，能够在数据库使用时，让代码和其他信息分离，这种做法能够有效降低网络的传输量，并提高数据情况的执行能力。相关人员在进行数据存储的过程中，用户可以发出执行命令，并提交SQL语句，从而节省对该语句的分析，充分使用SQL共享池的优势。

3.2 内存优化

Oracle数据库的信息主要存储在内存和磁盘上，从实际应用来看，内存的访问量比较大，明显高于磁盘的访问量。但是这种情况会降低数据库的响应时间，减慢其运行速度，所以相关人员要设置合适的内存尺寸，确保数据库性能得到更好的提升。

例如，相关人员要优化数据缓冲区的高速缓存性能，从而降低系统磁盘中的I/O数据，通过适当对缓冲区尺寸进行调整，能够让缓冲区找到需要的数据，从而对数据库的性能进行优化，减小用户的等待时间和缓冲时间。相关单位可以通过减小全表扫描的方式，得到优化数据库性能的目的。相关人员可以用索引的方式，降低全表扫描的次数，应用全表扫描的次数越少，系统的缓冲命中率越高。

提高共享池性能，能够较快的提高数据库性能。共享池是存放近期使用SQL语句的地方，共享池内的数据字典数据比缓冲区的内存停留时间更长，拥有更好的命中率。所以可以优先度缓冲区进行调整，相关人员可以根据实际情况对每个节点的共享池大小进行记录和分析，从而有利于下一步调整。利用代码重新书写能够快速提高共享池的命中率。针对比较大的对象，例如自定义的程度等，相关人员需要应用共享池，进行有效的解析。相关人员要将重要的对象保存在内存中，这样就能够提高共享池的性能。

3.3 磁盘优化

应用Oracle数据库使用对象产生I/O的机会较多，所以相关人员要将访问量较大的数据文件放置在磁盘中，不同的对象要尽量分开放置，从而为索引创造有利条件。相关人员要注意内存中修改过的数据并不是写入到数据文件中，所以要优先将其写入到日志文件中，并保持其容量。在这个过程中，相关人员应减少对不同对象对磁盘的竞争，合理将日志文件进行分组，一组写满后再换到下一组，这个过程要循环进行。在数据库中，要创建回滚段和其专用的表空间，其中从系统操作失败后得到的恢复数据是回滚段，所以应尽量减小I/O进程之间的竞争，并确保空间竞争能够有效完成。

3.4 SQL优化

SQL语句的执行效率会影响Oracle数据库的性能，所以优化SQL语句能够直接提高Oracle系统执行效率。执行SQL会消耗数据库系统70%-85%的资源，所以合理设计SQL语句非常重要，从而提高系统的利用效率，优秀的SQL语句，能够加快执行的速率，降低网络传输的频率，从而充分发挥数据库的性能。

4 结 语

通过上文对Oracle数据库性能优化研究，可以得出，Oracle数据库规模的增大和用户的增加，该数据库中隐藏的问题会逐渐暴露出来，所以相关人员要对数据库的性能进行优化，并不断调整数据库的各个方面。在这个过程中，要充分掌握数据库系统的性能影响因素，然后针对这些因素，进行合理优化，采用先进的技术调试数据库，从而使系统性能更加优化，为用户提供更多便利。

参考文献：

[1] 郭霞.基于Oracle数据库性能优化技术研究[J].电脑知识与技术，2011，（24）.

[2] 魏亚楠，宋义秋.oracle数据库应用系统的性能优化[J].制造业自动化，2010，（8）.

[3] 戴伟敏.Oracle数据库系统性能优化与调整[J].赤峰学院学报（自然科学版），2010，（12）.