数据库性能的优化

数据库性能的优化（通用12篇）

数据库性能的优化 篇1

摘要：本文主要讨论在系统分析设计及开发阶段, 如何进行数据库优化, 以充分发挥数据库的性能。

关键词：数据库,性能,优化

随着计算机技术在各个领域的广泛应用, 以及计算机硬件性能的不断提升, 软件系统由最初满足业务的单一需求与功能, 向着全面支撑企业生产管理各个环节, 导致系统朝着复杂化、大型化的方向发展。大部分的系统运行离不开数据库的支撑, 数据库系统的性能是信息系统高效运转的前提和保证。影响数据库应用性能的因素很多, 既有软件方面的因素, 也包括数据库运行的硬件环境、网络环境、数据库管理和维护方面的因素等。

一、在设计阶段进行数据库性能优化的意义

信息系统需要经历需求分析设计、开发测试、上线维护与下线三个阶段。在软件生命周期的系统分析设计与开发阶段是数据库应用优化的最佳阶段, 能以最小代价收获最大的性能效益, 而在系统上线后的维护阶段来进行调优则要花费更多的精力和代价, 往往需要修改代码甚至暂停系统来进行优化, 且性能的优化效果也不十分明显, 这个阶段的优化不仅存在时间成本也容易造成其他业务问题, 影响用户的体验。因此数据库性能优化通常在设计阶段进行。

二、数据库性能优化的策略

为了充分利用数据库的功能特性, 在系统分析与设计阶段, 数据库设计人员需要根据系统特点, 确认哪些数据表频繁查询、频繁修改或只写入而偶尔进行查询的表, 同时评估每个表数据量大小、周期增加量、访问量等信息作为数据库建库输入信息, 作为初始参数、表空间及建表策略。设计规划阶段常采用以下几个策略:

(一) 表数据和索引数据分开存储, 各自使用独立的表空间:

由于表数据与索引数据存放在相同表空间时, 当应用程序对表进行读写操作时数据与索引的I/O操作将产生资源竞争, 将降低了数据库的性能。故需要将表数据与索引数据分别存放在不同的表空间, 并在物理层面将不同类型表空间的数据文件存在不同的物理磁盘上, 以避免资源竞争。

(二) 表分区的使用:

系统中经常存在一些特别大的表且在日常业务处理过程增长量非常大, 当表增长到一定程度后, 查询数据的速度将会非常慢, 这时需要对表进行分区管理, 表分区后, 逻辑上还是一张完整的表, 只是将表中的数据在物理上存在多个表空间, 这样查询数据不需要进行全表扫描。且分区还能增强表的可用性、方便维护, 如果某个分区出现故障时, 其他分区的数据还能使用, 且可以针对单个分区数据修复迁移。

(三) 内存表的表使用:

计算机系统的性能瓶颈在硬盘的读写速度, 数据库系统进行表数据操作时均是先将硬盘中的数据先读入内存然后在进行操作, 故数据库的性能验证依赖于硬盘的读写速度。目前很多数据库均提供将表数据常驻内存的功能, 故如果系统中存在一些频繁操作的表, 在系统的内存空间允许的情况下可以将表建成内存, 以提升数据访问速度。如:oracle数据库可以通过ALTER TABLE tablename CACHE。

三、优化SQL语句在数据库系统性能优化中的重要作用

SQL语句优化对数据库系统的性能起着决定性的作用, 因此在开发过程中如果不注意SQL语句在程序中混入执行效率比较低脚本, 将会对数据库性能造成较大影响, 效率低下的脚本可能造成整个数据库系统宕机。故系统开发时需要每个开发成员对数据库SQL脚本编写规范进行宣灌并在测试过程中对所有的SQL进行检查, 所有脚本均需要严格按照以下几个原则:

(一) 每个数据库连接均有与之对应的断开:

数据库为了保存良好性能都对数据库连接数进行了限制, 如果大量数据库连接长时间连接未释放, 当数据库的连接数接近或达到数据库最大连接数时, 新数据请求将会长时间排队造成访问失败且存在数据库宕机的风险。故程序中数据库建立连接与断开连接需一一对应, 并且程序中尽量使用较少的数据库连接或者数据库连接池以节省数据库的连接。

(二) 避免长事务:

应用系统进行大批量数据插入或删除操作时容易产生长事务, 长事务会消耗大量的数据库资源, 并造成数据库访问速度缓慢。为了避免长事务, 可以对事务进行分割处理。对于一个由一组小事务顺序操作组成的大事务 (如:银行交易系统的日终处理、电信运营商的每月计费处理) , 可以由一系列的事务完成整个事务, 但其缺点是有可能因整个事务太大而使不能完成。为了避免由单个事务处理异常导致整个事务回滚, 在系统开发设计需要对事务进行流程控制, 每个小事务进行单独提交事务并记录断点, 这样单个事务失败时只需要根据断点开始执行后续的事务的, 不需要对整个任务进行重新执行。这样可以避免长事务, 也可以节省执行时间并便于问题跟踪。

(三) 使用相同的数据库编写规则:

为了不重复解析相同的SQL语句, 在第一次解析后, 数据库会将SQL语句存放在内存中, 当有新脚本需要执行时, 数据将脚本跟与内存中已存在的脚本进行比较, 如果存在相同的脚本, 则根据解析过的脚本直接执行, 否则需要重新解析语句并将语句添加至内存中。故重复执行内存中的语句能提升脚本的执行速度, 因此整个系统的脚本编写规则需保持一致。

(四) 批量处理数据查询与修改操作:

对于同一张表顺次查询大量数据 (几十万、几百万甚至千万条记录) 时 (电信的月租计算、话单统计等均需要顺序查询大量数据) , 如果一条数据进行查询输出将消耗大量资源且查询效率低下, 这种情况下可以使用批量处理, 如每次查询fetch出一批数据 (如:500条记录) , 这样可以大大提升数据库的读写速度。同样顺序写入或修改多条数据时, 也可以使用批量语句进行操作, 这样比每次单条执行顺序提交速度快得多。同时批量执行也将大大减少数据库的压力, 提升了数据库的性能。

(五) 避免全表扫描:

全表扫描是指连续从表中将所有数据读出, 不论查询一条记录还是整个表的数据, 全表扫描将会把整张表从硬盘中读出来后进行逐一过滤。由于全表扫描没有选择性造成其读出的数据将在短时间内就从SQL缓冲区中移走。所以基于数据库脚本优化方面考虑, 在程序开发中需要避免出现以下几种SQL语句:

(1) 表无索引或查询时索引未使用;

(2) 对返回的记录无任何限定条件 (如没有Where条件语句)

(3) 对数据表查询时表存在索引, 但查询条件不合理造成无法索引无法使用。如:在CUST表中存在一个由cust_id、cust_type、state字段的复合索引 (索引的第一个字段是cust_id) , 那么查询条中只出现cust_type与state字段但未出现cust_id, 时, 不能使用索引。

(4) 使用索引字段作为查询条件时, 条件表达式中使用了NULL或者是不等号, 如限定条件为cust_id is not null或者cust_id<>1时, 索引将无法使用到。

(5) 查询条件中使用索引主字段, 但条件在表达式中使用, 如:主索引字段为cust_id, 条件为cust_id=‘134667’时, 能使用上索引, 但限定条件为where substr (cust_id, 1, 3) =13, 则不会使用cust_id字段上的索引, 由于cust_id字段在substr函数里。如果将cust_idz字段与文本字符串结在一起, 也无法使用索引。

(六) 索引的合理使用:

索引是提高数据库读写效率最有效的方法之一, 索引将表中对记录按照一个或者多个字段进行排序的一种方式进行存储, 且不会改变表原来的物理结构。对经常作为Where条件子句的列创建索引, 直接访问特定的数据列, 这样减少数据存取时间。一个建有合理索引的数据库应用系统能比一个没有建立索引的数据库应用系统效率提高一个数量级。但并不是索引越多越好, 索引也有空间开销, 建立的时候也需要消耗一定时间, 且进行Insert、Delete和Update*作时也有维护代价。

结束语:在设计阶段通过对系统各种指标预估与规划来选用合适的硬件系统, 规划数据库逻辑存储结构与物理存储结构设计进行优化;在开发阶段通过给出详细的数据库脚本编写规范, 以提升数据库的脚本执行效率, 减少系统的开销, 以保证系统运行的整个生命周期的优良性能。

数据库性能的优化 篇2

引言

DB2是一种高性能的大型关系数据库管理系统，广泛的应用在客户/服务器体系结构中。评价系统性能优化的标准有：吞吐量、响应时间、并行能力等。本文从数据库的设计、查询的优化、并发控制以及客户/服务器模式这四个角度来讨论优化系统性能。

设计数据库

1. 熟悉业务系统

对业务系统的熟悉程度对整个数据库系统的性能有很大影响，一个对业务不熟悉的设计人员，尽管有丰富的数据库知识，也很难设计出性能最佳的数据库应用系统。

2. 规范化与非规范化

数据库被规范化后，减少了数据冗余，数据量变小，数据行变窄。这样DB2的每一页可以包括更多行，那么每一区里的数据量更多，从而加速表的扫描，改进了单个表的查询性能。但是，当查询涉及多个表的时候，需要用很多连接操作把信息从各个表中组合在一起，导致更高的CPU和I/O花销。那么，有很多时候需要在规范化和非规范化之间保持平衡，用适当的冗余信息来减少系统开销，用空间代价来换取时间代价。有订单信息表OrderDetail，它里面记录了投递员信息，收款员信息，物品信息，价格策略，客户信息…..这些信息分别在投递员信息表、收款员信息表、物品信息表、价格策略表、客户信息表中存放。如果按照规范化的要求，OrderDetail查询时就必须要与这么多个表进行连接或者嵌套查询。如果OrderDetail表中的数据量是在百万级的，那么一次查询所需要的时间可能会达到好几个小时。事实上，只要在设计时保证数据的逻辑有效性，很多信息都可以直接冗余在OrderDetail表中，这些冗余的数据能够极大的提高查询的效率，从而减少CPU和I/O操作。

3. 数据条带化

如果一个表的记录条数超过一定的规模，那么最基本的查询操作也会受到影响，需要将该表根据日期水平划分,把最近、最经常用的数据和历史的、不经常用的数据划分开来，或是根据地理位置、部门等等进行划分。还有一种划分方式DD垂直划分，即把一个属性列很多的表分割成好几个小表，比如把经常用到的属性放在一个表里，不经常用到的属性放在另一个表里，这样可以加快表的扫描，提高效率。

4. 选择数据类型

对每一属性选择什么样的数据类型很大程度上依据表的要求，但是在不违背表要求的前提下，选择适当的数据类型可以提高系统性能。比如有text列存放一本书的信息，用BLOB而不是character(1024)，BLOB存放的是指针或者文件参照变量，真正的文本信息可以放在数据库之外，从而减少数据库存储空间，使得程序运行的速度提高。DB2提供了UDT(User Defined Datatypes)功能，用户可以根据自己的需要定义自己的数据类型。

5. 选择索引

索引是数据库中重要的数据结构，它的根本目的就是为了提高查询效率。现在大多数的数据库产品都采用IBM最先提出的ISAM索引结构。使用索引可以快速、直接、有序的存取数据。索引的建立虽然加快了查询，另一方面却将低了数据更新的速度，因为新数据不仅要增加到表中，也要增加到索引中。另外，索引还需要额外的磁盘空间和维护开销。因此，要合理使用索引：

●在经常进行连接，但是没有指定为外键的属性列上建立索引。

●在频繁进行排序或分组(即进行group by或order by操作)的列上建立索引。按索引来排序或分组，可以提高效率。

●在条件表达式中经常用到的不同值较多的列上建立检索，在不同值少的列上不要建立索引。

●如果待排序的列有多个，可以在这些列上建立复合索引(compound index)，即索引由多个字段复合而成。

查询优化

现在的数据库产品在系统查询优化方面已经做得越来越好，但由于用户提交的SQL语句是系统优化的基础，很难设想一个原本糟糕的查询计划经过系统的优化之后会变得高效，因此用户所写语句的优劣至关重要。下面重点说明改善用户查询计划的解决方案。

1. 排序

在很多时候，应当简化或避免对大型表进行重复的排序。当能够利用索引自动以适当的次序产生输出时，可以避免排序的步骤，当以下的情况发生时，排序就不能省略：

●索引中不包括一个或几个待排序的列;

●group by或order by子句中列的次序与索引的次序不一样;

●排序的列来自不同的表。

为了避免不必要的排序，就要正确地增建索引，合理地合并数据库表，尽管有时可能影响表的规范化，但相对于效率的提高是值得的，

如果排序不可避免，那么应当试图简化它，如缩小排序列的范围等。

2. 主键

主键用整型会极大的提高查询效率，而字符型的比较开销要比整型的比较开销大很多，用字符型数据作主键会使数据插入、更新与查询的效率降低。数据量小的时候这点降低可能不会被注意，可是当数据量大的时候，小的改进也能够提高系统的响应速度。

3. 嵌套查询

在SQL语言中，一个查询块可以作为另一个查询块中谓词的一个操作数。因此，SQL查询可以层层嵌套。例如在一个大型分布式数据库系统中，有订单表Order、订单信息表OrderDetail，如果需要两表关联查询：

SELECT CreateUserFROM Order WHERE OrderNo IN( SELECT OrderNoFROM OrderDetail WHERE Price=0.5)

在这个查询中，找出报纸单价为0.5元的收订员名单。下层查询返回一组值给上层查询，然后由上层查询块再根据下层块提供的值继续查询。在这种嵌套查询中，对上层查询的每一个值OrderNo，下层查询都要对表OrderDetail进行全部扫描，执行效率显然不会高。在该查询中，有2层嵌套，如果每层都查询1000行，那么这个查询就要查询100万行数据。在系统开销中，对表Order的扫描占82%，对表OrderDetail的搜索占16%。如果我们用连接来代替，即：

SELECT CreateUserFROM Order,OrderDetailWHERE Order.OrderNo=OrderDetail.OrderNo AND Praice=0.5

那么对表Order的扫描占74%，对表OrderDetail的搜索占14%。

而且，一个列的标签同时在主查询和where子句中的查询中出现，那么很可能当主查询中的列值改变之后，子查询必须重新查询一次。查询嵌套层次越多，效率越低，因此应当尽量避免子查询。如果子查询不可避免，那么要在子查询中过滤掉尽可能多的行。

4. 通配符

在SQL语句中，LIKE关键字支持通配符匹配，但这种匹配特别耗费时间。例如：SELECT * FROM Order WHERE CreateUser LIKE ‘M_ _ _’ 。即使在CreateUser字段上建立了索引，在这种情况下也还是采用顺序扫描的方式，Order表中有1000条记录，就需要比较1000次。如果把语句改为SELECT * FROM Order WHERE CreateUser >’M’ AND CreateUser <’N’，在执行查询时就会利用索引来查询，显然会大大提高速度。

5. distinct

使用distinct是为了保证在结果集中不出现重复值，但是distinct会产生一张工作表，并进行排序来删除重复记录，这会大大增加查询和I/O的操作次数。因此应当避免使用distinct关键字。

6. 负逻辑

负逻辑如!=、、not in等，都会导致DB2用表扫描来完成查询。当表较大时，会严重影响系统性能，可以用别的操作来代替。

7. 临时表

使用临时表时数据库会在磁盘中建立相应的数据结构，因为内存的访问速度远远大于外部存储器的访问速度，在复杂查询中使用临时表时，中间结果会被导入到临时表中，这种磁盘操作会大大降低查询效率。另外，在分布式系统中，临时表的使用还会带来多个查询进程之间的同步问题。所以，在进行复杂查询时最好不要使用临时表。

8. 存储过程

DB2中的Stored Procedure Builder可以产生存储过程，运行并测试存储过程。存储过程可以包含巨大而复杂的查询或SQL操作，经过编译后存储在DB2数据库中。用户在多次使用同样的SQL操作时，可以先把这些SQL操作做成存储过程，在需要用到的地方直接引用其名字进行调用。存储过程在第一次执行时建立优化的查询方案，DB2将查询方案保存在高速缓存里，以后调用运行时可以直接从高速缓存执行，省去了优化和编译的阶段，节省了执行时间，从而提高效率和系统利用率。

最优的查询方案按照某些标准选择往往不可行，要根据实际的要求和具体情况，通过比较进行选择。DB2提供的Query Patroller可以对不同的查询方案的查询代价进行比较，通过追踪查询语句，返回查询不同阶段的系统开销，从而作出最佳选择。DB2提供的Performance Monitor也对整个数据库系统的性能进行监控，包括I/O时间、查询次数、排序时间、同步读写时间等等。

数据库系统的并发控制也能影响系统性能。多个用户的同时操作可能导致数据的不一致性，DB2为了防止同时修改造成数据丢失和访问未被提交的数据，以及数据的保护读，采用Lock机制来实现控制。

DB2中可以对表空间、表、表列和索引加锁。锁的粒度越大，锁越简单，开销小，并发度低;粒度小，锁机制复杂，开销大，并发度高。大型系统在并发处理中如果遇到所要分配的资源处于锁定状态，系统会把进程挂起等待。如果一个很耗时的查询操作工作于一个经常使用的表上，此时使用表一级锁，意味着整个系统都要等待你的查询结束以后才能够继续运行。所以在复杂查询中，尽量避免使用表一级锁。如果有这一类的需要该怎么办呢?可以利用视图来解决这一类问题。视图避免了对表的直接操作，同时有能够保证数据库的高效运转。

(责任编辑：铭铭 mingming_ky#126.com TEL：(010)-68476636)

数据库性能的优化 篇3

关键词：数据库应用系统；性能；设计；优化

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

The Performance Design Optimization Strategies

of Database Application System

Lin Shubin

(Agricultural School of Zhangzhou City,Zhangzhou363000,China)

Abstract:With the expanding database applications,enterprise-class database applications have become an important data storage and query method.Database performance and design optimization for the data structure to simplify and optimize the query process is important.This article discusses the importance of SQL databases optimization,detailed

analysis of the SQL database optimization strategy.

Keywords:Database applications system;Performance;Design;

Optimization

在一个基于数据库的应用系统的运行过程中，影响系统效率的原因是多方面的，对于目前常用的三层（N层）Web结构应用架构来说，如果系统运行效果不理想，需要判断性能损失来自于操作系统、Web层应用系统或者数据库，单独测试以确定瓶颈所在。

一、优化SQL数据库的意义

如果脱离Web层应用组件测试仍然存在性能问题，需要进一步跟踪数据库应用，判断开销主要来源于SQL还是PL/SQL，然后再进一步做性能分析。在数据库方面的原因 ，可能来源于数据库结构设计是否合理，磁盘空间和表空间的规划是否合理，SGA区设置是否合理，数据库参数设置是否合理，以及SQL语句的编写质量等。一般来说，数据库的结构设计、空间规划及参数调整、甚至是项目结构调整通常根据系统的需求而定，主要由系统分析员和数据库管理员来共同完成。实际上，不同的SQL实现方式之间的效率差异可能会非常大，尤其是在大数据量复杂数据库环境下表现尤为明显，对于千万级别数据量的数据库，执行一条关联几个大表的SELECT语句可能会消耗几十分钟，SQL语句的低效直接导致系统性能低下。高效的SQL语句来自于满足SQL语句的优化原则，使用充分的连接条件，优化的WHERE子句，以及适当的索引设计。可以利用一些工具，例如执行计划及跟踪文件等，帮助调试SQL语句以获得最优效果。下面先了解在构造SQL语句时应当遵循的一般优化原则。

二、SQL优化策略

（一）在SQL语句中，查询所有列时尽量不使用“*”’符号

我们在查询某个表的所有列时，经常使用SELECT*FROM table这种方式，注意“*”，符号的确是SQL语法许可的查询所有列的方式，但是这种查询方式，数据库服务器需要额外地去查询数据字典，把“*”符号转换为表的所有列，再将查询结果返回给用户。这个额外地查询数据字典的动作是会消耗系统时间的，所以建议在写SQL语句时，把实际列名写出，即使包含全部列，也就是使用SELECT deptno，dname，loc FROM dept而不用SELECT*FROM dept。

（二）编写SQL时使用相同的编码风格

SQL语句被发送到服务器进程后，要经过语句解析、语句执行以及返回结果几个步骤。在语句解析阶段，首先判断在共享的SGA区中是否能找到完全相同的SQL语句，如果找到就省去解析步骤，直接使用现有的执行计划，否则再去执行解析步骤。所谓完全相同是指SQL中的字段位置、大小写、空格个数等完全等价，SQL中所指的对象必须完全相同。

（三）使用TRUNCATE语句替代DELETE

如果要删除表的全部记录，可以使用不带WHERE子句的DELETE语句实现。但TRUNCATETABLE速度更快，并占用更少的系统资源和事务日志资源。DELETE属于DML语句，每次删除一行，同时在事务日志中记录删除动作，在UNDOSEGMENT中保存删除的信息，以备操作撤销，而TRUNCATE语句只在事务日志中记录所释放的数据页，不保留任何所删除的数据，所以速度比DELETE更快。执行DELETE语句后，表所占用的空间是不释放的，而TRUNCATE语句释放表所占用的全部空间。所以TRUNCATE是执行删除全部表记录时效率比较高的操作。

（四）在确保业务逻辑的前提下及时COMMlT提交事务

因为业务逻辑的要求，经常需要在事务中执行一系列DML语句，建议在保证业务逻辑一致的前提下，尽可能的多用COMMIT提交事务，这样可以及时结束事务，释放事务所占用的资源，例如回滚段中的空间占用、DML语句造成的锁、重做日志缓存区的空间以及Oracle Server为维护事务的内部开销。

（五）EXISTS和IN

在编写SQL语句时，经常需要在子查询中获取一个值列表，在主查询中使用IN去比较列数据是否在值列表中，这种方式实现SQL比较简单和结构清晰。OracleServer采用的是先对子查询中的表做全表扫描，获得查询结果，然后再执行主查询。而EXIST则是首先执行主查询，再运行子查询直到找到第一个匹配项。在大多数SQL调优的观点中，建议在业务密集的SQL当中尽量不采用I_N操作符，而使用EXIST替代IN，效率会提高。具体在选择IN或EXIST操作时，要根据主表和子表的数据量大小来具体考虑。如果两个表数据量相差悬殊，EXIST适合外表小而内表大的情况，N适合外表大而内表小的情况。

三、结束语

数据库是数据资料管理、存储与处理的重要技术，数据库系统的性能是决定信息资源使用效率的根本，如果在保证数据查询准确的同时提高数据查询的速度，是影响数据库系统应用效率的重要因素，只有完成性能优化才能保证数据库的高效利用，达到更高的资源应用要求、产生更高的价值。

参考文献：

[1]张君枫.Oracle数据库性能调整与优化[J].电脑知识与技术,2008,29

[2]朱建东,翁正平,柳庆武.Oracle数据库在属性数据管理中的另类用法[J].微机发展,2005,06

浅谈数据库性能的优化 篇4

1 硬件层面的优化

随着数据库的存取量越来越大, 任何数据库应用都可能遇到硬件的瓶颈。DBA必需评估有无可能通过优化逻辑和配置消除这些瓶颈, 或者需要更多的硬件资源, 系统瓶颈一般产生在这四个方面:磁盘寻道、磁盘读写、CPU、内存。因此这四个方面可做如下优化:

1.1 磁盘寻道。

磁盘找到要读写的数据需要花费时间, 现代硬盘的寻道时间一般低于10ms, 所以我们理论上1秒钟可以做100次寻道。硬盘在这方面的改进非常缓慢, 单表也很难有优化余地。优化寻道的简单方法是把数据分布到两个或多个硬盘上。

1.2 磁盘读写。

磁盘的磁头寻道到正确的位置之后, 接下来就是读写数据, 现代磁盘最少能达到10-20MB/s的吞吐量。读写比寻道容易优化, 因为可以从几块硬盘并行的读 (磁盘阵列) 。

1.3 CPU。

当遇到CPU方面的资源瓶颈的时候, 可能由两个方面造成: (1) 过多依赖数据库进行逻辑运算:对于这种状况, 最好的优化方式是将运算尽可能从数据库端迁移到应用端, 降低数据库主机的计算量。如果从数据库端的硬件来解决问题, 一般要通过增加设备CPU数目 (如果支持) , 或者是使用CPU能力更为高端的主机来替换老主机。 (2) 数据库逻辑IO太大:对于这类状况, 从硬件角度来说能做的就只有提升CPU处理能力。增加CPU数目 (如果支持) , 或换CPU更强劲的主机。但是在这之前, 建议先尝试从应用角度优化看看是否能够尽量降低非必要请求或者是减少每次请求的数据量。同时从数据库角度针对Schema结构以及索引进行相应的优化调整, 尽可能让完成一次请求所需要检索的数据量更小, 从而达到降低逻辑IO的目的。

1.4 内存。

当CPU需要的数据比CPU cache更大时, 主内存带宽就成了瓶颈, 内存成为瓶颈的情况较为罕见。优化的方法是增加内存, 加大可缓存的数据量。这个方案能否达到效果取决于系统热点数据的总量, 毕竟内存的成本也是比较高的, 而且单台设备所能管理的内存量也是有限的。

2 软件层面的优化

2.1 优化SQL语句。

数据库程序的核心逻辑通过SQL语句执行, 有的通过解析器直接执行, 有的通过API提交到后台程序。

2.2 优化SELECT语句。

SELECT形式的查询执行了数据库中的全部查询操作, 不管是做动态网页还是需要通宵执行的巨大报表, 优化SELECT都是重中之重。SELECT调优技术也可以应用到“CREATE TABLE...AS SE-LECT”、“INSERT INTO...SELECT”和DELETE语句的WHERE子句。这些语句在SELECT基础上有附加的功能, 读出查询结果之后又附加了写操作。

2.3 优化查询的主要注意事项。

(1) 在where条件中用到的字段上简历索引, 可加快过滤和最后的检索速度。为了避免磁盘空间的浪费, 应建一个尽可能小的索引去优化程序中用到的大部分的查询。 (2) 查询中用到的表要尽可能少, 最好单表查, 大表尤其不要联查。 (3) 尽量使表统计信息更新, 使优化器有足够的信息找到一个最有效率的执行方案。 (4) 学习不同存储引擎的调优技术、索引技术和配置。 (5) 分别调用优化查询的每一部分, 比如:耗时的函数调用, 要知道在大查询操作中, 这些函数可能被调用上百万次。 (6) 如果一个性能问题无法通过简单的原则解决, 就要通过查看explain命令来了解细节, 以便调整索引, WHERE语句, JOIN语句等等。高级用户在做每个查询的第一步就是explain。 (7) 调整My SQL用于缓存的内存大小和设置, 通过有效运用Inno DB的缓冲池、My ISAM的键缓存和查询缓存, 重复查询可以更快执行, 因为第二次以及以后的查询可以直接从内存中读取查询结果。 (8) 即使一个查询已经通过内存缓存优化过, 仍有进一步优化的余地, 优化还可以使需要的内存更少, 让程序可以处理更多的并发用户, 更大的请求数量, 而性能却不会明显下降。 (9) 处理锁问题, 在同一时间内, 查询速度可能被其他存取表所影响。

2.4 SELECT语句的速度。

一般来说, 当你要优化“SELECT...WHERE”第一反应应该想到的是加索引, 当引用多个表, 使用连接 (JOIN) 和外键时, 索引尤为重要。可以通过EXPLAIN语句判断查询使用了哪个索引。

3 小结

其实数据库的性能优化是一个复杂的过程, 上述这些只是在应用层次的一种体现, 深入研究还会涉及数据库层的资源配置、网络层的流量控制以及操作系统层的总体设计。

参考文献

[1]顾长生, 林超.SQL Server6.5的九种性能优化方法[J].计算机应用研究, 2001第7期-维普资讯网.

[2]席洁.数据库优化技术的分析与探讨[J].电脑知识与技术, 2011 (12) .

编程语言的数据库性能比较 篇5

摘要：随着计算机技术不断发展，各种数据库编程工具也随着发展，使当今的大多数程序开发人员可以摆脱枯燥无味的用计算机指令或汇编语言开发软件，而是利用一系列高效的、具有良好可视化的编程工具去开发各种数据库软件，从而达到事半功倍的效果，但是现在市面上的数据库编程工具门类众多，优良不齐，比如VB，VC，DEPHI，PB等，对此我特别针对流行的开发语言介绍相应的较为成熟的数据库编程工具。

几种支持数据库的语言介绍

VB

全称Visual Basic，它是以Basic语言作为其基本语言的一种可视化编程工具。在中国乃至全世界都能看到它的身影，它曾是在中国最为流行的编程工具，到现在还占据着非常重要的地位，对于它的好坏大家都有一定的了解，VB作为一种较早出现的开发程序以其容易学习，开发效率较高，具有完善的帮助系统等优点曾影响了好几代编程人员，但是由于VB不具备跨平台这个特性，从而也决定了VB在未来的软件开发中将会逐渐地退出其历史舞台；它对组件技术的支持是基于COM和ActiveX,对于组件技术不断完善发展的今天，它也显出了它的落后性；同时VB在进行系统底层开发的时候也是相对复杂的，调用API函数需声明，调用不方便，不能进行DDK编程，不可能深入Ring0编程，不能嵌套汇编；而且面向对象的特性差；网络功能和数据库功能也没有非常突出的表现，综上所述，VB作为一种可视化的开发工具由于其本身的局限性，导致了它在未来软件开发中逐

步被其他工具所代替。

PB

全称PowerBuilder，是开发MIS系统和各类数据库跨平台的首选工具，使用简单，容易学习，容易掌握，在代码执行效率上也有相当出色的表现。PB是一种真正的4GL语言（第四代语言），可随意直接嵌套SQL语句返回值被赋值到语句的变量中，支持语句级游标，存储过程和数据库函数，是一种类似SQLJ的规范，数据访问中具有无可比拟的灵活性。但是它在系统底层开发中犯了跟VB一样的错误，调用API函数需声明，调用不方便，不能进行DDK编程，不可能深入Ring0编程，不能嵌套汇编；在网络开发中提供了较多动态生成Web页面的用户对象和服务以及系统对象，非常适合编写服务端动态Web应用，有利于商业逻辑的封装；但是用于网络通讯的支持不足；静态页面定制支持有限，使得PB在网络方面的应用也不能非常广泛。面向对象特向也不是太好。

C++Builder/Delphi

它们都是基于VCL库的可视化开发工具，它们在组件技术的支持、数据库支持、系统底层开发支持、网络开发支持、面向对象特性等各方面都有相当不错的表现，并且学习使用较为容易，充分提现了所见即所得的可视化开发方法，开发效率高。由于两者都是Borland 公司的产品，自然继承了该公司一贯以来的优良传统：代码执行效率高。但是，它们并不是毫无缺点，它们所作的最大不足之处就是他们的帮助系统在众多的编程工具中是属于比较差的。C++Builder 的VCL库是基 1

于Object pascal(面向对象pascal),使得C++Builder在程序的调试执行上都面向落后于其他编程工具。而Delphi则是它的语言不够广泛，开发系统软件功能

不足两个比较大的缺点。

Visual C++

是基于MFC库的可视化的开发工具，从总体上说它是一个功能强大但是不便使用的一种工具。它在网络开发和多媒体开发都具有不俗的表现，帮助系统也做得非常不错（Microsoft 在细节方面的处理往往都让人觉得亲切），但是虽然是使用C++作为基本语言，但是它在面向对象特性上却不够好，主要是为了兼容C的程序，结果顾此失彼；在组件支持上也不太好，虽然说除了支持COM,ActiveX外还支持CORBA,但是没有任何IDE支持，是所有C编译器的功能, 需要CORBA中间

件支持；最大的问题是开发效率也不高。

Java

数据库性能的优化 篇6

关键词：Oracle关系型数据；性能优化；安全；备份

随着oracle数据库应用的深入，数据信息的不断增加，数据库的安全性受到多方面的威胁，包括对数据库信息的偷取、篡改、破坏和数据库系统本身存在的一些Bug、黑客的故意攻击、病毒和木马的入侵等，可能会造成无法预料的损失时，数据库系统不能正常运行，造成大量数据的信息丢失，影响数据库业务运行，数据库的安全问题已经显得越来越重要。

1 影响Oracle数据库性能的因素

随着当今业务复杂程序的不断加大，对信息系统的稳定性、数据的可靠性、业务的连续性及用户体验均提出了更高的要求。然而，信息系统用户量、数据量增长、硬件老化、资源分配不足、设计缺陷和开发漏洞等因素，严重制约着信息系统高性能运行，威胁系统的稳定性，影响用户体验。从Oracle系统性能优化的角度来看，影响系统性能的可控因素主要包括以下几点：

1.1 数据库主机性能

主机对整个系统性能的影响主要分为CPU数量和内存大小。

CPU数量决定了整个系统的并发处理能力，当CPU数量相对较少时，主机整体处理数据的能力不足，最终导致事务响应时间增长。当内存不足时，会出现换页现象，换页是数据在内存和磁盘之间交互，大量的换页会导致数据处理时间变长，CPU负载增加。

1.2 数据库核心参数设置

数据库的核心参数设置直接决定了整体系统性能，比如SGA设置过大会导致操作系统层面剩余内存不足，造成换页，影响系统性能；SGA设置过小会使系统整体的I/O增加，导致事务响应变慢。此外还包括进程数、并发、优化器模式设置等。

1.3 网络传输

网络传输分为公共网络和私有网络。客户端与数据库之间的数据交互需要通过公共网络来进行，公网的传输性能严重影响着最终用户体验。RAC数据库中私有网络承载着节点间的网络心跳和实例间的数据块传输，私有网络性能直接决定着RAC集群性能，私有网络带宽不足会严重影响集群节点见的数据传输，严重的性能问题会导致节点驱逐甚至宕机。

1.4 应用程序

应用程序对数据库整体性能的影响主要表现在SQL语句，存储过程等的执行效率方面。比如设计缺陷和开发漏洞会导致索引失效最终查询路径使用全表扫描方式，使用了低效的表连接方式等等导致SQL响应时间变长，影响着系统整体的响应时间。

1.5 存储性能

存储是整个数据库架构的根基，直接决定了物理读写的速度。存储的性能取决于带宽，分为磁盘带宽（度量标准为IOPS和等待事件）和通道带宽（度量标准为MBPS）。生产中通过条带化来提升存储性能，用镜像来保障安全冗余。但是不合理的设置，例如RAID和ASM的二次条带化将大大降低存储性能，增加应用响应时间。

2 Oracle数据库系统的系能评价指标

2.1 系统的吞吐量

Oracle数据库应用系统的吞吐量是指单位时间内处理事务的数目，单位是tps即每秒处理的事务量。提高系统吞吐量有两种方法：一是减少服务时间，提高服务效率，在同样的资源条件下能做更多的事务处理；二是减少总体的响应时间，提高系统运行效率，让事务处理过程可以更快的完成。

2.2 用户响应时间

响应时间，顾名思义就是指在用户请求一项事务时，从用户提交到数据库返回结果所用的时间。

2.3 数据库实例效率

数据库实例效率包括多项指标，这些指标都是越接近100%数据库性能越好。Buffer Nowait会话申请一个buffer（兼容模式）不等待的次数比例。buffer hit：高速缓存命中率，反应物理读和逻辑读中间的比例。Library Hit：库字典缓存命中率，申请一个library cache object例如一个SQL游标时，其已经在library cache中的比例。Soft Parse： 软解析比例。Execute to Parse反映了 执行解析比。Non-Parse CPU非解析CPU比例，若大多数CPU都用在解析上了，则可能好钢没用在刃上了。

2.4 内存使用情况

内存是否合理使用，一般考虑的主要调整目标有两点：一是尽可能充分利用内存来降低物理读写，从而提升性能，比如设置合理的buffer cache来降低物理读。二是在系统最繁忙的时间段，要保证系统拥有足够的内存，如果分配过大的SGA和PGA导致系统繁忙时间段内存耗尽出现大量的换页，将会极大地降低系统性能。

2.5 I/O响应时间

Oracle对I/O类型等待事件的响应时间做了严格的规定，控制文件并行写、直接路径写、临时文件直接路径写和日志文件并行写响应时间需要控制在15毫秒内；控制文件顺序读、数据文件并行读、数据文件离散读、数据文件顺序读、直接路径读和临时文件直接路径读的响应时间需要控制在20毫秒内。

3 Oracle数据库性能优化

3.1 内存参数调整与优化

Oracle数据库实例的内存主要由SGA和PGA构成，其中SGA主要包括数据缓冲区、共享池和日志缓冲区；PGA主要包括哈希区、排序区等。它们的分配是否合理决定了数据处理各个阶段的性能。

3.1.1 数据缓冲区调整与优化

数据库缓存命中率是一个过时的参数，对于buffer hit% 看它的命中率有多高没有意义，主要是关注未命中的次数有多少。不合理的db_cache_size或者是SGA自动管理ASMM /Memory 自动管理AMM下都可能因为db_cache_size过小引起大量的db file sequential /scattered read等待事件。 此外与 buffer Hit%相关的指标值得关注的还有 table scans（long tables） 大表扫描这个统计项目、此外相关的栏目还有Buffer Pool Statistics 、Buffer Pool Advisory等。可以根据Buffer Pool Advisory和数据库服务器的整体内存情况来设置合理的db_cache_size，并使用内存的手工管理来保证db_cache_size不会改变。

3.1.2 共享池调整与优化

共享池主要由库缓冲、数据字典缓存组成。合理设置共享池大小，使共享池中保存较多的SQL语句以及相关数据对象和用户信息，可以提高SQL程序的解析效率。此外可以使用绑定变量来提高软解析比例，通过设置session_cached_cursors参数来提高执行解析比。这些方法都有助于降低共享池的争用。

3.1.3日志缓冲区调整与优化

日志缓冲区用于存放数据的修改信息。日志首先写入日志缓冲区，在一定条件下由LGWR进程将日志缓冲区的信息写入日志文件。如果日志缓冲区已满，但还没有写入日志文件，则日志写入失败。过多的日志写入失败，说明日志缓冲区偏小，影响数据库性能，应该调整LOG BUFFER 的大小。

3.1.4 PGA区域调整与优化

PGA区性能主要由哈希区和排序区决定。在Oracle数据库中，哈希和排序操作一般情况下在PGA中进行，如果PGA内存不足，会使用临时段进行排序，由于使用临时段是对磁盘的操作，会降低执行效率，因为建议尽量在PGA中进行哈希和排序操作。

3.2 磁盘I/O性能调整优化

数据库的数据是存储在物理磁盘上的。影响磁盘I/O性能的主要原因有磁盘规划不合理、I/O操作过量、热点块竞争和数据库碎片整理。磁盘规划方面尽可能使用转速较快的SAS盘或者FC盘，尤其是数据库的redo和undo。可以使用廉价磁盘冗余阵列实现条带化，使所有数据文件可以访问所有可用带宽。避免ASM和RAID之间的二次条带化等。

优化I/O操作的方法包括：将频繁扫描的小表固定在buffer cache的保留池中，使热点对象造成的I/O最小化；利用索引、分区表来降低查询中数据块的读取量。

3.3 SQL语句优化

SQL语句消耗资源主要分为I/O和CPU，优化SQL的实质就是在结果正确的前提下，将IO和CPU消耗降到最低，主要通过调整执行计划来实现。

执行计划三要素分为访问路径、关联方式和关联顺序。访问路径包括：全表扫描、索引扫描、先走索引再回表；关联方式分为循环嵌套连接、哈希连接和排序合并连接；关联顺序分为驱动表和从动表。

从访问路径来看，最终目的是访问最少的数据块来得到最终想要的结果。最优路径一般是通过索引找到目标数据块，因此，避免全表扫描是这个部分中的重要环节；此外还存在例如集群因子高导致回表耗费暴增的情形，需要建立联合索引来解决等等。

从表的关联方式和关联顺序来看：对于循环嵌套连接，要保证小结果集驱动，驱动表的选择列上最好有索引，在从动表的关联列上要有索引；对于哈希连接，要保证小结果集驱动，两表的限制条件要有索引，确保PGA中完成哈希运算；对于排序合并连接，两表的限制条件要有索引，连接条件索引消除排序，避免多余列致排序尺寸过大，保证PGA的尺寸。

3.4 Oracle表空间规划

表空间是Oracle数据库逻辑划分中最大的概念，如果能合理规划表空间，提高表空间的使用率，会对Oracle数据库性能的提升有很大的帮助。合理表空间的分布除了要求分离数据和索引，归档日志和重做日志也要分离。

优化表空间结构，首先要做好系统表空间的分离，除了数据字典，尽量不要存储非系统用户的信息；其次，由于索引段和数据段的数据管理以及查询会存在冲突，因此要把两者分开来放；最后，做好临时表的分离，由数据库动态产生的临时段是动态的，一般是存放在临时表空间中。

4 保证Oracle数据库较高安全性的方法

4.1 用户管理

数据库用户是连接数据库、存取数据库对象的通道。通过建立不同的用户组和用户口令验证，可以有效地防止非法Oracle用户进入数据库。另外应该注重数据库用户口令的复杂程度和使用期限，特别注重对SYS和SYSTEM两个特殊账户的保密管理。对于远程用户，应使用加密方式来访问数据库，加强网络上的DBA权限控制，如拒绝远程的DBA访问。

4.2 数据备份

Oracle数据库的备份是数据库管理员日常工作中的重中之重。Oracle数据库主要由以下几种备份方式：

4.2.1 逻辑备份

逻辑备份的核心是复制数据。这种复制方式不管数据库中具体是哪些文件存储数据，而是按照oracle提供的命令，通过逻辑的方式直接将数据保存在其他位置。例如导出文件，数据泵导出文件等。

4.2.2 物理备份

物理备份的核心是复制文件。对于oracle数据库来讲，就是将数据文件、控制文件、归档文件等oracle数据库启动时所必须的相关物理文件，复制到其他路径或者存储设备中。最主要的方式是RMAN。

4.2.3 Oracle数据库的备份策略

Oracle数据库备份在生产中一般使用RMAN备份，数据库备份分为普通备份和增量备份。选择备份策略一般考虑如下几点：

希望最早恢复到的时间点；系统何时负载最小，备份是密集I/O操作，应选择系统最空闲的时间段进行备份；数据库的规模，在一定程度上决定了是否使用增量备份；数据块是否被频繁修改，决定了是否应该使用增量备份；最后还应该考虑能够给予的恢复时间。

4.3 数据灾难备份

一般情况数据备份都在同一机房，在遭遇机房渗水、火灾甚至地震海啸时，数据备份也无能为力，这时数据灾难备份就会派上用场。数据灾难备份一般可以使用Oracle Golden Gate或者Data Guard在异地建立灾难备份中心，当主库在出现灾难时及时启用备份数据库支撑前端业务运行。

5 小结

Oracle数据库系统优化是一个需要宏观把控，多方考虑的任务，需要对Oracle数据库进行深入分析，多角度了解服务器、存储、网络及应用程序对数据库性能的影响，进而才能分析与解决问题。数据库的安全需要冗余，而冗余又制约着数据库效率，所以在实际工作中，要根据具体需求来权衡数据库安全和性能问题。

参考文献：

[1]侯东敏.浅谈Oracle数据库安全问题[J].科技天地，2009.01.

[2]刘哲.基于Oracle数据库系统的优化与性能调整研究[J].绿色科技，2012.05.

影像数据库的建立及性能优化 篇7

关键词：影像数据库,多线程处理,数据压缩

影像数据是承载着空间信息的数据, 具有多光谱、多时相、高分辨率的特性。随着空间信息获取方式越来越多以及空间信息迅速增长, 一个高效的、合理的、安全的存储和管理方式是必不可少的。经过近30多年的发展后, 影像数据库由文件管理方式向关系数据库管理影像数据的方式逐步升级过渡。现阶段, 基于关系数据库平台的影像数据库系统慢慢崛起, 需要根据系统特点进行多方面的性能优化, 以此对海量影像数据进行有效管理[1]。

1 遥感影像建库流程及主要功能

1.1 影像库建库流程

以国家基础地理信息中心1∶5000栅格数据建库为例, 中心提供的数据有一个共同特点:同一文件目录下的影像数据, 绝大部分的波段和分辨率都是一定的, 只有少数的数据出现了不一致。为了使之批量入库, 一种行之有效的办法是:对同一文件目录下的所有影像数据, 首先要判断它们的波段, 做出一个统计得到主要数据所带有的波段和分辨率信息, 然后以这个信息为标准, 建立一个目录图层, 对于不符合这些元信息的数据, 以它们的“波段-分辨率”为目录图层名, 进行单独存放。其流程如图1所示。

1.2 影像库主要功能

大型的影像库应用系统应该具备如下几个主要功能:

(1) 上传数据:对于大量的影像数据, 将它们从一定格式文件导入到数据库表单中, 这个过程是数据管理第一步;

(2) 查询数据:数据库系统能够为用户提供快捷的数据查询, 对于影像数据的查询可以提供多种条件复合的查询, 方便用户在最短时间内准确找到所需要的数据;

(3) 数据浏览:能够利用窗口视图, 对所选择的数据进行浏览查看, 可以对单个图层进行浏览, 也可以对单个目录图层进行整体浏览;

(4) 数据下载:已经浏览过的数据, 如果想以某种数据格式得到它们, 应该提供快速的下载功能[2]。

2 遥感影像建库的关键技术

2.1 影像数据的存储结构

Oracle数据库提供了BFILE、BLOB数据模型来存储影像数据, 在所要建立的1∶5000栅格数据库系统将采用BLOB数据模型。

BLOB是一种内部LOB类型, 适用于2进制数据的存储, 它以字节流的形式存储在数据库的内部, 这种存储方式的最大优点是可以充分发挥数据库系统强大的安全保密机制。由于BLOB类型不考虑数据的格式, 仅把存储在其中的数据看作是长短不一的字节流, 这样可以在存储时引入各种加密算法进行进一步的保密处理, 最大限度地保护数据不被非法浏览、使用或修改。Oracle提供了多种使用和操作BLOB的方式, 如, 使用PL/SQL调用DBMS_LOB包、调用OCI等[3,4]。

2.2 影像数据的分块

由于在海量影像数据库中, 每次调度和使用的图像数据只是数据库中的小部分。如果数据文件很大, 将直接影响到数据的读取执行速度。如何高效的组织和管理数据, 将直接影响到系统的性能。数据分块是影像数据库的关键技术, 数据块太大或太小会影响系统的有效性能。如果数据块太大, 则可能导致读取过多的多余数据 (不在目标范围内的数据) ;如果数据块太小, 尽管减少了多余数据, 但却增加了磁盘寻址和读操作次数, 不利于节省总的读数据时间。目前, 建立影像数据库多采用数据块大小为128×128个像素或256×256个像素[5,6]。如图2所示。

3 遥感影像库的性能优化

3.1 影像数据压缩

几乎所有的自然数据都有一些冗余的信息, 数据压缩的核心问题就是怎样把这些冗余信息除掉并以更精炼的方式把信息表现出来。遥感数据的规模与信息含量并不是线性关系的。对遥感数据进行压缩, 降低数据的规模, 有利于节省存储空间, 提高数据上传、下载的速度和提高系统的整体性能。

根据重建图像的质量, 数据压缩分为无损压缩和有损压缩。无损压缩可以完整的恢复原始图像, 不会丢失图像任何重要信息, 但压缩比例比较低;有损压缩允许重建信号局部失真, 但压缩倍率比较高。因为, 影像库对数据主要是一种管理功能, 数据可能被下载后做一些精确性的应用, 所以, 不能因为追求系统的最高性能而使数据质量下降。鉴于此, 可以利用JPEG2000的开源代码, 修改针对特定格式文件的读取部分代码, 使之应用到影像数据的压缩系统中[7,8]。压缩解压模块和整个系统的应用关系, 如图3所示。

3.2 多线程处理

系统会比较多的用到数据的上传和下载, 为了能够提高系统执行效率, 数据的压缩只是从源头降低了数据量。对于某一个特定的系统, 可以考虑对数据的显示、下载等多个操作过程实现多线程处理, 这样可以继续提高系统性能的并发性, 可以同时进行部分数据的浏览和部分数据的上传或下载。

利用多线程的C++ API函数创建多个线程, 确定每个线程的功能后, 采取合适的调度算法和线程间的通信方式, 使各个线程的功能得到发挥[9,10], 多线程的处理方式, 如图4所示。

4 结论

系统实践表明, 文中给出的建库方案和优化技术较好的解决了对多样遥感数据的入库、浏览、下载等功能的实施。对于图像的无损压缩, 较好的解决了图像数据量和图像质量的矛盾;多线程的操作方式使系统具有并行操作成为可能, 提高了数据管理和应用的效率。该系统已经实施并交付给国家地理信息中心使用, 结果表明它能很好的完成对栅格数据的管理任务。

参考文献

[1]罗睿, 张永生.遥感影像数据模型及影像数据库的建立[J].测绘学院学报, 2002 (12) .

[2]李兰勇.影像数据库系统的研究与建立[D].辽宁工程技术大学硕士研究生论文, 2005 (1) .

[3]王连备, 吴云东.基于oracle数据库的遥感影像存储技术[J].测绘学院学报, 2002, 19 (4) :12.

[4]杨培章.OCI接口简介及其在VC++中的应用[J].电脑编程技巧与维护, 2003 (11) .

[5]王密.大型无缝影像数据库系统 (GeoImage DB) 的研制与可量测虚拟现实 (MVR) 的可行性研究[D].武汉大学博士学位论文, 2001 (11) .

[6]赵峰.上海市遥感影像数据库的研建[D].同济大学硕士研究生学位论文, 2002 (10) .

[7]李飞鹏, 秦前清, 李德仁.海量遥感数据库实时压缩系统的设计与实现[J].计算机工程与应用, 2003 (26) .

[8]何凯涛, 张海江.整数小波变换在海量影像数据库系统建设中的应用研究[J].长春科技大学学报, 2004 (4) .

[9]Bil Lewis, Daniel J.Berg.PThreads Primer:A Guide toMultithreaded Programming[M].2002 (10) .

数据库性能的优化 篇8

数据库的生命周期分为设计、开发和成品三个阶段, 因此, 对数据库性能的优化要贯穿于数据库系统的整个过程, 由于在设计和开发阶段进行的成本最低, 数据库设计关系到系统的效率和质量, 因此, 在数据库的设计阶段对数据库性能进行优化, 是最高效、实用的措施。

数据库设计包括逻辑设计和物理设计两部分。逻辑设计主要是用数据库组件为业务需求和数据建模, 但不需要考虑数据的存储方式和位置;物理设计包括将逻辑设计映射到物理媒体上, 尽可能快的使用可用的软硬件对数据库进行物理访问和维护;还包括索引的生成。

1. 逻辑数据库设计的性能优化

1.1 数据库设计规范化和非规范化的互补。

关系数据库的主要存在形式是表格, 对关系数据库金属优化, 就是要合理的处理数据库中表与表的关系。科学合理的逻辑数据库设计能够在表与表的关系中进行科学的设计, 为关系数据库的优化和应用程序打下良好的基础。标准化的逻辑数据库采用大量有关系的窄表来代替很多列的宽表, 使数据库的排序和索引的建立更为迅速, 促进了多簇索引的使用使INSERT和DELETE等语句的执行速度更快, 使索引更窄、更紧凑, 由此形成的空值和多余值的减少也增加了数据库的紧凑性。

由此可知, 数据库的规范化处理使数据行趋向变窄, 减少了数据的冗余, 增加了SQL Server数据库每页的字符含量, 对表的扫描和返回多行的速度与单个表的查询功能进行了改进。但在涉及到多个表的使用时, 可能要对信息进行复杂的合并处理才能达到要求, 这一过程会引起大量的数据处理处理, 在一定程度上降低了系统的性能。要解决这一问题, 可以采用数据库的非规范化进行处理, 非规范化就是违反规范化的规则进行的一些数据库的设计。非规范化可以根据不同的情况采用不同的方式对系统的性能进行一定程度的改善, 提高数据库的整体性能。

(1) 当规范化设计产生了很多路的合并关系时, 在数据表中加入重复的列的方式会使数据库的操作产生困难。在这种情况下, 可以采用把实体 (表) 分割成两个表 (把所有的属性分割成两组) , 把每个表中的首要关键字进行复制的方式进行非规范化处理。就可以把频繁访问的数据和较少访问的数据分开, 这样的设计会产生较少的表, 还有利于并行处理。

(2) 对一些系统的最大值、总计等常用计算字段, 可以采取将字段存储到数据库实体中的方式进行处理;在表的记录量很大时, 用户可以把这些在查询和报表经常用到的资料的计划总数作为一个独立的字段加入到表中, 用触发器与客户端保持数据的一致。

这种做法也加大了表的处理难度, 可以采用把一个表分为两个表的方式进行非规范化处理, 这样的方式一般应用于含量较大的表中, 在使用中需要保持历史记录的, 可以把频繁访问的数据和较少使用的数据分开进行处理, 就可以减少单个表的操作难度。如果数据行是作为销售分区和地理分区等自身的逻辑工作组进行防伪时, 表的分开处理也具有一定的好处。

关于规范化和非规范化的处理原则, 一般是以规范化的设计为出发点, 在根据特定的情况有选择的对某些表进行非规划设计处理, 用规范化和非规范化向结合的策略进行数据库设计。但无论是规范化设计还是非规范化设计, 都可以利用SQL Server的以下功能对数据库的完整性进行自动的维护。

(1) 利用CHECK约束和PRIMARY KEY和UNIOUE约束来保证字段的有效性和唯一性。

(2) 利用DEFAULT和N0T NULL约束来保证输出必要字段值, 对字段的有效性进行保护。

(3) 利用F0REIGN KEY约束来保证记录的参照完整性。

(4) 使用IDENTITY字段, 高效生成惟一行的标始符。

(5) 利用TIMESTAMP字段确保在多用户更新间进行高效并发检查, 保证用户定义的数据与数据库内的保持一致。

SQL Server的这些强制规则有助于避免因应用程序本身为完全强制完整性规则而引起的数据库错误, 尽量保证强制保证数据库的完整性和有效性。

物理数据库设计

2. 磁盘硬件的选择。

一般选择由多个磁盘驱动器组成的RAID (独立磁盘冗余阵列) 磁盘系统设备。硬件RAID采用将Windows和应用程序的所有数据进行切片, 散分在所有参与RAID阵列的磁盘中的方法来减轻单个磁盘的工作负荷。也按照类似的方法在物理驱动器之间拆分数据, 将所有参与RAID阵列的物理磁盘的工作负荷进行平分。因此可以使作为整体参与RAID阵列的磁盘保持同等的繁忙程度, 不仅可以提高磁盘I/O的性能, 还避免了因某些磁盘I/O请求分配的不平均而成为瓶颈的情况发生。RAID还用奇偶信息和镜像等方法预防磁盘故障的出现和数据的丢失。因此, RAID磁盘系统具有很高的可靠性、存储容量, 整体性能很高, 而且所需的成本很低。

SQL Server在具体的使用中, 一般采用RAID等级0、1和5.

RAID 0是最基本的RAID级别, 是传统的磁盘镜像, 阵列中的每一个磁盘都有一个或者是多个磁盘的拷贝, 能够提供最高的可靠性。由此可见, RAID 0的写操作得以成倍的增加, 但对读操作却没有影响, 可以进行多个读操作的并行处理, 提高了读操作的性能。

RAID 1是最基本的容错RAID级别, 称为磁盘镜像或者是磁盘双工。主要是保证事务日志的冗余性。

RAID 5是使用奇偶校验对数据引入冗余的RAID容错级别。将数据信息和校验信息分散到阵列的所有磁盘中, 当数据分割为条时, 对附加的奇偶校验位进行计算并将其存储在一个磁盘的条中, 解决了单个校验盘的瓶颈和单点失效问题。因此, RAID 5阵列失去一个磁盘驱动器不会对系统造成太大的影响。此外, RAID 5也增加了写操作, 可以并行处理一个读操作, 成倍的提高了读操作的性能。

通常情况下, 在RAID 0驱动器上配置数据库, 将事务日志放置在驱动器RAID 1的方法, 通过镜像事务日志, 为数据库获取最佳的磁盘I/O性能并对数据库的可恢复性进行维护。若考虑到数据的快速恢复, 可以将数据库和镜像事务日志放置在RAID 5磁盘上。

综上可知, RAID 5提供的性能比RAID 0或RAID 1要低, 但可靠性和恢复能力比它们要高。而且虽然RAID 5的写操作比RAID 0的增加要少, 但在实际的应用中, 用户的读操作要比写操作多很多, 而且写操作的执行操作速度很快, 因此, 读者对写操作时间的节省很难感觉到。因此, 在实际的应用中, 一般选用RAID 5来作为硬件磁盘使用。

2.1 索引的选择。

索引的建立是快速获得所需信息的有效方法, 索引的访问与全表扫描相比, 查询时间明显的缩短。SQL Server提供了聚集索引和非聚集索引两种索引。虽然索引都可以提高检索和更新数据库的速度, 但不同的索引由于功能的不同对于特定的任务可能会有更高的效率, 因此, 在设计时, 要根据实际情况进行选择。

非聚集索引的索引顺序和其表行的物理排序不同, 但其叶层包含指向数据页上的表行指针。SQL Server可以通过搜索非聚集索引中的表行指针对数据库中的数据位置进行直接的查找, 从而能得以快速的读取数据。

聚集索引按照字典排序对表中数据的进行物理排序, SQL Server按行的形式排列表行, 使得它们具有相同的物理顺序和逻辑顺序。由于聚集索引决定了表中数据的物理顺序, 因此, 每张表只能建立一个聚集索引。

由此可以看出, 聚集索引对数据进行物理排序, 查询的速度相对较快, 但一个表只能建立一个聚集索引。非聚集索引只对数据进行逻辑排序, 速度相对较慢, 但一个表可以建立多个索引。另外, 由于新数据不仅要增加到表中, 还要在索引中进行更新, 所以, 非聚集索引的建立虽然加快了查询的速度, 但降低了更新的速度。加上索引的使用还需要额外的磁盘空间和维护开销, 因此, 在实际的设计选择中, 要尽量选择有用的索引和索引形式, 以便最好的发挥其作用。

3. 查询语句的选择。

数据库的查询效率是衡量数据库性能的一个重要的指标, 但SQL Server的查询会消耗大量资源, 在保证查询效率的同时也产生了一些负面的影响, 下面就如何优化查询和提高查询性能提出几点建议。

(1) 在SQL Server的使用过程中, 系统数据库tempdb会根据需要而自动扩展, 利用了大量的临时空间。在执行查询进行时, 可以利用WHERE语句来对必须处理的行数进行限制, 以免对所有的记录行进行非必要的无限制读取和处理。

(2) 添加更多的内存。

(3) 将一个大的查询拆开, 分成多步进行执行。

(4) 多个处理器可以使SQL Server进行并行查询, 因此, 可以在有多个处理器的计算机行运行SQL Server。

(5) 如果查询需要游标, 则要对使游标类型或游标查询的功能就行进行确认, 以标准游标的使用效率。

(6) 在确实需要程序使用循环时, 则可以考虑在查询内放入循环。

(7) 避免对同一查询内的单个表使用多个别名, 以免增加查询的难度。

(8) 利用guery governor配置选项来对长时间运行的查询进行阻止, 以免系统资源的消耗。

(9) 对有关当前查询的统计信息进行记录。在开始优化查询之前要对提供了可以测量优化修订后成功与否的测试标准的Showpian和I/O统计信息进行记录。

(10) 从基础入手, 检查是否存在着可用的索引, 检查运行查询时是否有其他的触发器在同时运行, 查询是否运用了视图、是否使用了非查找变量符。

4. 存储过程的优化。

存储过程是分析和编译后的SOL程序, 包含大量复杂的查询或者是SQL操作, 通过编译的程序存储在SQL数据库中, 客户可以利用应用程序对其名称进行查询的方式加以调用。

存储过程在第一次执行时建立优化的查询方案, 第一次执行后SQL Server产生的优化后的查询计划就会被保留在内存中, 再次使用时不需要再次编译、优化就可以直接执行查询计划, 从而改善了系统的性能, 节省了查询的时间。

存储过程通过本地存储、代码预编译及缓存技术能够实现高效的数据操作, 合理的使用存储过程不仅优化了程序员的程序设计, 还可以极大的提高SQL语言的使用效率;将其使用在服务器上, 也有助于减少向客户端传输的数据量, 提高传输和处理数据的效率。

最优查询方案的选择, 往往要根据实际要求和具体情况进行比较。SQL Server提供的Showpian能够对不同查询结构的性能包括查询计划、索引选择、I/O次数和响应时间等进行比较。在设计开发中, 可以对这一工具加以。

5. 对客户/服务器体系结构进行利用

(1) 保持客户、服务器工作负载的平衡。一般情况下, 服务器最适合处理基于集合的数据检索和维修操作;而客户工作站在显示复杂的用户界面、处理数据格式化和特殊行或列的数据有效验证效率最高, 在设计开发时, 要充分考虑到两者的特点。发挥各自的优势, 努力实现达到均衡负载。

(2) 减少网络负载。网络是客户/服务器工作的基础, 但网络宽带的有限性也常使它成为一个主要的瓶颈。减少网络负载, 可以对系统的响应时间进行改善。使用存储过程有效地减少网络流量。这样, 客户不需要发送大量的SQL语句, 仅仅传递一些参数就可以对存储过程进行调用。

6. 结语

综上所述, 在SQL Server数据库的设计开发阶段进行性能的优化, 可以从多个方面进行, 具有很大的优势和效益, 因此, 要把性能优化贯穿于数据库系统的整个周期进行。

参考文献

[1]魏银珍, 陈征兵, WEI Yin-zhen, CHEN Zhen-bing, SQLServer数据库的查询优化策略研究, [J]电脑知识与技术, 2011, 07 (29)

[2]揭晓陵, 张红, 熊亮春, 影响SQL SERVER数据库性能的因素及优化, [J]江西电力职工大学学报, 2002, 15 (3)

[3]徐丽媛, 张亚宾, 基于SQL Server数据库查询优化的几点思考, [J]科技信息, 2010 (20)

[4]李荣瀚, SQLServer数据库性能优化, [J]科海故事博览科技探索, 2011 (3)

[5]宋益众, Microsoft SQL Server2000数据库管理系统性能研究, [J]电脑知识与技术 (技术论坛) , 2005 (6)

数据库性能的优化 篇9

在计算机应用系统中,数据库的设计占有相当重要的地位,数据库性能的好坏,直接影响到整个系统的运行效率。对数据查询和处理速度,已成为衡量一个应用系统成败的标准。所以,数据库性能优化问题应贯穿到整个数据库设计过程中,SQL Server2000自推出以来,凭借其强大的信息操作和优越的数据管理功能,受到了广大用户的喜爱,但随着数据量的增加,也需要对其进行使用情况分析和性能优化,以提高系统的性能和运行效率。

2 数据库布局的优化

2.1 数据、索引和日志文件分开

SQL Server把数据库文件存储为操作系统文件,数据和索引存为一个或多个操作系统文件,并且组成文件组,日志文件存成另外的操作系统文件,使用这种结构可以把频繁访问的表或索引分布到特定的磁盘上,从而平衡组成数据库的各个资源的负载,另外这种结构具有很好的伸缩性,可以轻而易举地支持小规模和大规模的数据库。它除了带来性能上的提高,还从物理层次上把数据、索引和日志信息分割存放在系统的硬件资源上,提供了更大的灵活性和可管理性。

2.2 使用文件组

把数据文件从逻辑上分成文件组,可以把表和索引放到指定的磁盘上,这样数据库就可以跨越多个磁盘,磁盘控制器和PCI母线来分散负载,让管理员实现数据库系统的负载平衡分配。对于大型数据库,文件组可以提高和扩展RAID阵列的能力,并且可以从逻辑上扩展到采用相似或不同的硬件技术的多个阵列上,但是对于小型数据库文件组可能会成为一个额外的管理负担。所以采用文件组时注意:

(1)小型的数据库采用单个数据文件和单个日志文件时性能表现最优。

(2)把竞争资源的数据和索引信息分开存放到不同的文件组中。

(3)对于连接操作很多的操作,把表分布到不同的文件组中,因为提高I/O并行处理的机会会改善系统性能。

(4)总是把日志文件和数据文件分别存放在不同的磁盘和磁盘阵列上。

(5)首先要利用硬件RAID,再在RAID上使用文件组,从而把负载均布到多个磁盘控制器和总线上。

(6)把tempdb和用户定义的数据库分离开,这样会改善使用中间表的查询的性能。

2.3 磁盘分布

RAID(廉价磁盘冗余阵列)是由多个磁盘驱动器(一个阵列)组成的磁盘系统,是计算机系统中物理磁盘的一种组织机制。RAID在物理驱动器之间拆分数据,可提高磁盘I/O的性能,因为作为整体参与RAID阵列的硬盘保持同等繁忙程度,而不会是某些磁盘由于I/O请求分配的不平均而成为瓶颈。

SQL SERVER一般使用RAID等级0,1,5。RAID 0以16~64KB数据区的形式,把数据分布写入磁盘阵列中的所有磁盘上,它可以同时对多个磁盘写入和读出数据,但是它没有容错能力。RAID 1和RAID5具有容错能力,保护硬盘不出现故障,并能防止由于故障而出现数据丢失。RAID 0+1把镜像和条带结合起来以提供更大的数据保护和可用性。通常在RAID0驱动器上配置数据库,将事务日志放置在RAID1,通过镜像事务日志,为数据库获得最佳的磁盘I/O性能并维护数据库可恢复性,如果系统的存储容量不足以为数据文件建立RAID1卷,可以用RAID5来保护数据,虽然RAID5提供的性能比RAID0和RAID1低,但能提供更多的可靠性和更快的恢复能力。

2.4 分割可能争夺系统资源的数据

tempdb数据库用于保存所有的临时信息,包括存储的例程和表,是最争夺资源的部分,为了提高存取速度,所以需要把它独立出去,tempdb存取频繁,最适于存放到一个具有快速读写能力的设备上,从硬件的角度看,tempdb在RAID0或RAID 0+1卷上性能最高,而且如果只让tempdb自己使用这个磁盘、磁盘阵列或控制器,表现会更好。用Performance Monitor(性能监视器)来决定适当的起始容量,并且允许tempdb自动增长,为其设置一个合理的单位增长量,以防止tempdb数据库自动增大或减小带来的外来性碎片的问题。

2.5 管理事务日志

事务日志文件是数据库必不可少的一个数据文件,用于保持数据的完整性,还可以用于在数据丢失时恢复数据。为了优化事务日志的性能,要把事务日志文件单独存放在RAID1设备上,并把它的初始大小设置为合理的大小,以防止当需要更多的事务日志空间的文件自动扩展。在收缩事务日志文件时,要手工收缩,而不是允许SQL SERVER自动收缩文件,防止收缩事务日志会因数据页的移动和锁定而妨害性能。

3 数据库实现的优化技术和策略

3.1 规范化

由于数据库的规范化设计减少了数据冗余,也减少了用于存储数据的页,提高了应用程序的效率,并减少了因数据不一致引起错误的可能性。但是表关系也需要通过复杂的合并来处理,这样会降低系统的性能,而某种程度上的非规范化可以改善系统的性能,提高查询和操作的速度。所以在设计数据库时较优的策略是以规范化的设计为出发点,然后出于特定的原因有选择地非规范化某些表。

3.2 建立索引

索引是常见的数据库对象,它的设置好坏,使用是否得当,极大地影响数据库应用程序和数据库的性能。对于一个未建立索引的表执行查询操作,SQLSERVER必须进行表扫描,从磁盘上读表的每一个数据页,从而挑选出所有符合条件的数据行,特别是当一个表有很多行时,就会大量浪费时间,效率很低,然而在建立索引之后,SQLSERVER将根据索引的指示,直接定位到需要查询的数据行,从而加快SQLSERVER的数据检索操作,并减少因查询而造成的I/O开销。但是带索引的表在数据库中会占据更多的空间,为了维护索引,对数据进行插入,更新,删除操作的命令所花费的时间会更长,在设计和创建索引时,应确保对性能的提高程度大于在存储空间和处理资源反面的代价。

3.3 建立视图

视图是一个虚拟表,由来自一个或多个表、数据库或服务器的数据列组成,并且避免了显示各用户的数据在事实上由多个数据源组成。视图可以使用连接,group by子句,子查询等以及它们的任意组合来检索视图数据,它通过把多个数据源合为一个,提高了数据分块的效率,简化数据查询和处理操作。

在视图上创建索引时,当视图所涉及的数据不会频繁改变,或使用视图来计算大量的值或执行大规模的连接操作的时候,对视图建立索引可以显著地改善性能,但是对于修改操作和检索操作会严重地降低性能。

视图还可用于在多个数据库或SQL SERVER2000实例间对数据进行分区。分区视图可用于在整个服务器组内分布数据库处理,可以提高分布式数据的查询效率,在进行很多查询时避免了和其他服务器通信,能使服务器组中的多个服务器之间可以实现并行处理。

4 结束语

SQL SERVER数据库的性能优化技术还有很多,要根据具体情况来确定使用哪些优化调整技术,总之在使用过程中,注意权衡利弊,以使数据库的性能达到最优化,提高整个系统的性能和运行效率。

参考文献

[1][美]Jenney Lynne Fields.《Microsoft SQLServer2000优化指南》.北京:清华大学出版社,2001.

[2][美]Edward Whalen.《SQL Server2000性能调整技术指南》.北京:机械工业出版社,2002.

[3]杜军平,黄杰.《SQLServer2000数据库开发》.北京:机械工业出版社,2001.

[4]庄成三,洪玫,杨秋辉.《数据库系统原理及其应用》.北京:电子工业出版社,2000.

[5][美]Jeffrey D.Ullman,Jennifer Widom.《数据库系统基础教程》.北京:清华大学出版社,1999.

企业数据库的性能优化路径探究 篇10

现代化科学文化水准持续上升的环节中, 人们的生活频率不断进行加速, 效率这个关键词也被提高上了一个前所未有的程度之上。由于企业数据库的搜索功能以及普遍应用的性质的特点, 所以人们对企业数据库重视的程度不断加大。怎样才能使得企业数据库的性能不断优化, 加快工作进度的进行也逐渐的演变成了人们不断发掘的关键因素。本文就企业数据库为出发点, 提出了性能优化的使用价值, 并强调了对企业数据库的产生的工作效益具体的影响的具体原因以及对应的性能优化途径。具体报告如下所述。

1 企业数据库具体设计的优化

企业数据库具体的组成部分包括, 逻辑的设计和物理存储形式的设计, 逻辑设计具体是指通过对于数据库具体组成部分的应用, 以此来为客户所需要的内容提供更加优质的服务, 另外还要对数据库里的内容进行模块的建立, 但是这部分的设计理念不需要考虑存储的具体的方法和形式, 不要参考物理方面的具体设计内容。所讲的物理存储形式的设计就是指按照逻辑设计的理念将它投射到物体载体上的内容进行整理, 应用方便快捷的物理硬件和软件对于使用客户的需求进行防护, 具体的用户需求的维护包括对于访问时的具体内容和操作形式, 以及操作之后的维护操作。

1.1 逻辑设计的优化

企业数据库的逻辑设计的主要出发点是为了通过运营创作出一个DBMS可以进行相应管理的企业数据的模板, 以及通用较为简便的企业数据库的基本模式, 这个基本的模板一定要具备企业数据库所需要的基本特质, 整体性全面性以及一致性, 并且满足用户在使用过程中所需要的基本元素。企业数据库的逻辑设计的基本理念是删繁就简, 去除一些繁琐麻烦的数据, 增加数据检出率的效率, 加大数据的检出数量, 同时要注意保障数据存储的完整性和整体性, 要保障能够对数据和数据之间的对应联系进行清楚的展现。可见企业数据库的逻辑设计的基本出发点就是规范统一, 这样才能保证整体性的进行, 理论的指引作用才能更加明显, 逻辑要参照以下标准。首先, 所有的多值性质 (又被叫作重复内容) 都会被去除, 在数据库中的列表的内容每行和每列的交叉的部分都只保留一个固定值, 不要出现重复的现象。其次, 在关键词搜索这个方面, 非关键词要对关键词有依从性, 依从的对象不能够是其中一个组合的主要关键词, 或者其中组合的一个组成部分。在这个内容的基础上, 企业数据库中如果不存在非关键词和关键词的依从性的体现, 那么就会有新的原则, 即传递函数的依从原则, 具体是指A-B-C的依从关系, 其中C依从于A。

这些应用的优化原则, 可以删繁就简, 去除数据库庞大的复杂的数据整体内容, 也就可以对数据库的空间进行整理, 以此来提高数据库的检索效率, 使得检索功能更加方便快捷。但是更加需要注意的是, 对于逻辑设计的规范化的原则, 并不是可以一直提高检索的效能, 如果所要优化的企业数据库, 已经处于一个简便的表格的整合形式, 那么在使用优化逻辑设计的方法, 则数据库的内容不会再有什么删减, 还会保持原来的检索程度不变, 甚至会出现数据库的内容删减过多, 使得搜索的功能水平迅速下降。由此可得, 优化逻辑设计的方法只是适用于数据库内的表格存在繁琐的数据的数据库, 操作者要对数据库的优化逻辑设计功能进行权衡, 从而保证优化功能真正落到实处。

1.2 物理数据库的设计

目前主要的研究表明, 如果已经对于企业数据库所使用的整个系统和应用操作技术进行的确定, 那么数据库物理操作中所出现的问题就已经基本确定, 所以为了避免数据库整体系统所出现的问题从而导致的数据库功能下降以及部分数据丢失的情况, 操作人员要对以下几条原则多加重视。

首先, 保证每个逻辑设计的模块都有基本对应的物理模型, 这样做可以保证存储空间的合理化, 得到存储的最佳效益, 当用户在检索时, 所出现的数据内容就更加专业化以及具有针对性。

另外, 还需要对企业数据库进行区域的划分, 将一个庞大的表格划分为各个具有针对性的小型表格, 这样做的目的是为了提高检索的速度, 使得检索得到的内容更加具体和详细, 除了拆分表格之外, 划分区域的方法还有进行磁盘驱动器的应用。将表格和磁盘驱动器放置到一起, 并将不同的磁盘驱动器分开, 进行用户查询的时候, 不同的磁盘驱动器就会同时运行进行数据的搜素, 检索到的结果就会更加的全面, 同时也提高的检索的速度和效率。

最后还有的优化策略就是使用文件组对数据内容进行存储。将内容相似度加多, 结构类似的数据存储到同一个文件组里面, 这样对于检索效能的提升也有很重要的意义。

同时需要的注意的是对于数据库的实施日志的处理, 要避免过多的数据日志占据太多数据库的存储容量的现象的发生, 这要求操作人员对于数据库的日志存储部分的相关数值进行设定, 要安排合理的初始设置容量以及增量的合理范围, 通过设置减少增加的新的虚拟的日志文件对于数据库容量的占据, 也避免了由于日志内容存储过多, 而导致的搜索时出现的持续待机的状态的出现。

2 搜索设计的优化

加快查询速度的最好的方法就是对于搜索操作环节的各方面的内容进行优化, 这样才可以使检索效能的提高有质的飞跃。搜索机制是以数据库的表格为基础的检测工具, 它的设立对于查询表中的一条或者多条的内容的效率的提升有很优质的效果, 但是如果没有对于搜索的相关内容进行优化, 所出现的结果也有的是十分恶劣的。首先要了解到对于搜索机制的维护工作是十分繁琐的, 所要付出的代价很大, 要保证搜索功能设立之后应用的频率和正常功能。有的时候部分用户为了返回上一个检索内容, 从而错误的将整个检索库中的内容进行搜索, 达到了很繁琐的内容。

所以优化检索机制的主要注意事项如下, 检索时要注意是对于主要的关键词进行搜索, 不要使用非关键词进行错误的搜索, 如果频繁的使用某一关键词或者内容进行搜索, 可以建立分组的聚簇搜索。进行搜索时, 要尽量应用词条较为局限的词语进行搜索。如果数据库进行了一系列的更新之后, 就要对原来的检索的内容进行删除和整理, 以此来提高检索的速度。如果表格设立了太多的插入操作的、或者进行删除操作的情况下, 不要设立太多的检索内容。

3 查询语句的优化

设立必须的检索并不决定意义的说明着企业数据库的检索性能会有很大的提升, 以至于到达完美的效果, 操作人员还要对于一些SQL的相关查询语句的进行总结和优化。一个应用较为良好的搜素表达公式并不是以基本的逻辑设计为基础的, 而是从实际的基本操作出发的, 要不断总结经验, 对开发的各项项目进行优化。对于SQL的语句进行有效的整理, 对数据库中的表格检索次数就可以降低, 那么检索数据命中的几率就会大大增加。

另外还要注意对于个别计算内容的公式和语法语义的优化, 这样当用户进行数据库的浏览器的功能进行使用的时候, 浏览器的具体资源也已更加整体化, 浏览器在完成相应操作的时候, 可以降低解析的难度, 缩短解析的时间, 加速数据库检索功能的效率。

4 结语

综上所述, 在各项优化操作的基础上, 一个完整的数据库和搜索机制已经完成了一个基本的过程, 但是要注意的是企业数据库的性能优化过程是一个系统和繁杂的过程, 要对于各方面都有一个系统的了解, 要从各个方面出发进行考虑, 而不是单独考虑某一个数据库的完整性的影响因素, 这样会顾此失彼。

参考文献

[1]杜明.基于Flash混合存储的电子商务数据库性能优化研究[D].上海:东华大学, 2012.

[2]杨义根.面向应用模式的Hadoop/Hive架构和性能及应用研究[D].天津:南开大学, 2014.

[3]范玉雷, 赖文豫, 孟小峰.基于固态硬盘内部并行的数据库表扫描与聚集[J].计算机学报, 2012 (11) .

[4]焦毅, 李琳, 王颖慧.一种面向企业私有云的数据分布策略[J].计算机研究与发展, 2011 (z2) .

[5]谢佳壮.面向数据库集群的节能查询技术研究[D].合肥:中国科学技术大学, 2015.

数据库性能的优化 篇11

【关键词】无线网，优化，（E）GPRS数据，KPI参数，网络性能

【中图分类号】TN929.5 【文献标识码】A 【文章编号】1672-5158（2013）04-0123-01

近年来，（E）GPRS数据业务为附着在GSM网络上的新增业务，相比于基础话音业务来说（E）GPRS数据业务有很多新技术特点，例如：每一次用户会话都含有多次的分组呼叫、激活与休眠状态的变换、分组呼叫所用资源随时随数据传输而变化、数据用突发的方式进行传输工作等等。以诺西版本为例，其数据业务KPI参数系统的部署，对支持分析（E）GPRS数据有很大作用，为了解（E）GPRS性能提供了非常有用的工具，此外也对（E）GPRs性能融入到日常网络的维护与优化等工作中提供了有利的条件。

一、数据流量

以GSM无线网的视角来看，将（E）GPRs宽带定义为：在每秒的时间内最大通过的无线网比特数值。基于相同的上行与下行可用信道的数值，只需分析下行无线宽带，而以不同编码方式下行宽带有4个不同的公式。以AVAILABLE-PDTCH switchable PDTCH+reserved PDTCH，在话音业务处于繁忙阶段，部分switchable PDTCHI就会自动进行TCH的转化，将导致无线数据宽带的下降。（E）GPRS数～，据流量，即：在统计的时段内，进行无线网的通过时所占的总比特值。现阶段的统计项无法对重传数据进行区分，即：重传块包含在统计流量中。用公式表示为：Througput=（AIR-DL-DATA-BLKS[QOS3-CSl]×22+AIR-DL-DATA-BLKS[QOS3-CSZ]×32+AIR-DL-DATA-BLKS[C！OS3-Cg3]×38+AIR-DL-DATA-BLKS[QOS3-CS4Ix52）x800/1024kbit/s。对PDCH占用率、TBF建立成功率、掉线率、TBF拥塞率、误帧率和RLC重传率等关键KPI重点优化。

二、上行与下行的数据比例

（E）GPRS的上行与下行的数据比可以用（上行的数据流且/下行的数据流量）×0.01，这种比例在典型数据网络中应该处于25%以下，因此可以用这个比例对网络是否处休眠状态进行判断，用公式表示为：（AIR-UL-DATA-BLKS/AIR-DL-DATA-BLKS）×100%，当GPRS-ACCESS-PER-RACH比某一个门限大、且统计项的取值大于200%的情况下，则网络处于GPRS休眠状态，这就要对其（E）GPRS功能、BCSU/PCU进行重新激活。通常以上/下行TBF建立成功率>90%经验值来判断TBF建立是否正常，调整资源尽量将TBF：拥塞控制在2%以下。

三、空中接口和Gb接口

在GSM的基础上，（E）GPRS又增加了GGSN和SGSN两个核心网节点，而且，在对于IP分组的数据，进行在子网汇聚协议层议（SNDCP）到逻辑链路控制帧（LLc）的转化，每帧可以流出一个或者多个空隙给（E）GPRS数据业务，并且，不同（E）GPRS数据业务都可以对每一个时隙进行共享，同时也能与话音业务进行时隙的共享，这种共享方式随信道分配策略的不同进行不同的选择。Gb接口带宽受限同样会影响（E）GPRS的性能，Gb接口需要的带宽与规划数据流量相关，一般公式：【Gb接口规划的带宽=数据流量/70%*（1+25%）】。同时将PCU的峰值负荷控制在80%以下，均衡PCU负荷，优化Abis/Gb接口资源。

四、网络测评优化

（E）GPRS网络测评优化可以遵循网络评估、网络分析、效果检验三个步骤。通过对网络性能的整体评估、网络分析，发现网络存在的问题，在此基础上有针对性的制定KPI优化方案。网络分析可以通过STS统计/OSS测量数据提取、DT&CQT;测试数据采集、BSC&Cell;；相关功能特性参数核查等方面分别进行特性参数环境、容量、干扰和移动性能评估，深入分析PCU负荷、PDCH信道、TCH信道、IP中继、空闲信道、网络干扰、无线场强、硬件故障等因素，制定网络的整改和优化措施，采取多回合的CQT&DT;优化效果检验。

五、数据业务优化建议

（E）GPRS最为关键的技术就在与其在无线调制编码方式上实现了多种方式的自适应算法，它主要源于调制编码方式信道编码抗无码能力和无线信号载干比之间关系。C/I很大程度上直接影响了RLC数据速率，为了获得优秀速率，必须确保良好无线信号载干比。在实际测试中，C/I大于25dB是保证高级别调制编码方式重要前提。由于目前对（E）GPRS业务模型和标准没有统一，根据不同的运营需求，对（E）GPRS业务优化提出以下建议，如下图：

六、故障分析优化

在日常（E）GPRs数据业务优化，会接到各种的用户投诉案例，很多是无线环境、参数配置、硬件或是资源方面存在异常，需要结合现场测试、拥塞指标分析、干扰处理、资源调整、参数配置来进行优化，如：用调整频点解决网内干扰、用降低功率解决信道不足、用调整天线解决弱覆盖、用扩容解决DAP/PDCH拥塞、调整RAC解决路由频繁更新等等。

七、结论

闪存的数据库性能评测与优化分析 篇12

1 相关背景简介

1.1 对于闪存芯片的简介

现在市面上可以看到的闪存主要是分成了两种类型, 一种是NOR型, 另一种就是NADA型。NOR型的闪存存在着地址的全面映射, 可以对单个的字节进行访问, 对于片上的操作性工作具有可实施性;NAND型的闪存利用的就是接口对其进行数据访问, 这种形式类似于传统的硬盘数据存取方式。现在使用最多的就是NAND型的闪存。NAND型的闪存是通过两种存储单元组成的, 分别是单层存储单元 (SLC) 和多层存储单元 (MLC) 。由于单层存储单元价格成本会比多层存储单元的价格高很多, 所以现在我们使用的最多的就是多层存储单元, 在本文的介绍当中, 没有标明备注的就是NAND MLC闪存[1]。

1.2 对于固态硬盘的简介

固态硬盘制作的工具就是闪存, 利用闪存制造成的有超大容量的存储设备, 这个设备和传统的设备进行比较可以发现, 其有着体积更小、质量更小、速度更快、更加的省电防震的多种优点。

1.3 与其有关的各种实际操作

在现如今的计算机研究领域当中, 闪存是最热门的研究要点, 最开始的闪存研究工作的研究目标是, 在操作体系和闪存之间插入FTL, 让闪存能够对磁盘的工作进行模拟化的操作。但是因为FTL的利用效率不高, 但是又多种数据结构和存取的计划性操作手段在设计工作当中想要直接跳过FTL这一层, 因此要是使用的固态用盘当作存储的媒介的话, 是没有办法避过FTL这一层的。

现如今因为技术有限, 因此在对闪存的IO测试上的工作还比较少, 还没有一套非常明确的测试方法和测试标准用来检测闪存[2]。

2 固态硬盘最基础性的IO性质测试分析

表1是对NAND MLC的内存和磁盘之间进行访问时间的一个简单的对比。

从表1当中可以发现的是闪存在撰写速度上面要明显的慢于阅读的速度, 而擦除功能是这三个功能当中速度最慢的一个。而磁盘方面, 阅读与撰写的速度都差不多, 但是和闪存进行比较, 还是要慢了大概1—2个级别。

3 以闪存的数据库性能为基础进行测试

表2当中把测试的详细信息记性了一个总结归纳。

经过对上表的分析和研究, 可以得出结论就是操作体系和数据库体系对有没有放在闪存上面的影响不大。

4 对闪存的数据库整理体系的优化配置办法

经过上面的各种测试, 对相关的结构进行分析可以知晓, 闪存的IO方式和特点与磁盘之间还是存在着非常大的差别, 因此可以得出一个这样的结论, 对于磁盘优化有促进作用的配置放置在闪存上面就不适合了。对于闪存的优化方案总结了这样几点内容, 可以帮助闪存进行优化改造。一个是从数据组织这个方面入手进行操作, 另一个就是从整个操作体系的IO窄口处进行操作, 最后一方面就是从整个操作体系的资源窄口处入手进行相关的操作工作。

5 结语

本文就是从闪存的数据库体系入手, 对其的一些相关性能进行了简单的测试。关于存在的问题也进行了一些策略研究, 对于未来的闪存发展能够起到一定的帮助性作用。

摘要：在数据库领域的研究工作当中, 闪存数据数据库是研究的最多的一个方面。充分的将闪存的IO性质了解清楚, 详细的剖析现有数据库的产品在闪存上的性质特点, 对于此项工艺设计的改进工作有着良好的促进性作用。在现在这个阶段, 使用的最多的就是闪存制造固态硬盘, 固态硬盘和闪存的芯片之间, 彼此特点存在着巨大的差异。我们最先需要对固态硬盘的特性进行测试, 然后再利用TCP-B的标准对分布在固态硬盘上面的数据库产品进行分析。分析的内容包括了缓冲区的大小、用户的并发数、中央处理器的处理能力对闪存数据库造成的影响, 最后就是根据测试出来的结果, 从数据组织、数据库资源的利用等等各个方面对其进行优化配置和性能的升级。

关键词：闪存数据库,性能测试,性能优化

参考文献

[1]吕雁飞, 陈学轩, 崔斌等.基于闪存的数据库性能评测与优化分析[J].计算机研究与发展, 2009, 46 (z2) :682-687

[2]赵辉, 杨濮源, 岳丽华等.FEP:一个软硬件集成的闪存数据管理实验平台[C].第27届中国数据库学术会议论文集.2010:475-478