大家都说设计一个性能优越的数据库才能让程序跑的快些那怎样才能怎样才能设计一个性能优越的数据库？？？？？比如用sql2000来说事.....
解决方案 »
- 谁有.net 的班级网站源码，或者模版呀？
- 在线订购-商品库存的处理方式问题
- dataview如何绑定DataTable
- 为什么登陆后打开15个到20个页面就要求重新登陆？在线等，100f分解决即给分。
- 按钮取值时,ListBox的值怎么老是初始时的默认值，而不是当前值，好象我点按钮是有重新把本页登陆了一下
- C#对路劲的访问被拒绝
- 如何使多个“下拉菜单”相关联
- 怎样在客户端将某一站点设置为可信站点?
- [探索] 页面访问计数和大访问量是否能共存? 例如: 1万人同时对同一个ASPX页面发出访问,
- 如何限制textbox控制输入必须是数值。
- 使用UpdateProgress控件,loading层怎么罩住DropDownList
- 还是关于Cookie，顶者有分。
第一范式(1NF):
如果关系模式R的每个关系都是r的属性值不可分割的原子值,则称关系R是第一范式的模式.
不满足第一范式的情况:
关系R(name,address,phone)
----------------------------------------------------------------------
name address phone
AA 湖南长沙 2204446
AA 湖南长沙 8350524
----------------------------------------------------------------------
说明:phone可以再分(可以分为phone1和phone2).
*************************************************************************************
第二范式(2NF):
1):局部依赖:
对于依赖关系 W->A (A依赖于W),如果存在X归属于W,且X->A(A依赖于X),那么称W->A是局部依赖;否则称W->A是完全依赖.
比如:
关系模式R(sno,cno,grade,tname,taddr)
sno:学生学号;cno:课程编号;grade:成绩;tname:老师姓名;taddr:老师住址
(sno,cno)->(tname,taddr)(sno,cno决定于tname以及cno)是局部依赖,因为cno->(tname,taddr).
2):二范式定义:
如果关系模式R满足第一范式,且每个非主属性完全依赖于侯选键,则称R满足第二范式.
不满足第二范式的情况:
关系模式R(sno,cno,grade,tname,taddr)
sno:学生学号;cno:课程编号;grade:成绩;tname:老师姓名;taddr:老师住址
----------------------------------------------------------------------
sno cno grade tname taddr
101 001 100 张老师 湖南长沙....
102 001 95 张老师 湖南长沙....
103 001 98 张老师 湖南长沙....
104 002 95 李老师 湖南常德....
105 003 90 刘老师 湖南衡阳....
----------------------------------------------------------------------
说明:出现相同的tname,taddr三次
消除方法:分解关系模式R
----------------------------------------------------------------------
R1(sno,cno,grade)
sno cno grade
101 001 100
102 001 95
103 001 98
104 002 95
105 003 90
R2(cno,tname,taddr)
cno tname taddr
001 张老师 湖南长沙....
002 李老师 湖南常德....
003 刘老师 湖南衡阳....
----------------------------------------------------------------------
*************************************************************************************
第三范式(3NF):
1):传递依赖:如果X->Y,Y->A,且Y不依赖X和A不是Y的子集,那么称X->A是传递依赖.(A传递依赖于X)
2):三范式定义:
如果关系模式R是1NF,且每个非主属性都不依赖于R的侯选键,那么称R满足第三范式.
不满足第三范式的情况:
关系模式R2(cno,tname,taddr)是2NF模式,如果在R2中存在cno->tname,tname->taddr,那么cno->taddr就是个传递依赖,及不满足第三范式.
----------------------------------------------------------------------
cno tname taddr
001 张老师 湖南长沙....
002 李老师 湖南常德....
003 刘老师 湖南衡阳....
004 张老师 湖南长沙....
005 张老师 湖南长沙....
----------------------------------------------------------------------
说明:张老师开设了3门课程,上面就出现了3个元组,教师地址重复了3次.
消除方法:分解关系模式R2
----------------------------------------------------------------------
R3(cno,tname)
cno tname
001 张老师
002 李老师
003 刘老师
004 张老师
005 张老师
R4(tname,taddr)
tname taddr
张老师 湖南长沙....
李老师 湖南常德....
刘老师 湖南衡阳....
----------------------------------------------------------------------
还有其实要跑的快不仅仅是数据库后台要优化，.NET程序的一些逻辑也要优化，适当用缓存什么的，毕竟从内存取数据要比从硬盘取数据快上N倍的
就两个字,经验.
第N范式是理论上的东西
索引和cache属于数据库优化的范畴.
数据表的索引也很重要的
根据实际需要，你可能会使用xml存储一些不经常变化的东西
使用缓存也是提高性能的一个方面
数据库的设计一定要根据实际情况，没有一个通用的范式规则
优化策略
----为了保证Oracle数据库运行在最佳的性能状态下，在信息系统开发之前就应该考虑数据库的优化策略。优化策略一般包括服务器操作系统参数调整、数据库参数调整、网络性能调整、应用程序SQL语句分析及设计等几个方面，其中应用程序的分析与设计是在信息系统开发之前完成的。
----分析评价Oracle数据库性能主要有数据库吞吐量、数据库用户响应时间两项指标。数据库用户响应时间又可以分为系统服务时间和用户等待时间两项，即：
----数据库用户响应时间=系统服务时间＋用户等待时间
----因此，获得满意的用户响应时间有两个途径：一是减少系统服务时间，即提高数据库的吞吐量；二是减少用户等待时间，即减少用户访问同一数据库资源的冲突率。
----数据库性能优化包括如下几个部分：
----1. 调整数据结构的设计 这一部分在开发信息系统之前完成，程序员需要考虑是否使用Oracle数据库的分区功能，对于经常访问的数据库表是否需要建立索引等。
----2. 调整应用程序结构设计 这一部分也是在开发信息系统之前完成的。程序员在这一步需要考虑应用程序使用什么样的体系结构，是使用传统的Client/Server两层体系结构，还是使用Browser/Web/Database的三层体系结构。不同的应用程序体系结构要求的数据库资源是不同的。
----3. 调整数据库SQL语句 应用程序的执行最终将归结为数据库中的SQL语句执行，因此SQL语句的执行效率最终决定了Oracle数据库的性能。 Oracle公司推荐使用Oracle语句优化器（Oracle Optimizer）和行锁管理器（Row-Level Manager）来调整优化SQL语句。
----4. 调整服务器内存分配 内存分配是在信息系统运行过程中优化配置的。数据库管理员根据数据库的运行状况不仅可以调整数据库系统全局区（SGA区）的数据缓冲区、日志缓冲区和共享池的大小，而且还可以调整程序全局区（PGA区）的大小。
----5. 调整硬盘I/O 这一步是在信息系统开发之前完成的。数据库管理员可以将组成同一个表空间的数据文件放在不同的硬盘上，做到硬盘之间I/O 负载均衡。
----6. 调整操作系统参数 例如：运行在Unix操作系统上的 Oracle数据库，可以调整Unix数据缓冲区的大小、每个进程所能使用的内存大小等参数。
----实际上，上述数据库优化措施之间是相互联系的。Oracle 数据库性能恶化的表现基本上都是用户响应时间比较长，需要用户长时间的等待。而性能恶化的原因却是多种多样的，有时是多个因素共同造成了性能恶化的结果，这就需要数据库管理员有比较全面的计算机知识，能够敏感地察觉到影响数据库性能的主要原因所在。另外，良好的数据库管理工具对于优化数据库性能也是很重要的。
性能优化工具
---- Oracle数据库常用的数据库性能优化工具有：
----1. Oracle数据库在线数据字典 Oracle在线数据字典能够反映出Oracle的动态运行情况，对于调整数据库性能是很有帮助的。
----2. 操作系统工具 例如使用Unix操作系统的Vmstat、 Iostat等命令可以查看到系统级内存和硬盘I/O的使用情况，这些工具能够帮助管理员弄清楚系统瓶颈出现在什么地方。
----3. SQL语言跟踪工具（SQL Trace Facility）
----SQL语言跟踪工具可以记录SQL语句的执行情况，管理员可以使用虚拟表来调整实例，并使用SQL语句跟踪文件调整应用程序性能。SQL语言跟踪工具将结果输出成一个操作系统的文件，管理员可以使用TKPROF工具查看这些文件。
---- 4. Oracle Enterprise Manager（OEM） 这是一个图形的用户管理界面，用户可以使用它方便地进行数据库管理而不必记住复杂的Oracle数据库管理的命令。
----5. Explain Plan——SQL语言优化命令 使用这个命令可以帮助程序员写出高效的SQL语言。
系统性能评估
----信息系统的类型不同，需要关注的数据库参数也是不同的。数据库管理员需要根据自己的信息系统类型来着重考虑不同的数据库参数。
----1. 在线事务处理信息系统（OLTP） 这种类型的信息系统一般需要有大量的Insert、Update操作，典型的系统包括民航机票发售系统、银行储蓄系统等。OLTP系统需要保证数据库的并发性、可靠性和最终用户的速度，这类系统使用的Oracle数据库需主要考虑以下参数：
数据库回滚段是否足够？
是否需要建立Oracle数据库索引、聚集、散列？
系统全局区（SGA）大小是否足够？
SQL语句是否高效？
----2. 数据仓库系统（Data Warehousing） 这种信息系统的主要任务是从Oracle的海量数据中进行查询，以得到数据之间的某些规律。数据库管理员需要为这种类型的Oracle数据库着重考虑下述参数：
是否采用B＊索引或者Bitmap索引？
是否采用并行SQL查询以提高查询效率？
是否采用PL/SQL函数编写存储过程？
有必要的话，需要建立并行数据库以提高数据库的查询效率。
参数的调整
----1. CPU参数
---- CPU是服务器的一项重要资源，服务器良好的工作状态表现为在工作高峰时CPU的使用率高于90％。如果空闲时间CPU使用率就在90％以上，说明服务器缺乏CPU资源；如果工作高峰时CPU使用率仍然很低，则说明服务器CPU 资源还比较充足。
----使用操作命令可以看到CPU的使用情况，一般Unix操作系统的服务器，可以使用sar-u命令查看CPU的使用率；NT操作系统的服务器，可以使用NT的性能管理器来查看CPU的使用率。
----数据库管理员可以通过查看v＄sysstat数据字典中的 “CPU used by this session”统计项得知Oracle数据库使用的CPU时间；查看“OS User level CPU time”统计项得知操作系统用户状态下的CPU时间；查看“OS System call CPU time” 统计项得知操作系统系统状态下的CPU时间，操作系统总的CPU时间就是用户状态和系统状态时间之和。如果Oracle数据库使用的CPU时间占操作系统总CPU时间的90％以上，就说明服务器CPU基本上被Oracle数据库使用着，这是合理的，反之，则说明服务器CPU被其他程序占用过多，Oracle数据库无法得到更多的CPU时间。
---- 2. 内存参数
----内存参数的调整主要是指Oracle数据库的系统全局区（SGA）的调整。SGA主要由3部分构成：共享池、数据缓冲区、日志缓冲区。
----共享池由两部分构成：共享SQL区和数据字典缓冲区。共享SQL区是存放用户SQL命令的区域，数据字典缓冲区则存放数据库运行的动态信息。
结束语
----Oracle数据库的性能优化调整是一个系统工程，涉及的方面很多。数据库管理员需要综合运用上面介绍的规律，认真分析Oracle在运行过程当中出现的各种问题，以保证Oracle数据库运行的高效率。还需要指出的是，上面给出的语句只是测得Oracle运行过程的某一个时间点的情况，数据库管理员不能仅仅根据一个点的情况就断定数据库运行性能的好坏，只有多运行一些时间点才能对数据库运行状况做出一个综合评估。
----由于单个时间点的监测是很麻烦的，且对于多个时间点的监测更是一项烦琐的工作，为此，笔者开发了Oracle数据库性能监测软件ORATUNE。这个软件不仅能够定时从数据库中读取各种参数并自动计算出各种比例，而且还能自动根据这些比例的好坏建议数据库管理员修改某项参数
在基于表驱动的信息管理系统（MIS）中，基本表的设计规范是第三范式（3NF）。第三范式的基本特征是非主键属性只依赖于主键属性。基于第三范式的数据库表设计具有很多优点：一是消除了冗余数据，节省了磁盘存储空间；二是有良好的数据完整性限制，即基于主外键的参照完整限制和基于主键的实体完整性限制，这使得数据容易维护，也容易移植和更新；三是数据的可逆性好，在做连接（Join）查询或者合并表时不遗漏、也不重复；四是因消除了冗余数据（冗余列），在查询（Select）时每个数据页存的数据行就多，这样就有效地减少了逻辑I/O，每个Cash存的页面就多，也减少物理I/O；五是对大多数事务(Transaction)而言，运行性能好；六是物理设计(Physical Design)的机动性较大，能满足日益增长的用户需求。
在基本表设计中，表的主键、外键、索引设计占有非常重要的地位，但系统设计人员往往只注重于满足用户要求，而没有从系统优化的高度来认识和重视它们。实际上，它们与系统的运行性能密切相关。现在从系统数据库优化角度讨论这些基本概念及其重要意义： （1）主键(Primary Key)：主键被用于复杂的SQL语句时，频繁地在数据访问中被用到。一个表只有一个主键。主键应该有固定值（不能为Null或缺省值，要有相对稳定性），不含代码信息，易访问。把常用（众所周知）的列作为主键才有意义。短主键最佳（小于25bytes），主键的长短影响索引的大小，索引的大小影响索引页的大小，从而影响磁盘I/O。主键分为自然主键和人为主键。自然主键由实体的属性构成，自然主键可以是复合性的，在形成复合主键时，主键列不能太多，复合主键使得Join*作复杂化、也增加了外键表的大小。人为主键是，在没有合适的自然属性键、或自然属性复杂或灵敏度高时，人为形成的。人为主键一般是整型值（满足最小化要求），没有实际意义，也略微增加了表的大小；但减少了把它作为外键的表的大小。 （2）外键（Foreign Key）：外键的作用是建立关系型数据库中表之间的关系（参照完整性），主键只能从独立的实体迁移到非独立的实体，成为后者的一个属性，被称为外键。 （3）索引(Index)：利用索引优化系统性能是显而易见的，对所有常用于查询中的Where子句的列和所有用于排序的列创建索引，可以避免整表扫描或访问，在不改变表的物理结构的情况下，直接访问特定的数据列，这样减少数据存取时间；利用索引可以优化或排除耗时的分类*作；把数据分散到不同的页面上，就分散了插入的数据；主键自动建立了唯一索引，因此唯一索引也能确保数据的唯一性（即实体完整性）；索引码越小，定位就越直接；新建的索引效能最好，因此定期更新索引非常必要。索引也有代价：有空间开销，建立它也要花费时间，在进行Insert、Delete和Update*作时，也有维护代价。索引有两种：聚族索引和非聚族索引。一个表只能有一个聚族索引，可有多个非聚族索引。使用聚族索引查询数据要比使用非聚族索引快。在建索引前，应利用数据库系统函数估算索引的大小。
① 聚族索引（Clustered Index）：聚族索引的数据页按物理有序储存，占用空间小。选择策略是，被用于Where子句的列：包括范围查询、模糊查询或高度重复的列（连续磁盘扫描）；被用于连接Join*作的列；被用于Order by和Group by子句的列。聚族索引不利于插入*作，另外没有必要用主键建聚族索引。
② 非聚族索引（Nonclustered Index）：与聚族索引相比，占用空间大，而且效率低。选择策略是，被用于Where子句的列：包括范围查询、模糊查询（在没有聚族索引时）、主键或外键列、点（指针类）或小范围（返回的结果域小于整表数据的20%）查询；被用于连接Join*作的列、主键列（范围查询）；被用于Order by和Group by子句的列；需要被覆盖的列。对只读表建多个非聚族索引有利。索引也有其弊端，一是创建索引要耗费时间，二是索引要占有大量磁盘空间，三是增加了维护代价（在修改带索引的数据列时索引会减缓修改速度）。那么，在哪种情况下不建索引呢？对于小表（数据小于5页）、小到中表（不直接访问单行数据或结果集不用排序）、单值域（返回值密集）、索引列值太长（大于20bitys）、容易变化的列、高度重复的列、Null值列，对没有被用于Where子语句和Join查询的列都不能建索引。另外，对主要用于数据录入的，尽可能少建索引。当然，也要防止建立无效索引，当Where语句中多于5个条件时，维护索引的开销大于索引的效益，这时，建立临时表存储有关数据更有效。
批量导入数据时的注意事项：在实际应用中，大批量的计算（如电信话单计费）用C语言程序做，这种基于主外键关系数据计算而得的批量数据（文本文件），可利用系统的自身功能函数（如Sybase的BCP命令）快速批量导入，在导入数据库表时，可先删除相应库表的索引，这有利于加快导入速度，减少导入时间。在导入后再重建索引以便优化查询。 （4）锁：锁是并行处理的重要机制，能保持数据并发的一致性，即按事务进行处理；系统利用锁，保证数据完整性。因此，我们避免不了死锁，但在设计时可以充分考虑如何避免长事务，减少排它锁时间，减少在事务中与用户的交互，杜绝让用户控制事务的长短；要避免批量数据同时执行，尤其是耗时并用到相同的数据表。锁的征用：一个表同时只能有一个排它锁，一个用户用时，其它用户在等待。若用户数增加，则Server的性能下降，出现“假死”现象。如何避免死锁呢？从页级锁到行级锁，减少了锁征用；给小表增加无效记录，从页级锁到行级锁没有影响，若在同一页内竞争有影响，可选择合适的聚族索引把数据分配到不同的页面；创建冗余表；保持事务简短；同一批处理应该没有网络交互。 （5）查询优化规则：在访问数据库表的数据(Access Data)时，要尽可能避免排序（Sort）、连接(Join)和相关子查询*作。经验告诉我们，在优化查询时，必须做到：
① 尽可能少的行；
② 避免排序或为尽可能少的行排序，若要做大量数据排序，最好将相关数据放在临时表中*作；用简单的键（列）排序，如整型或短字符串排序；
③ 避免表内的相关子查询；
④ 避免在Where子句中使用复杂的表达式或非起始的子字符串、用长字符串连接；
⑤ 在Where子句中多使用“与”（And）连接，少使用“或”(Or)连接；
⑥ 利用临时数据库。在查询多表、有多个连接、查询复杂、数据要过滤时，可以建临时表（索引）以减少I/O。但缺点是增加了空间开销。
除非每个列都有索引支持，否则在有连接的查询时分别找出两个动态索引，放在工作表中重新排序 。
3 基本表扩展设计
基于第三范式设计的库表虽然有其优越性（见本文第一部分），然而在实际应用中有时不利于系统运行性能的优化：如需要部分数据时而要扫描整表，许多过程同时竞争同一数据，反复用相同行计算相同的结果，过程从多表获取数据时引发大量的连接*作，当数据来源于多表时的连接*作；这都消耗了磁盘I/O和CPU时间。
尤其在遇到下列情形时，我们要对基本表进行扩展设计：许多过程要频繁访问一个表、子集数据访问、重复计算和冗余数据，有时用户要求一些过程优先或低的响应时间。
如何避免这些不利因素呢？根据访问的频繁程度对相关表进行分割处理、存储冗余数据、存储衍生列、合并相关表处理，这些都是克服这些不利因素和优化系统运行的有效途径。 3.1 分割表或储存冗余数据
分割表分为水平分割表和垂直分割表两种。分割表增加了维护数据完整性的代价。
水平分割表：一种是当多个过程频繁访问数据表的不同行时，水平分割表，并消除新表中的冗余数据列；若个别过程要访问整个数据，则要用连接*作，这也无妨分割表；典型案例是电信话单按月分割存放。另一种是当主要过程要重复访问部分行时，最好将被重复访问的这些行单独形成子集表（冗余储存），这在不考虑磁盘空间开销时显得十分重要；但在分割表以后，增加了维护难度，要用触发器立即更新、或存储过程或应用代码批量更新，这也会增加额外的磁盘I/O开销。
垂直分割表（不破坏第三范式），一种是当多个过程频繁访问表的不同列时，可将表垂直分成几个表，减少磁盘I/O（每行的数据列少，每页存的数据行就多，相应占用的页就少），更新时不必考虑锁，没有冗余数据。缺点是要在插入或删除数据时要考虑数据的完整性，用存储过程维护。另一种是当主要过程反复访问部分列时，最好将这部分被频繁访问的列数据单独存为一个子集表（冗余储存），这在不考虑磁盘空间开销时显得十分重要；但这增加了重叠列的维护难度，要用触发器立即更新、或存储过程或应用代码批量更新，这也会增加额外的磁盘I/O开销。垂直分割表可以达到最大化利用Cache的目的。
总之，为主要过程分割表的方法适用于：各个过程需要表的不联结的子集，各个过程需要表的子集，访问频率高的主要过程不需要整表。在主要的、频繁访问的主表需要表的子集而其它主要频繁访问的过程需要整表时则产生冗余子集表。
注意，在分割表以后，要考虑重新建立索引。 3.2 存储衍生数据
对一些要做大量重复性计算的过程而言，若重复计算过程得到的结果相同（源列数据稳定，因此计算结果也不变），或计算牵扯多行数据需额外的磁盘I/O开销，或计算复杂需要大量的CPU时间，就考虑存储计算结果（冗余储存）。现予以分类说明：
若在一行内重复计算，就在表内增加列存储结果。但若参与计算的列被更新时，必须要用触发器更新这个新列。
若对表按类进行重复计算，就增加新表（一般而言，存放类和结果两列就可以了）存储相关结果。但若参与计算的列被更新时，就必须要用触发器立即更新、或存储过程或应用代码批量更新这个新表。
若对多行进行重复性计算（如排名次），就在表内增加列存储结果。但若参与计算的列被更新时，必须要用触发器或存储过程更新这个新列。
总之，存储冗余数据有利于加快访问速度；但违反了第三范式，这会增加维护数据完整性的代价，必须用触发器立即更新、或存储过程或应用代码批量更新，以维护数据的完整性。 3.3 消除昂贵结合
对于频繁同时访问多表的一些主要过程，考虑在主表内存储冗余数据，即存储冗余列或衍生列（它不依赖于主键），但破坏了第三范式，也增加了维护难度。在源表的相关列发生变化时，必须要用触发器或存储过程更新这个冗余列。当主要过程总同时访问两个表时可以合并表，这样可以减少磁盘I/O*作，但破坏了第三范式，也增加了维护难度。对父子表和1：1关系表合并方法不同：合并父子表后，产生冗余表；合并1：1关系表后，在表内产生冗余数据。 4 数据库对象的放置策略
数据库对象的放置策略是均匀地把数据分布在系统的磁盘中，平衡I/O访问，避免I/O瓶颈。
⑴ 访问分散到不同的磁盘，即使用户数据尽可能跨越多个设备，多个I/O运转，避免I/O竞争，克服访问瓶颈；分别放置随机访问和连续访问数据。
⑵ 分离系统数据库I/O和应用数据库I/O。把系统审计表和临时库表放在不忙的磁盘上。
⑶ 把事务日志放在单独的磁盘上，减少磁盘I/O开销，这还有利于在障碍后恢复，提高了系统的安全性。
⑷ 把频繁访问的“活性”表放在不同的磁盘上；把频繁用的表、频繁做Join*作的表分别放在单独的磁盘上，甚至把把频繁访问的表的字段放在不同的磁盘上，把访问分散到不同的磁盘上，避免I/O争夺；
⑸ 利用段分离频繁访问的表及其索引（非聚族的）、分离文本和图像数据。段的目的是平衡I/O，避免瓶颈，增加吞吐量，实现并行扫描，提高并发度，最大化磁盘的吞吐量。利用逻辑段功能，分别放置“活性”表及其非聚族索引以平衡I/O。当然最好利用系统的默认段。另外，利用段可以使备份和恢复数据更加灵活，使系统授权更加灵活。