精华内容
下载资源
问答
  • 字符串类型的字段在各关系数据库中均占有重要地位。比如Oracle数据库用于存储字符串类型数据的字段类型就超过了5种。遗憾的是,在日常工作笔者发现很多开发者对这些类型并没有完整的认识,更不用说设计表结构时...

    本文来自李明子csdn博客(http://blog.csdn.net/free1985),商业转载请联系博主获得授权,非商业转载请注明出处!

    1 引子

    字符串类型的字段在各关系数据库中均占有重要地位。比如Oracle数据库中用于存储字符串类型数据的字段类型就超过了5种。遗憾的是,在日常工作中笔者发现很多开发者对这些类型并没有完整的认识,更不用说设计表结构时正确的选择字段类型了。本文将辨析Oracle数据库中表示字符串的各字段类型以及设计表结构时字段类型的选择依据。

    2 字段类型介绍

    Oracle数据库中,用于表示字符串类型的字段类型包括CHAR、VARCHAR2、VARCHAR、NCHAR、NVARCHAR2、CLOB和NCLOB等几种,下面我们来一一介绍这些类型。
    2.1 CHAR
    CHAR类型用于存储定长的字符串,字段长度的取值范围是1到2000字节,默认为1字节。因为CHAR是定长的,所以,当存储的字符串小于设置的字段长度时,Oracle将在字符串尾填充空格占位。比如我们定义了一个字段“TEST_CHAR CHAR(2)”,而插入的记录对应字段值为“a”,则从表中读取的记录的对应字段是填充了一个空格的“a ”。
    对于CHAR类型值的比较,Oracle会在填充空格补齐到设置长度后进行。比如对于上例,当检索条件为“where TEST_CHAR=’a’”时是可以得到记录“a ”的。
    另外,在定义CHAR的长度时可以使用单位名称BYTE或CHAR,默认为BYTE。即“TEST_CHAR CHAR(2 BYTE)”意为长度为2个字节的CHAR,而“TEST_CHAR CHAR(2 CHAR)”意为长度为2个字符的CHAR。
    这里说的“字节”是存储字段信息所占用的物理存储空间,而“字符”则是指存储的信息的最小逻辑单位。当数据库使用单字节字符集时,一个字符的存储空间就是一个字节,而当数据库使用多字节字符集时,一个字符的存储空间可能是1到n个字节。
    2.2 VARCHAR2
    VARCHAR2类型用于存储变长的字符串,字段长度的取值范围是1到4000字节。VARCHAR2是变长的,这意味着实际存储长度与具体的字符串有关。
    对于VARCHAR2类型的比较,Oracle不会预先填充空格,而是直接比较值。比如我们定义一个字段“TEST_VARCHAR2 VARCHAR2(2)”,插入对应字段值为“a ”的记录。当检索条件为“where TEST_ VARCHAR2=’a’”时是无法得到记录“a ”的。
    另外,与CHAR一样,在定义VARCHAR2类型字段的最大长度时可以使用单位名称BYTE或CHAR,默认为BYTE。即“TEST_ VARCHAR2 VARCHAR2(2 BYTE)”意为最大长度为2个字节的VARCHAR2,而“TEST_ VARCHAR2 VARCHAR2 (2 CHAR)”意为长度为2个字符的VARCHAR2。
    2.3 VARCHAR
    在Oracle中,VARCHAR被定义为VARCHAR2的别名,其一切行为、特征与VARCHAR2相同。据传,起初,Oracle预留了VARCHAR字段类型用于与其他数据库兼容。而时至今日,它仍作为VARCHAR2的别名存在,其意义恐怕只是对Oracle数据库自身的向下兼容了。
    2.4 NCHAR
    NCHAR类型用于存储定长的Unicode字符串,其字符集只能是AL16UTF16或UTF8,与数据库安装时指定的字符集相同。有关Oracle数据库字符集的相关知识可参见Oracle官网在线文档Database Globalization Support Guide( https://docs.oracle.com/database/121/NLSPG/applocaledata.htm#NLSPG014)。
    在设置NCHAR类型字段的长度时,不支持设置单位名称,即单位名称均为“字符”。比如“TEST_NCHAR NCHAR(2)”指长度为2个字符的NCHAR类型字段。NCHAR字段的最大长度是2000个字节。这意味着它最多可以存储2000个字符,但这些字符的实际存储空间不能超过2000个字节。
    NCHAR的其他特性与CHAR相同,恕不赘述。
    2.5 NVARCHAR2
    NVARCHAR2类型用于存储变长的Unicode字符串,其特性参见VARCHAR2和NCHAR,恕不赘述。
    2.6 CLOB
    CLOB类型用于存储最大不超过128TB的变长字符串。CLOB支持事务,但不支持跨事务和会话的定位。下面的示例定义了一个叫做CLOB_TEST的CLOB类型的字段:CLOB_TEST CLOB。
    因为CLOB类型的字段在表中记录的是实际信息的指针,因此无法在sql语句中使用比较运算符。如果我们需要查找CLOB_TEST值为“a”的记录可以使用查询条件“where dbms_lob.compare(t.clob_test,’a’)=0”。
    2.7 NCLOB
    NCLOB类型用于存储最大不超过128TB的Unicode变长字符串。NCLOB的其他特性与CLOB相同,恕不赘述。

    3 字段类型选择依据

    既然Oracle数据库提供了多种字段类型用于字符串类型数据的存储,那么我们在设计数据库表结构时应该如何选择呢?笔者认为应该从各字段类型的区别、限制入手,抓住字符串类型数据的关键特性,从而选择出最适合的字段类型。下面将逐一介绍这些关键特性。
    3.1 最大长度
    从存储信息的角度来说,字段支持的字符串长度是信息能否被完整保留的重要条件。CHAR和NCHAR的最大长度是2000字节,VARCHAR2和NVARCHAR2的最大长度是4000字节,CLOB和NCLOB的最大长度是128TB。当我们要选择一个字段类型来存储字符串信息时,应当首先根据业务模型判断字符串的最大值,排除掉无法满足最大存储需求的字段类型。因为CLOB(NCLOB)类型使用时的诸多不便,当CHAR(NCHAR)和VARCHAR2(NVARCHAR)字段类型的最大长度限制可以满足业务需求时,通常不使用CLOB(NCLOB)类型。
    3.2 是否定长
    CHAR(NCHAR)类型与VARCHAR2(NVARCHAR2)类型最大的区别在于是否定长。CHAR(NCHAR)类型是定长的,这意味着它拥有更高的访问效率。但是,当实际存储的信息小于设置的字段长度时,Oracle会用空格来填充,此时会浪费一定的存储空间。虽然对于单条记录这个影响可以忽略不计,但对于海量记录,这个浪费就需要引起足够的重视了。
    VARCHAR2(NVARCHAR2)的情形与CHAR(NCHAR)刚好相反。它通过牺牲访问效率获得了更高的空间利用率。
    3.3 存储内容包含的字符
    NCHAR、NVARCHAR2、NCLOB类型存储Unicode字符串,仅支持AL16UTF16或UTF8字符集。虽然实际工作中很少遇到,但如果要存储的字符超出AL16UTF16和UTF8字符集范围,那就无法使用NCHAR、NVARCHAR2、NCLOB等字段类型了。
    3.4 是否需要建立索引
    如果需要为存储字符串的字段建立索引,那么我们要格外注意其对字段类型的限制。在CLOB和NCLOB类型的字段上是不能建立普通索引的。而在NCLOB类型的字段上是不能建立文本索引(如CONTEXT)的。
    3.5 是否可能出现数据库迁移
    如果可以预见在将来数据库可能发生迁移,那么设计数据库表结构时应该充分考虑字段类型的兼容性。比如,将Oracle中的NCHAR类型迁移到IBM DB2时,就需要通过CCSID子句创建兼容Unicode字符集的CHAR或VARCHAR。

    4 常见场景的字段类型选择

    第3节中从技术角度讨论了存储字符串类型数据时的选择依据,属于设计表结构时的一些指导原则。本节将以工作指导书的形式介绍在工作中经常涉及的几个业务场景中的字段类型选择及原因,帮助读者更深刻的理解各字段类型的差异。
    4.1 记录状态及可枚举值
    在数据库设计中,我们常常需要表示记录状态的字段。比如,用“R”表示记录已发布,“O”表示记录被检出;再比如用“O”表示树节点已展开,用“C”表示树节点已关闭;甚至表示布尔,用“1”表示真,用“0”表示假。
    这类场景存储的字符串具有定长(或最大长度可知)、可枚举、信息通常为英文字母或数字、经常作为检索过滤条件等特点。
    对于这类场景,我们通常使用CHAR类型字段进行存储。
    4.2 GUID、UUID与MD5
    GUID和UUID是我们经常使用的全局唯一标识符。它们具有长度、格式统一,字符可枚举(16进制数字)的特点。相应的,用于校验的MD5、SH-11、CRC等也有类似的特征。
    对于这类字符串,我们通常使用CHAR类型字段来存储。
    4.3 单据号、证件号
    业务系统中经常需要存储符合一定格式的单据号、证件号。它们除了具有定长、字符可枚举的特点外,还是一些信息的编码集合。以身份证为例,18位数字中就包含了户籍地址、出生日期、性别、校验码等信息。因此,它们通常会被用于创建文本索引或函数索引。
    对于单据号、证件号类型的字符串,我们通常使用CHAR类型字段来存储。
    4.4 普通字符串
    对于诸如“产品型号”、“产品规格”等一般业务属性字符串,通常符合变长、长度不超过4000字节的特征。
    因此,我们可以使用VARCHAR2来存储这个类型的字符串。
    4.5 静态页面、大文本
    在一些web项目中,我们会将静态页面文件存储在数据库表中。一些基于诸如FreeMarker等模版引擎的项目也会将模版文件存储于数据库表中。另外,一些类似论坛、博客、新闻功能的应用也存在存储大量字符串的需求。
    对于以上类型的需求,用排除法可知,能够几乎不受长度限制进行大文本存储的类型只有CLOB和NCLOB。当然,依前所述,我更倾向于使用CLOB。

    展开全文
  • 关系数据库中关键技术

    千次阅读 2016-05-05 15:12:53
    MySQL 的存储引擎可能是所有关系数据库产品最具有特色的了,不仅可以同时使用多种存储引擎,而且每种存储引擎和MySQL之间使用插件方式这种非常松的耦合关系。 由于各存储引擎功能特性差异较大,这篇文章主要是...

    存储引擎

    MySQL 的存储引擎可能是所有关系型数据库产品中最具有特色的了,不仅可以同时使用多种存储引擎,而且每种存储引擎和MySQL之间使用插件方式这种非常松的耦合关系。

    由于各存储引擎功能特性差异较大,这篇文章主要是介绍如何来选择合适的存储引擎来应对不同的业务场景。

    MyISAM

    1.特性

    不支持事务:MyISAM存储引擎不支持事务,所以对事务有要求的业务场景不能使用

    表级锁定:其锁定机制是表级索引,这虽然可以让锁定的实现成本很小但是也同时大大降低了其并发性能

    读写互相阻塞:不仅会在写入的时候阻塞读取,MyISAM还会在读取的时候阻塞写入,但读本身并不会阻塞另外的读

    只会缓存索引:MyISAM可以通过key_buffer缓存以大大提高访问性能减少磁盘IO,但是这个缓存区只会缓存索引,而不会缓存数据

    2.适用场景

    不需要事务支持(不支持)

    并发相对较低(锁定机制问题)

    数据修改相对较少(阻塞问题)

    以读为主

    数据一致性要求不是非常高

    3.最佳实践

    尽量索引(缓存机制)

    调整读写优先级,根据实际需求确保重要操作更优先

    启用延迟插入改善大批量写入性能

    尽量顺序操作让insert数据都写入到尾部,减少阻塞

    分解大的操作,降低单个操作的阻塞时间

    降低并发数,某些高并发场景通过应用来进行排队机制

    对于相对静态的数据,充分利用Query Cache可以极大的提高访问效率

    MyISAM的Count只有在全表扫描的时候特别高效,带有其他条件的count都需要进行实际的数据访问

    InnoDB

    1.特性

    具有较好的事务支持:支持4个事务隔离级别,支持多版本读

    行级锁定:通过索引实现,全表扫描仍然会是表锁,注意间隙锁的影响

    读写阻塞与事务隔离级别相关

    具有非常高效的缓存特性:能缓存索引,也能缓存数据

    整个表和主键以Cluster方式存储,组成一颗平衡树

    所有Secondary Index都会保存主键信息

    2.适用场景

    需要事务支持(具有较好的事务特性)

    行级锁定对高并发有很好的适应能力,但需要确保查询是通过索引完成

    数据更新较为频繁的场景

    数据一致性要求较高

    硬件设备内存较大,可以利用InnoDB较好的缓存能力来提高内存利用率,尽可能减少磁盘 IO

    3.最佳实践

    主键尽可能小,避免给Secondary index带来过大的空间负担

    避免全表扫描,因为会使用表锁

    尽可能缓存所有的索引和数据,提高响应速度

    在大批量小插入的时候,尽量自己控制事务而不要使用autocommit自动提交

    合理设置innodb_flush_log_at_trx_commit参数值,不要过度追求安全性

    避免主键更新,因为这会带来大量的数据移动

    NDBCluster

    1.特性

    分布式:分布式存储引擎,可以由多个NDBCluster存储引擎组成集群分别存放整体数据的一部分

    支持事务:和Innodb一样,支持事务

    可与mysqld不在一台主机:可以和mysqld分开存在于独立的主机上,然后通过网络和mysqld通信交互

    内存需求量巨大:新版本索引以及被索引的数据必须存放在内存中,老版本所有数据和索引必须存在与内存中

    2.适用场景

    具有非常高的并发需求

    对单个请求的响应并不是非常的critical

    查询简单,过滤条件较为固定,每次请求数据量较少,又不希望自己进行水平Sharding

    3.最佳实践

    尽可能让查询简单,避免数据的跨节点传输

    尽可能满足SQL节点的计算性能,大一点的集群SQL节点会明显多余Data节点

    在各节点之间尽可能使用万兆网络环境互联,以减少数据在网络层传输过程中的延时

    注:以上三个存储引擎是目前相对主流的存储引擎,还有其他类似如:Memory,Merge,CSV,Archive等存储引擎的使用场景都相对较少,这里就不一一分析了,如果有朋友感兴趣,后面再补充吧。

    如今Bigtable型(列族)数据库应用越来越广,功能也很强大。但是很多人还是把它当做关系型数据库在使用,用原来关系型数据库的思维建表、存储、查询。本文以hbase举例讲述数据模式的变化。

    传统关系型数据库(mysql,oracle)数据存储方式主要如下:

    图一

    上图是个很典型的数据储存方式,我把每条记录分成3部分: 主键、记录属性、索引字段。我们会对索引字段建立索引,达到 二级索引的效果。

    但是随着业务的发展,查询条件越来越复杂,需要更多的索引字段,且很多值都不存在,如下图:

    图二

    上图是6个索引字段,实际情况可能是上百个甚至更多,并且还需要根据多个索引字段刷选。查询性能越来越低,甚至无法满足查询要求。关系型数据里的局限也开始显现,于是很多人开始接触NoSQL。

    列族数据库很强大,很多人就想把数据从mysql迁到hbase,存储的方式还是跟图一或者图二一样,主键为rowkey。其他各个字段的数据,存储一个列族下的不同列。但是想对索引字段查询就没有办法,目前还没有比较好的基于bigtable的二级索引方案,所以无法对索引字段做查询。

    这时候其实可以转换下思维,可以把数据倒过来,如下图:

    图三

    把各个索引字段的值作为rowkey,然后把记录的主键和属性值按照一定顺序存在对应rowkey的value里。上图只有一个列族,是最简单的方式。 Value里的记录可以设置成定长的byte[],多个记录集合通过移位快速查询到。

    但是上面只适合单个索引字段的查询。如果要同时对多个索引字段查询,图三的方式需要求取出所有value值,比如查询“浙江”and“手机”,需要取出两个value,再解析出各自的主键求交。如果每条记录的属性有上百个,对性能影响很大。

    接下来的变化是解决多索引字段查询的问题。我们将 主键字段和属性字段分开存储,储存在不同的列族下,多索引查询只需要取出列族1下的数据,再去最小集合的列族2里取得想要的值。储存如图四:

    图四

    为什么是不同列族,而不是一个列族下的两个列?

    列族数据库数据文件是按照列族分的。在取数据时,都会把一个列族的所有列数据都取出来,事实上我们并不需要把记录明细取出来,所以把这部分数据放到了另一个列族下。

    接下来是对列族2扩展,列族2储存更多的列,用来做各种刷选、计算处理。如下图:

    图五

    后来我感觉这玩样越来越像搜索了。。。

    索引设计

    为了使索引的使用效率更高,在创建索引时,必须考虑在哪些字段上创建索引和创建什么类型的索引。本小节将向读者介绍一些索引的设计原则。

    1.选择唯一性索引

    唯一性索引的值是唯一的,可以更快速的通过该索引来确定某条记录。例如,学生表中学号是具有唯一性的字段。为该字段建立唯一性索引可以很快的确定某个学生的信息。如果使用姓名的话,可能存在同名现象,从而降低查询速度。

    2.为经常需要排序、分组和联合操作的字段建立索引

    经常需要ORDER BY、GROUP BY、DISTINCT和UNION等操作的字段,排序操作会浪费很多时间。如果为其建立索引,可以有效地避免排序操作。

    3.为常作为查询条件的字段建立索引

    如果某个字段经常用来做查询条件,那么该字段的查询速度会影响整个表的查询速度。因此,为这样的字段建立索引,可以提高整个表的查询速度。

    4.限制索引的数目

    索引的数目不是越多越好。每个索引都需要占用磁盘空间,索引越多,需要的磁盘空间就越大。修改表时,对索引的重构和更新很麻烦。越多的索引,会使更新表变得很浪费时间。

    5.尽量使用数据量少的索引

    如果索引的值很长,那么查询的速度会受到影响。例如,对一个CHAR(100)类型的字段进行全文检索需要的时间肯定要比对CHAR(10)类型的字段需要的时间要多。

    6.尽量使用前缀来索引

    如果索引字段的值很长,最好使用值的前缀来索引。例如,TEXT和BLOG类型的字段,进行全文检索会很浪费时间。如果只检索字段的前面的若干个字符,这样可以提高检索速度。

    7.删除不再使用或者很少使用的索引

    表中的数据被大量更新,或者数据的使用方式被改变后,原有的一些索引可能不再需要。数据库管理员应当定期找出这些索引,将它们删除,从而减少索引对更新操作的影响。

    注意:选择索引的最终目的是为了使查询的速度变快。上面给出的原则是最基本的准则,但不能拘泥于上面的准则。读者要在以后的学习和工作中进行不断的实践。根据应用的实际情况进行分析和判断,选择最合适的索引方式。

    SQL 优化

    (一)深入浅出理解索引结构

    实际上,您可以把索引理解为一种特殊的目录。微软的SQL SERVER提供了两种索引:聚集索引(clustered index,也称聚类索引、簇集索引)和非聚集索引(nonclustered index,也称非聚类索引、非簇集索引)。下面,我们举例来说明一下聚集索引和非聚集索引的区别:

    其实,我们的汉语字典的正文本身就是一个聚集索引。比如,我们要查“安”字,就会很自然地翻开字典的前几页,因为“安”的拼音是“an”,而按照拼音排序汉字的字典是以英文字母“a”开头并以“z”结尾的,那么“安”字就自然地排在字典的前部。如果您翻完了所有以“a”开头的部分仍然找不到这个字,那么就说明您的字典中没有这个字;同样的,如果查“张”字,那您也会将您的字典翻到最后部分,因为“张”的拼音是“zhang”。也就是说,字典的正文部分本身就是一个目录,您不需要再去查其他目录来找到您需要找的内容。

    我们把这种正文内容本身就是一种按照一定规则排列的目录称为“聚集索引”。

    如果您认识某个字,您可以快速地从自动中查到这个字。但您也可能会遇到您不认识的字,不知道它的发音,这时候,您就不能按照刚才的方法找到您要查的字,而需要去根据“偏旁部首”查到您要找的字,然后根据这个字后的页码直接翻到某页来找到您要找的字。但您结合“部首目录”和“检字表”而查到的字的排序并不是真正的正文的排序方法,比如您查“张”字,我们可以看到在查部首之后的检字表中“张”的页码是672页,检字表中“张”的上面是“驰”字,但页码却是63页,“张”的下面是“弩”字,页面是390页。很显然,这些字并不是真正的分别位于“张”字的上下方,现在您看到的连续的“驰、张、弩”三字实际上就是他们在非聚集索引中的排序,是字典正文中的字在非聚集索引中的映射。我们可以通过这种方式来找到您所需要的字,但它需要两个过程,先找到目录中的结果,然后再翻到您所需要的页码。

    我们把这种目录纯粹是目录,正文纯粹是正文的排序方式称为“非聚集索引”。

    通过以上例子,我们可以理解到什么是“聚集索引”和“非聚集索引”。

    进一步引申一下,我们可以很容易的理解:每个表只能有一个聚集索引,因为目录只能按照一种方法进行排序。

    (二)何时使用聚集索引或非聚集索引

    下面的表总结了何时使用聚集索引或非聚集索引(很重要)。

    动作描述

    使用聚集索引

    使用非聚集索引

    列经常被分组排序

    返回某范围内的数据

    不应

    一个或极少不同值

    不应

    不应

    小数目的不同值

    不应

    大数目的不同值

    不应

    频繁更新的列

    不应

    外键列

    主键列

    频繁修改索引列

    不应

    事实上,我们可以通过前面聚集索引和非聚集索引的定义的例子来理解上表。如:返回某范围内的数据一项。比如您的某个表有一个时间列,恰好您把聚合索引建立在了该列,这时您查询2004年1月1日至2004年10月1日之间的全部数据时,这个速度就将是很快的,因为您的这本字典正文是按日期进行排序的,聚类索引只需要找到要检索的所有数据中的开头和结尾数据即可;而不像非聚集索引,必须先查到目录中查到每一项数据对应的页码,然后再根据页码查到具体内容。

    (三)结合实际,谈索引使用的误区

    理论的目的是应用。虽然我们刚才列出了何时应使用聚集索引或非聚集索引,但在实践中以上规则却很容易被忽视或不能根据实际情况进行综合分析。下面我们将根据在实践中遇到的实际问题来谈一下索引使用的误区,以便于大家掌握索引建立的方法。

    1、主键就是聚集索引

    这种想法笔者认为是极端错误的,是对聚集索引的一种浪费。虽然SQL SERVER默认是在主键上建立聚集索引的。

    通常,我们会在每个表中都建立一个ID列,以区分每条数据,并且这个ID列是自动增大的,步长一般为1。我们的这个办公自动化的实例中的列Gid就是如此。此时,如果我们将这个列设为主键,SQL SERVER会将此列默认为聚集索引。这样做有好处,就是可以让您的数据在数据库中按照ID进行物理排序,但笔者认为这样做意义不大。

    显而易见,聚集索引的优势是很明显的,而每个表中只能有一个聚集索引的规则,这使得聚集索引变得更加珍贵。

    从我们前面谈到的聚集索引的定义我们可以看出,使用聚集索引的最大好处就是能够根据查询要求,迅速缩小查询范围,避免全表扫描。在实际应用中,因为ID号是自动生成的,我们并不知道每条记录的ID号,所以我们很难在实践中用ID号来进行查询。这就使让ID号这个主键作为聚集索引成为一种资源浪费。其次,让每个ID号都不同的字段作为聚集索引也不符合“大数目的不同值情况下不应建立聚合索引”规则;当然,这种情况只是针对用户经常修改记录内容,特别是索引项的时候会负作用,但对于查询速度并没有影响。

    在办公自动化系统中,无论是系统首页显示的需要用户签收的文件、会议还是用户进行文件查询等任何情况下进行数据查询都离不开字段的是“日期”还有用户本身的“用户名”。

    通常,办公自动化的首页会显示每个用户尚未签收的文件或会议。虽然我们的where语句可以仅仅限制当前用户尚未签收的情况,但如果您的系统已建立了很长时间,并且数据量很大,那么,每次每个用户打开首页的时候都进行一次全表扫描,这样做意义是不大的,绝大多数的用户1个月前的文件都已经浏览过了,这样做只能徒增数据库的开销而已。事实上,我们完全可以让用户打开系统首页时,数据库仅仅查询这个用户近3个月来未阅览的文件,通过“日期”这个字段来限制表扫描,提高查询速度。如果您的办公自动化系统已经建立的2年,那么您的首页显示速度理论上将是原来速度8倍,甚至更快。

    在这里之所以提到“理论上”三字,是因为如果您的聚集索引还是盲目地建在ID这个主键上时,您的查询速度是没有这么高的,即使您在“日期”这个字段上建立的索引(非聚合索引)。下面我们就来看一下在1000万条数据量的情况下各种查询的速度表现(3个月内的数据为25万条):

    (1)仅在主键上建立聚集索引,并且不划分时间段:

    Select gid,fariqi,neibuyonghu,title from tgongwen

    用时:128470毫秒(即:128秒)

    (2)在主键上建立聚集索引,在fariq上建立非聚集索引:

    select gid,fariqi,neibuyonghu,title from Tgongwen

    where fariqi> dateadd(day,-90,getdate())

    用时:53763毫秒(54秒)

    (3)将聚合索引建立在日期列(fariqi)上:

    select gid,fariqi,neibuyonghu,title from Tgongwen

    where fariqi> dateadd(day,-90,getdate())

    用时:2423毫秒(2秒)

    虽然每条语句提取出来的都是25万条数据,各种情况的差异却是巨大的,特别是将聚集索引建立在日期列时的差异。事实上,如果您的数据库真的有1000万容量的话,把主键建立在ID列上,就像以上的第1、2种情况,在网页上的表现就是超时,根本就无法显示。这也是我摒弃ID列作为聚集索引的一个最重要的因素。

    得出以上速度的方法是:在各个select语句前加:declare @d datetime

    set @d=getdate()

    并在select语句后加:

    select [语句执行花费时间(毫秒)]=datediff(ms,@d,getdate())

    2、只要建立索引就能显著提高查询速度

    事实上,我们可以发现上面的例子中,第2、3条语句完全相同,且建立索引的字段也相同;不同的仅是前者在fariqi字段上建立的是非聚合索引,后者在此字段上建立的是聚合索引,但查询速度却有着天壤之别。所以,并非是在任何字段上简单地建立索引就能提高查询速度。

    从建表的语句中,我们可以看到这个有着1000万数据的表中fariqi字段有5003个不同记录。在此字段上建立聚合索引是再合适不过了。在现实中,我们每天都会发几个文件,这几个文件的发文日期就相同,这完全符合建立聚集索引要求的:“既不能绝大多数都相同,又不能只有极少数相同”的规则。由此看来,我们建立“适当”的聚合索引对于我们提高查询速度是非常重要的。

    3、把所有需要提高查询速度的字段都加进聚集索引,以提高查询速度

    上面已经谈到:在进行数据查询时都离不开字段的是“日期”还有用户本身的“用户名”。既然这两个字段都是如此的重要,我们可以把他们合并起来,建立一个复合索引(compound index)。

    很多人认为只要把任何字段加进聚集索引,就能提高查询速度,也有人感到迷惑:如果把复合的聚集索引字段分开查询,那么查询速度会减慢吗?带着这个问题,我们来看一下以下的查询速度(结果集都是25万条数据):(日期列fariqi首先排在复合聚集索引的起始列,用户名neibuyonghu排在后列)

    (1)select gid,fariqi,neibuyonghu,title from Tgongwen where fariqi>’2004-5-5′

    查询速度:2513毫秒

    (2)select gid,fariqi,neibuyonghu,title from Tgongwen where fariqi>’2004-5-5′ and neibuyonghu=’办公室’

    查询速度:2516毫秒

    (3)select gid,fariqi,neibuyonghu,title from Tgongwen where neibuyonghu=’办公室’

    查询速度:60280毫秒

    从以上试验中,我们可以看到如果仅用聚集索引的起始列作为查询条件和同时用到复合聚集索引的全部列的查询速度是几乎一样的,甚至比用上全部的复合索引列还要略快(在查询结果集数目一样的情况下);而如果仅用复合聚集索引的非起始列作为查询条件的话,这个索引是不起任何作用的。当然,语句1、2的查询速度一样是因为查询的条目数一样,如果复合索引的所有列都用上,而且查询结果少的话,这样就会形成“索引覆盖”,因而性能可以达到最优。同时,请记住:无论您是否经常使用聚合索引的其他列,但其前导列一定要是使用最频繁的列。

    (四)其他书上没有的索引使用经验总结

    1、用聚合索引比用不是聚合索引的主键速度快

    下面是实例语句:(都是提取25万条数据)

    select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi=’2004-9-16′

    使用时间:3326毫秒

    select gid,fariqi,neibuyonghu,reader,title from Tgongwen where gid<=250000

    使用时间:4470毫秒

    这里,用聚合索引比用不是聚合索引的主键速度快了近1/4。

    2、用聚合索引比用一般的主键作order by时速度快,特别是在小数据量情况下

    select gid,fariqi,neibuyonghu,reader,title from Tgongwen order by fariqi

    用时:12936

    select gid,fariqi,neibuyonghu,reader,title from Tgongwen order by gid

    用时:18843

    这里,用聚合索引比用一般的主键作order by时,速度快了3/10。事实上,如果数据量很小的话,用聚集索引作为排序列要比使用非聚集索引速度快得明显的多;而数据量如果很大的话,如10万以上,则二者的速度差别不明显。

    3、使用聚合索引内的时间段,搜索时间会按数据占整个数据表的百分比成比例减少,而无论聚合索引使用了多少个

    select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi>’2004-1-1′

    用时:6343毫秒(提取100万条)

    select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi>’2004-6-6′

    用时:3170毫秒(提取50万条)

    select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi=’2004-9-16′

    用时:3326毫秒(和上句的结果一模一样。如果采集的数量一样,那么用大于号和等于号是一样的)

    select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi>’2004-1-1′ and fariqi<‘2004-6-6′

    用时:3280毫秒

    4 、日期列不会因为有分秒的输入而减慢查询速度

    下面的例子中,共有100万条数据,2004年1月1日以后的数据有50万条,但只有两个不同的日期,日期精确到日;之前有数据50万条,有5000个不同的日期,日期精确到秒。

    select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi>’2004-1-1′ order by fariqi

    用时:6390毫秒

    select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi<‘2004-1-1′ order by fariqi

    用时:6453毫秒

    (五)其他注意事项

    “水可载舟,亦可覆舟”,索引也一样。索引有助于提高检索性能,但过多或不当的索引也会导致系统低效。因为用户在表中每加进一个索引,数据库就要做更多的工作。过多的索引甚至会导致索引碎片。

    所以说,我们要建立一个“适当”的索引体系,特别是对聚合索引的创建,更应精益求精,以使您的数据库能得到高性能的发挥。

    当然,在实践中,作为一个尽职的数据库管理员,您还要多测试一些方案,找出哪种方案效率最高、最为有效。

    二、改善SQL语句

    很多人不知道SQL语句在SQL SERVER中是如何执行的,他们担心自己所写的SQL语句会被SQL SERVER误解。比如:

    select * from table1 where name=’zhangsan’ and tID > 10000

    和执行:

    select * from table1 where tID > 10000 and name=’zhangsan’

    一些人不知道以上两条语句的执行效率是否一样,因为如果简单的从语句先后上看,这两个语句的确是不一样,如果tID是一个聚合索引,那么后一句仅仅从表的10000条以后的记录中查找就行了;而前一句则要先从全表中查找看有几个name=’zhangsan’的,而后再根据限制条件条件tID>10000来提出查询结果。

    事实上,这样的担心是不必要的。SQL SERVER中有一个“查询分析优化器”,它可以计算出where子句中的搜索条件并确定哪个索引能缩小表扫描的搜索空间,也就是说,它能实现自动优化。

    虽然查询优化器可以根据where子句自动的进行查询优化,但大家仍然有必要了解一下“查询优化器”的工作原理,如非这样,有时查询优化器就会不按照您的本意进行快速查询。

    在查询分析阶段,查询优化器查看查询的每个阶段并决定限制需要扫描的数据量是否有用。如果一个阶段可以被用作一个扫描参数(SARG),那么就称之为可优化的,并且可以利用索引快速获得所需数据。

    SARG的定义:用于限制搜索的一个操作,因为它通常是指一个特定的匹配,一个值得范围内的匹配或者两个以上条件的AND连接。形式如下:

    列名 操作符 <常数 或 变量>

    <常数 或 变量> 操作符列名

    列名可以出现在操作符的一边,而常数或变量出现在操作符的另一边。如:

    Name=’张三’

    价格>5000

    5000<价格

    Name=’张三’ and 价格>5000

    如果一个表达式不能满足SARG的形式,那它就无法限制搜索的范围了,也就是SQL SERVER必须对每一行都判断它是否满足WHERE子句中的所有条件。所以一个索引对于不满足SARG形式的表达式来说是无用的。

    介绍完SARG后,我们来总结一下使用SARG以及在实践中遇到的和某些资料上结论不同的经验:

    1、Like语句是否属于SARG取决于所使用的通配符的类型

    如:name like ‘张%’ ,这就属于SARG

    而:name like ‘%张’,就不属于SARG。

    原因是通配符%在字符串的开通使得索引无法使用。

    2、or 会引起全表扫描

    Name=’张三’ and 价格>5000 符号SARG,而:Name=’张三’ or 价格>5000 则不符合SARG。使用or会引起全表扫描。

    3、非操作符、函数引起的不满足SARG形式的语句

    不满足SARG形式的语句最典型的情况就是包括非操作符的语句,如:NOT、!=、<>、!<、!>、NOT EXISTS、NOT IN、NOT LIKE等,另外还有函数。下面就是几个不满足SARG形式的例子:

    ABS(价格)<5000

    Name like ‘%三’

    有些表达式,如:

    WHERE 价格*2>5000

    SQL SERVER也会认为是SARG,SQL SERVER会将此式转化为:

    WHERE 价格>2500/2

    但我们不推荐这样使用,因为有时SQL SERVER不能保证这种转化与原始表达式是完全等价的。

    4、IN 的作用相当与OR

    语句:

    Select * from table1 where tid in (2,3)

    Select * from table1 where tid=2 or tid=3

    是一样的,都会引起全表扫描,如果tid上有索引,其索引也会失效。

    5、尽量少用NOT

    6、exists 和 in 的执行效率是一样的

    很多资料上都显示说,exists要比in的执行效率要高,同时应尽可能的用not exists来代替not in。但事实上,我试验了一下,发现二者无论是前面带不带not,二者之间的执行效率都是一样的。因为涉及子查询,我们试验这次用SQL SERVER自带的pubs数据库。运行前我们可以把SQL SERVER的statistics I/O状态打开。

    (1)select title,price from titles where title_id in (select title_id from sales where qty>30)

    该句的执行结果为:

    表 ‘sales’。扫描计数 18,逻辑读 56 次,物理读 0 次,预读 0 次。

    表 ‘titles’。扫描计数 1,逻辑读 2 次,物理读 0 次,预读 0 次。

    (2)select title,price from titles where exists (select * from sales where sales.title_id=titles.title_id and qty>30)

    第二句的执行结果为:

    表 ‘sales’。扫描计数 18,逻辑读 56 次,物理读 0 次,预读 0 次。

    表 ‘titles’。扫描计数 1,逻辑读 2 次,物理读 0 次,预读 0 次。

    我们从此可以看到用exists和用in的执行效率是一样的。

    7、用函数charindex()和前面加通配符%的LIKE执行效率一样

    前面,我们谈到,如果在LIKE前面加上通配符%,那么将会引起全表扫描,所以其执行效率是低下的。但有的资料介绍说,用函数charindex()来代替LIKE速度会有大的提升,经我试验,发现这种说明也是错误的:

    select gid,title,fariqi,reader from tgongwen where charindex(‘刑侦支队’,reader)>0 and fariqi>’2004-5-5′

    用时:7秒,另外:扫描计数 4,逻辑读 7155 次,物理读 0 次,预读 0 次。

    select gid,title,fariqi,reader from tgongwen where reader like ‘%’ + ‘刑侦支队’ + ‘%’ and fariqi>’2004-5-5′

    用时:7秒,另外:扫描计数 4,逻辑读 7155 次,物理读 0 次,预读 0 次。

    8、union并不绝对比or的执行效率高

    我们前面已经谈到了在where子句中使用or会引起全表扫描,一般的,我所见过的资料都是推荐这里用union来代替or。事实证明,这种说法对于大部分都是适用的。

    select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi=’2004-9-16′ or gid>9990000

    用时:68秒。扫描计数 1,逻辑读 404008 次,物理读 283 次,预读 392163 次。

    select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi=’2004-9-16′

    union

    select gid,fariqi,neibuyonghu,reader,title from Tgongwen where gid>9990000

    用时:9秒。扫描计数 8,逻辑读 67489 次,物理读 216 次,预读 7499 次。

    看来,用union在通常情况下比用or的效率要高的多。

    但经过试验,笔者发现如果or两边的查询列是一样的话,那么用union则反倒和用or的执行速度差很多,虽然这里union扫描的是索引,而or扫描的是全表。

    select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi=’2004-9-16′ or fariqi=’2004-2-5′

    用时:6423毫秒。扫描计数 2,逻辑读 14726 次,物理读 1 次,预读 7176 次。

    select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi=’2004-9-16′

    union

    select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi=’2004-2-5′

    用时:11640毫秒。扫描计数 8,逻辑读 14806 次,物理读 108 次,预读 1144 次。

    9、字段提取要按照“需多少、提多少”的原则,避免“select *”

    我们来做一个试验:

    select top 10000 gid,fariqi,reader,title from tgongwen order by gid desc

    用时:4673毫秒

    select top 10000 gid,fariqi,title from tgongwen order by gid desc

    用时:1376毫秒

    select top 10000 gid,fariqi from tgongwen order by gid desc

    用时:80毫秒

    由此看来,我们每少提取一个字段,数据的提取速度就会有相应的提升。提升的速度还要看您舍弃的字段的大小来判断。

    10、count(*)不比count(字段)慢

    某些资料上说:用*会统计所有列,显然要比一个世界的列名效率低。这种说法其实是没有根据的。我们来看:

    select count(*) from Tgongwen

    用时:1500毫秒

    select count(gid) from Tgongwen

    用时:1483毫秒

    select count(fariqi) from Tgongwen

    用时:3140毫秒

    select count(title) from Tgongwen

    用时:52050毫秒

    从以上可以看出,如果用count(*)和用count(主键)的速度是相当的,而count(*)却比其他任何除主键以外的字段汇总速度要快,而且字段越长,汇总的速度就越慢。我想,如果用count(*), SQL SERVER可能会自动查找最小字段来汇总的。当然,如果您直接写count(主键)将会来的更直接些。

    11、order by按聚集索引列排序效率最高

    我们来看:(gid是主键,fariqi是聚合索引列)

    select top 10000 gid,fariqi,reader,title from tgongwen

    用时:196 毫秒。 扫描计数 1,逻辑读 289 次,物理读 1 次,预读 1527 次。

    select top 10000 gid,fariqi,reader,title from tgongwen order by gid asc

    用时:4720毫秒。 扫描计数 1,逻辑读 41956 次,物理读 0 次,预读 1287 次。

    select top 10000 gid,fariqi,reader,title from tgongwen order by gid desc

    用时:4736毫秒。 扫描计数 1,逻辑读 55350 次,物理读 10 次,预读 775 次。

    select top 10000 gid,fariqi,reader,title from tgongwen order by fariqi asc

    用时:173毫秒。 扫描计数 1,逻辑读 290 次,物理读 0 次,预读 0 次。

    select top 10000 gid,fariqi,reader,title from tgongwen order by fariqi desc

    用时:156毫秒。 扫描计数 1,逻辑读 289 次,物理读 0 次,预读 0 次。

    从以上我们可以看出,不排序的速度以及逻辑读次数都是和“order by 聚集索引列” 的速度是相当的,但这些都比“order by 非聚集索引列”的查询速度是快得多的。

    同时,按照某个字段进行排序的时候,无论是正序还是倒序,速度是基本相当的。

    12、高效的TOP

    事实上,在查询和提取超大容量的数据集时,影响数据库响应时间的最大因素不是数据查找,而是物理的I/0操作。如:

    select top 10 * from (

    select top 10000 gid,fariqi,title from tgongwen

    where neibuyonghu=’办公室’

    order by gid desc) as a

    order by gid asc

    这条语句,从理论上讲,整条语句的执行时间应该比子句的执行时间长,但事实相反。因为,子句执行后返回的是10000条记录,而整条语句仅返回10条语句,所以影响数据库响应时间最大的因素是物理I/O操作。而限制物理I/O操作此处的最有效方法之一就是使用TOP关键词了。TOP关键词是SQL SERVER中经过系统优化过的一个用来提取前几条或前几个百分比数据的词。经笔者在实践中的应用,发现TOP确实很好用,效率也很高。但这个词在另外一个大型数据库ORACLE中却没有,这不能说不是一个遗憾,虽然在ORACLE中可以用其他方法(如:rownumber)来解决。在以后的关于“实现千万级数据的分页显示存储过程”的讨论中,我们就将用到TOP这个关键词。

    到此为止,我们上面讨论了如何实现从大容量的数据库中快速地查询出您所需要的数据方法。当然,我们介绍的这些方法都是“软”方法,在实践中,我们还要考虑各种“硬”因素,如:网络性能、服务器的性能、操作系统的性能,甚至网卡、交换机等。

    三、实现小数据量和海量数据的通用分页显示存储过程

    建立一个web 应用,分页浏览功能必不可少。这个问题是数据库处理中十分常见的问题。经典的数据分页方法是:ADO 纪录集分页法,也就是利用ADO自带的分页功能(利用游标)来实现分页。但这种分页方法仅适用于较小数据量的情形,因为游标本身有缺点:游标是存放在内存中,很费内存。游标一建立,就将相关的记录锁住,直到取消游标。游标提供了对特定集合中逐行扫描的手段,一般使用游标来逐行遍历数据,根据取出数据条件的不同进行不同的操作。而对于多表和大表中定义的游标(大的数据集合)循环很容易使程序进入一个漫长的等待甚至死机。

    更重要的是,对于非常大的数据模型而言,分页检索时,如果按照传统的每次都加载整个数据源的方法是非常浪费资源的。现在流行的分页方法一般是检索页面大小的块区的数据,而非检索所有的数据,然后单步执行当前行。

    最早较好地实现这种根据页面大小和页码来提取数据的方法大概就是“俄罗斯存储过程”。这个存储过程用了游标,由于游标的局限性,所以这个方法并没有得到大家的普遍认可。

    后来,网上有人改造了此存储过程,下面的存储过程就是结合我们的办公自动化实例写的分页存储过程:

    CREATE procedure pagination1

    (@pagesize int, –页面大小,如每页存储20条记录

    @pageindex int –当前页码

    )

    as

    set nocount on

    begin

    declare @indextable table(id int identity(1,1),nid int) –定义表变量

    declare @PageLowerBound int –定义此页的底码

    declare @PageUpperBound int –定义此页的顶码

    set @PageLowerBound=(@pageindex-1)*@pagesize

    set @PageUpperBound=@PageLowerBound+@pagesize

    set rowcount @PageUpperBound

    insert into @indextable(nid) select gid from TGongwen where fariqi >dateadd(day,-365,getdate()) order by fariqi desc

    select O.gid,O.mid,O.title,O.fadanwei,O.fariqi from TGongwen O,@indextable t where O.gid=t.nid

    and t.id>@PageLowerBound and t.id<=@PageUpperBound order by t.id

    end

    set nocount off

    以上存储过程运用了SQL SERVER的最新技术――表变量。应该说这个存储过程也是一个非常优秀的分页存储过程。当然,在这个过程中,您也可以把其中的表变量写成临时表:CREATE TABLE #Temp。但很明显,在SQL SERVER中,用临时表是没有用表变量快的。所以笔者刚开始使用这个存储过程时,感觉非常的不错,速度也比原来的ADO的好。但后来,我又发现了比此方法更好的方法。

    笔者曾在网上看到了一篇小短文《从数据表中取出第n条到第m条的记录的方法》,全文如下:

    从publish 表中取出第 n 条到第 m 条的记录:


    SELECT TOP m-n+1 *
    FROM publish
    WHERE (id NOT IN
    (SELECT TOP n-1 id
    FROM publish))

    id 为publish 表的关键字

    我当时看到这篇文章的时候,真的是精神为之一振,觉得思路非常得好。等到后来,我在作办公自动化系统(ASP.NET+ C#+SQL SERVER)的时候,忽然想起了这篇文章,我想如果把这个语句改造一下,这就可能是一个非常好的分页存储过程。于是我就满网上找这篇文章,没想到,文章还没找到,却找到了一篇根据此语句写的一个分页存储过程,这个存储过程也是目前较为流行的一种分页存储过程,我很后悔没有争先把这段文字改造成存储过程:

    CREATE PROCEDURE pagination2
    (
    @SQL nVARCHAR(4000), –不带排序语句的SQL语句
    @Page int, –页码
    @RecsPerPage int, –每页容纳的记录数
    @ID VARCHAR(255), –需要排序的不重复的ID号
    @Sort VARCHAR(255) –排序字段及规则
    )
    AS

    DECLARE @Str nVARCHAR(4000)

    SET @Str=’SELECT TOP ‘+CAST(@RecsPerPage AS VARCHAR(20))+’ * FROM (‘+@SQL+’) T WHERE T.’+@ID+’NOT IN
    (SELECT TOP ‘+CAST((@RecsPerPage*(@Page-1)) AS VARCHAR(20))+’ ‘+@ID+’ FROM (‘+@SQL+’) T9 ORDER BY ‘+@Sort+’) ORDER BY ‘+@Sort

    PRINT @Str

    EXEC sp_ExecuteSql @Str
    GO

    其实,以上语句可以简化为:

    SELECT TOP 页大小 *

    FROM Table1

    WHERE (ID NOT IN

    (SELECT TOP 页大小*页数 id

    FROM 表

    ORDER BY id))

    ORDER BY ID

    但这个存储过程有一个致命的缺点,就是它含有NOT IN字样。虽然我可以把它改造为:

    SELECT TOP 页大小 *

    FROM Table1

    WHERE not exists

    (select * from (select top (页大小*页数) * from table1 order by id) b where b.id=a.id )

    order by id

    即,用not exists来代替not in,但我们前面已经谈过了,二者的执行效率实际上是没有区别的。

    既便如此,用TOP 结合NOT IN的这个方法还是比用游标要来得快一些。

    虽然用not exists并不能挽救上个存储过程的效率,但使用SQL SERVER中的TOP关键字却是一个非常明智的选择。因为分页优化的最终目的就是避免产生过大的记录集,而我们在前面也已经提到了TOP的优势,通过TOP 即可实现对数据量的控制。

    在分页算法中,影响我们查询速度的关键因素有两点:TOP和NOT IN。TOP可以提高我们的查询速度,而NOT IN会减慢我们的查询速度,所以要提高我们整个分页算法的速度,就要彻底改造NOT IN,同其他方法来替代它。

    我们知道,几乎任何字段,我们都可以通过max(字段)或min(字段)来提取某个字段中的最大或最小值,所以如果这个字段不重复,那么就可以利用这些不重复的字段的max或min作为分水岭,使其成为分页算法中分开每页的参照物。在这里,我们可以用操作符“>”或“<”号来完成这个使命,使查询语句符合SARG形式。如:

    Select top 10 * from table1 where id>200

    于是就有了如下分页方案:

    select top 页大小 *

    from table1

    where id>

    (select max (id) from

    (select top ((页码-1)*页大小) id from table1 order by id) as T

    )

    order by id

    在选择即不重复值,又容易分辨大小的列时,我们通常会选择主键。下表列出了笔者用有着1000万数据的办公自动化系统中的表,在以GID(GID是主键,但并不是聚集索引。)为排序列、提取gid,fariqi,title字段,分别以第1、10、100、500、1000、1万、10万、25万、50万页为例,测试以上三种分页方案的执行速度:(单位:毫秒)

    页 码

    方案1

    方案2

    方案3

    1

    60

    30

    76

    10

    46

    16

    63

    100

    1076

    720

    130

    500

    540

    12943

    83

    1000

    17110

    470

    250

    1万

    24796

    4500

    140

    10万

    38326

    42283

    1553

    25万

    28140

    128720

    2330

    50万

    121686

    127846

    7168

    从上表中,我们可以看出,三种存储过程在执行100页以下的分页命令时,都是可以信任的,速度都很好。但第一种方案在执行分页1000页以上后,速度就降了下来。第二种方案大约是在执行分页1万页以上后速度开始降了下来。而第三种方案却始终没有大的降势,后劲仍然很足。

    在确定了第三种分页方案后,我们可以据此写一个存储过程。大家知道SQL SERVER的存储过程是事先编译好的SQL语句,它的执行效率要比通过WEB页面传来的SQL语句的执行效率要高。下面的存储过程不仅含有分页方案,还会根据页面传来的参数来确定是否进行数据总数统计。

    – 获取指定页的数据

    CREATE PROCEDURE pagination3

    @tblName varchar(255), — 表名

    @strGetFields varchar(1000) = ‘*’, — 需要返回的列

    @fldName varchar(255)=”, — 排序的字段名

    @PageSize int = 10, — 页尺寸

    @PageIndex int = 1, — 页码

    @doCount bit = 0, — 返回记录总数, 非 0 值则返回

    @OrderType bit = 0, — 设置排序类型, 非 0 值则降序

    @strWhere varchar(1500) = ” — 查询条件 (注意: 不要加 where)

    AS

    declare @strSQL varchar(5000) — 主语句

    declare @strTmp varchar(110) — 临时变量

    declare @strOrder varchar(400) — 排序类型

    if @doCount != 0

    begin

    if @strWhere !=”

    set @strSQL = “select count(*) as Total from [" + @tblName + "] where “+@strWhere

    else

    set @strSQL = “select count(*) as Total from [" + @tblName + "]“

    end

    –以上代码的意思是如果@doCount传递过来的不是0,就执行总数统计。以下的所有代码都是@doCount为0的情况

    else

    begin

    if @OrderType != 0

    begin

    set @strTmp = “<(select min”

    set @strOrder = ” order by [" + @fldName +"] desc”

    –如果@OrderType不是0,就执行降序,这句很重要!

    end

    else

    begin

    set @strTmp = “>(select max”

    set @strOrder = ” order by [" + @fldName +"] asc”

    end

    if @PageIndex = 1

    begin

    if @strWhere != ”

    set @strSQL = “select top ” + str(@PageSize) +” “+@strGetFields+ ” from [" + @tblName + "] where ” + @strWhere + ” ” + @strOrder

    else

    set @strSQL = “select top ” + str(@PageSize) +” “+@strGetFields+ ” from ["+ @tblName + "] “+ @strOrder

    –如果是第一页就执行以上代码,这样会加快执行速度

    end

    else

    begin

    –以下代码赋予了@strSQL以真正执行的SQL代码

    set @strSQL = “select top ” + str(@PageSize) +” “+@strGetFields+ ” from ["

    + @tblName + "] where [" + @fldName + "]” + @strTmp + “(["+ @fldName + "]) from (select top ” + str((@PageIndex-1)*@PageSize) + ” ["+ @fldName + "] from [" + @tblName + "]” + @strOrder + “) as tblTmp)”+ @strOrder

    if @strWhere != ”

    set @strSQL = “select top ” + str(@PageSize) +” “+@strGetFields+ ” from ["

    + @tblName + "] where [" + @fldName + "]” + @strTmp + “(["

    + @fldName + "]) from (select top ” + str((@PageIndex-1)*@PageSize) + ” ["

    + @fldName + "] from [" + @tblName + "] where ” + @strWhere + ” “

    + @strOrder + “) as tblTmp) and ” + @strWhere + ” ” + @strOrder

    end

    end

    exec (@strSQL)

    GO

    上面的这个存储过程是一个通用的存储过程,其注释已写在其中了。

    在大数据量的情况下,特别是在查询最后几页的时候,查询时间一般不会超过9秒;而用其他存储过程,在实践中就会导致超时,所以这个存储过程非常适用于大容量数据库的查询。

    笔者希望能够通过对以上存储过程的解析,能给大家带来一定的启示,并给工作带来一定的效率提升,同时希望同行提出更优秀的实时数据分页算法。

    四、聚集索引的重要性和如何选择聚集索引

    在上一节的标题中,笔者写的是:实现小数据量和海量数据的通用分页显示存储过程。这是因为在将本存储过程应用于“办公自动化”系统的实践中时,笔者发现这第三种存储过程在小数据量的情况下,有如下现象:

    1、分页速度一般维持在1秒和3秒之间。

    2、在查询最后一页时,速度一般为5秒至8秒,哪怕分页总数只有3页或30万页。

    虽然在超大容量情况下,这个分页的实现过程是很快的,但在分前几页时,这个1-3秒的速度比起第一种甚至没有经过优化的分页方法速度还要慢,借用户的话说就是“还没有ACCESS数据库速度快”,这个认识足以导致用户放弃使用您开发的系统。

    笔者就此分析了一下,原来产生这种现象的症结是如此的简单,但又如此的重要:排序的字段不是聚集索引!

    本篇文章的题目是:“查询优化及分页算法方案”。笔者只所以把“查询优化”和“分页算法”这两个联系不是很大的论题放在一起,就是因为二者都需要一个非常重要的东西――聚集索引。

    在前面的讨论中我们已经提到了,聚集索引有两个最大的优势:

    1、以最快的速度缩小查询范围。

    2、以最快的速度进行字段排序。

    第1条多用在查询优化时,而第2条多用在进行分页时的数据排序。

    而聚集索引在每个表内又只能建立一个,这使得聚集索引显得更加的重要。聚集索引的挑选可以说是实现“查询优化”和“高效分页”的最关键因素。

    但要既使聚集索引列既符合查询列的需要,又符合排序列的需要,这通常是一个矛盾。

    笔者前面“索引”的讨论中,将fariqi,即用户发文日期作为了聚集索引的起始列,日期的精确度为“日”。这种作法的优点,前面已经提到了,在进行划时间段的快速查询中,比用ID主键列有很大的优势。

    但在分页时,由于这个聚集索引列存在着重复记录,所以无法使用max或min来最为分页的参照物,进而无法实现更为高效的排序。而如果将ID主键列作为聚集索引,那么聚集索引除了用以排序之外,没有任何用处,实际上是浪费了聚集索引这个宝贵的资源。

    为解决这个矛盾,笔者后来又添加了一个日期列,其默认值为getdate()。用户在写入记录时,这个列自动写入当时的时间,时间精确到毫秒。即使这样,为了避免可能性很小的重合,还要在此列上创建UNIQUE约束。将此日期列作为聚集索引列。

    有了这个时间型聚集索引列之后,用户就既可以用这个列查找用户在插入数据时的某个时间段的查询,又可以作为唯一列来实现max或min,成为分页算法的参照物。

    经过这样的优化,笔者发现,无论是大数据量的情况下还是小数据量的情况下,分页速度一般都是几十毫秒,甚至0毫秒。而用日期段缩小范围的查询速度比原来也没有任何迟钝。

    聚集索引是如此的重要和珍贵,所以笔者总结了一下,一定要将聚集索引建立在:

    1、您最频繁使用的、用以缩小查询范围的字段上;

    2、您最频繁使用的、需要排序的字段上。

    结束语:

    本篇文章汇集了笔者近段在使用数据库方面的心得,是在做“办公自动化”系统时实践经验的积累。希望这篇文章不仅能够给大家的工作带来一定的帮助,也希望能让大家能够体会到分析问题的方法;最重要的是,希望这篇文章能够抛砖引玉,掀起大家的学习和讨论的兴趣,以共同促进,共同为公安科技强警事业和金盾工程做出自己最大的努力。

    最后需要说明的是,在试验中,我发现用户在进行大数据量查询的时候,对数据库速度影响最大的不是内存大小,而是CPU。在我的P4 2.4机器上试验的时候,查看“资源管理器”,CPU经常出现持续到100%的现象,而内存用量却并没有改变或者说没有大的改变。即使在我们的HP ML 350 G3服务器上试验时,CPU峰值也能达到90%,一般持续在70%左右。

    本文的试验数据都是来自我们的HP ML 350服务器。服务器配置:双Inter Xeon 超线程 CPU 2.4G,内存1G,操作系统Windows Server 2003 Enterprise Edition,数据库SQL Server 2000 SP3。

    展开全文
  • 查询优化在关系数据库系统有着非常重要的地位 关系查询优化是影响RDBMS性能的关键因素 由于关系表达式的语义级别很高,使关系系统可以从关系表达式分析查询语义,提供了执行查询优化的可能性 查询优化的优点...

    查询优化

    在关系数据库系统中有着非常重要的地位
    关系查询优化是影响RDBMS性能的关键因素
    由于关系表达式的语义级别很高,使关系系统可以从关系表达式中分析查询语义,提供了执行查询优化的可能性

    查询优化的优点不仅在于用户不必考虑如何最好地表达查询以获得较好的效率,而且在于系统可以比用户程序的“优化”做得更好
    (1) 优化器可以从数据字典中获取许多统计信息,而用户程序则难以获得这些信息
    (2)如果数据库的物理统计信息改变了,系统可以自动对查询重新优化以选择相适应的执行计划。在非关系系统中必须重写程序,而重写程序在实际应用中往往是不太可能的。
    (3)优化器可以考虑数百种不同的执行计划,程序员一般只能考虑有限的几种可能性。
    (4)优化器中包括了很多复杂的优化技术,这些优化技术往往只有最好的程序员才能掌握。系统的自动优化相当于使得所有人都拥有这些优化技术

    RDBMS通过某种代价模型计算出各种查询执行策略的执行代价,然后选取代价最小的执行方案
    集中式数据库
    执行开销主要包括:
    磁盘存取块数(I/O代价)
    处理机时间(CPU代价)
    查询的内存开销
    I/O代价是最主要的
    分布式数据库
    总代价=I/O代价+CPU代价+内存代价+通信代价

    查询优化的总目标:
    选择有效的策略
    求得给定关系表达式的值
    使得查询代价最小(实际上是较小) 
    [例3] 求选修了2号课程的学生姓名。用SQL表达:
          SELECT  Student.Sname
           FROM  Student,SC
           WHERE  Student.Sno=SC.Sno AND                 SC.Cno=‘2’; 
    
    假定学生-课程数据库中有1000个学生记录,10000个选课记录
    其中选修2号课程的选课记录为50
    系统可以用多种等价的关系代数表达式来完成这一查询
    Q1=πSname(σStudent.Sno=SC.Sno∧Sc.Cno='2' (Student×SC))
    Q2=πSname(σSc.Cno='2' (Student     SC))
    Q3=πSname(Student      σSc.Cno='2'(SC))
    

    一、第一种情况
    Q1=πSname(σStudent.Sno=SC.Sno∧Sc.Cno=’2’ (Student×SC))
    1. 计算广义笛卡尔积
    把Student和SC的每个元组连接起来的做法:
    在内存中尽可能多地装入某个表(如Student表)的若干块,留出一块存放另一个表(如SC表)的元组。
    把SC中的每个元组和Student中每个元组连接,连接后的元组装满一块后就写到中间文件上
    从SC中读入一块和内存中的Student元组连接,直到SC表处理完。
    再读入若干块Student元组,读入一块SC元组
    重复上述处理过程,直到把Student表处理完
    2. 作选择操作
    依次读入连接后的元组,按照选择条件选取满足要求的记录
    假定内存处理时间忽略。读取中间文件花费的时间(同写中间文件一样)需5×104s
    满足条件的元组假设仅50个,均可放在内存
    3. 作投影操作
    把第2步的结果在Sname上作投影输出,得到最终结果
    第一种情况下执行查询的总时间≈105+2×5×104≈105s
    所有内存处理时间均忽略不计

    二、 第二种情况
    Q2=πSname(σSc.Cno=’2’ (Student SC))
    1. 计算自然连接
    执行自然连接,读取Student和SC表的策略不变,总的读取块数仍为2100块花费105 s
    自然连接的结果比第一种情况大大减少,为104个
    写出这些元组时间为104/10/20=50s,为第一种情况的千分之一
    2. 读取中间文件块,执行选择运算,花费时间也为50s。
    3. 把第2步结果投影输出。
    第二种情况总的执行时间≈105+50+50≈205s

    三、 第三种情况
    Q3=πSname(Student σSc.Cno=’2’(SC))
    1. 先对SC表作选择运算,只需读一遍SC表,存取100块花费时间为5s,因为满足条件的元组仅50个,不必使用中间文件。
    2. 读取Student表,把读入的Student元组和内存中的SC元组作连接。也只需读一遍Student表共100块,花费时间为5s。
    3. 把连接结果投影输出
    第三种情况总的执行时间≈5+5≈10s

    假如SC表的Cno字段上有索引
    第一步就不必读取所有的SC元组而只需读取Cno=‘2’的那些元组(50个)
    存取的索引块和SC中满足条件的数据块大约总共3~4块

    若Student表在Sno上也有索引
    第二步也不必读取所有的Student元组
    因为满足条件的SC记录仅50个,涉及最多50个Student记录
    读取Student表的块数也可大大减少

    总的存取时间将进一步减少到数秒

    把代数表达式Q1变换为Q2、 Q3,
    即有选择和连接操作时,先做选择操作,这样参加连接的元组就可以大大减少,这是代数优化
    在Q3中
    SC表的选择操作算法有全表扫描和索引扫描2种方法,经过初步估算,索引扫描方法较优
    对于Student和SC表的连接,利用Student表上的索引,采用index join代价也较小,这就是物理优化

    代数优化策略

    :通过对关系代数表达式的等价变换来提高查询效率

    关系代数表达式的等价:指用相同的关系代替两个表达式中相应的关系所得到的结果是相同的

    两个关系表达式E1和E2是等价的,可记为E1≡E2

    常用的等价变换规则:
    1.  连接、笛卡尔积交换律
       设E1和E2是关系代数表达式,F是连接运算的条件,则有
        E1  × E2≡E2  × E1
        E1      E2≡E2      E1
        E1      E2≡E2      E1
    2. 连接、笛卡尔积的结合律
       设E1,E2,E3是关系代数表达式,F1和F2是连接运算的条件,则有
        (E1  × E2) × E3≡E1 × (E2 × E3)
        (E1      E2)      E3≡E1      (E2      E3)
        (E1     E2)      E3≡E1     (E2      E3) 
    3. 投影的串接定律
                     (            (E))≡            (E)
        这里,E是关系代数表达式,Ai(i=12,…,n),Bj(j=12,…,m)是属性名且{A1,A2,…,An}构成{B1,B2,…,Bm}的子集。
    4. 选择的串接定律
               (     (E))≡           (E)
        这里,E是关系代数表达式,F1、F2是选择条件。
        选择的串接律说明选择条件可以合并。这样一次就可检查全部条件
    5. 选择与投影操作的交换律
        σF(          (E))≡            (σF(E))
        选择条件F只涉及属性A1,…,An。
        若F中有不属于A1,…,An的属性B1,…,Bm则有更一般的规则:
                    (σF(E))≡          (σF(                       (E)))
    
    6. 选择与笛卡尔积的交换律
        如果F中涉及的属性都是E1中的属性,则
             (E1×E2)≡     (E1)×E2
        如果F=F1∧F2,并且F1只涉及E1中的属性,F2只涉及E2中的属性,则由上面的等价变换规则146可推出:
             (E1×E2)≡     (E1)×     (E2)
        若F1只涉及E1中的属性,F2涉及E1和E2两者的属性,则仍有
            (E1×E2)≡      (     (E1)×E2)
        它使部分选择在笛卡尔积前先做。 
    
    7. 选择与并的分配律
        设E=E1∪E2,E1,E2有相同的属性名,则
        σF(E1∪E2)≡σF(E1)∪σF(E2)
    8. 选择与差运算的分配律
        若E1与E2有相同的属性名,则
        σF(E1-E2)≡σF(E1)-σF(E2)
    9. 选择对自然连接的分配律
        σF(E1    E2)≡σF(E1)      σF(E2)
        F只涉及E1与E2的公共属性 
    10. 投影与笛卡尔积的分配律
        设E1和E2是两个关系表达式,A1,…,An是E1的属性,B1,…,Bm是E2的属性,则
                            (E1×E2)≡            (E1)×            (E2)
    11. 投影与并的分配律
        设E1和E2有相同的属性名,则
                      (E1∪E2)≡            (E1)∪            (E2)
    

    查询树的启发式优化

    典型的启发式规则:
    1. 选择运算应尽可能先做。在优化策略中这是最重要、最基本的一条
    2. 把投影运算和选择运算同时进行(pipelining技术)
    如有若干投影和选择运算,并且它们都对同一个关系操作,则可以在扫描此关系的同时完成所有的这些运算以避免重复扫描关系,也避免存储中间关系
    3. 把投影同其前或其后的双目运算结合起来执行(pipelining技术)
    4. 把某些选择同在它前面要执行的笛卡尔积结合起来成为一个连接运算
    5. 找出公共子表达式
    如果这种重复出现的子表达式的结果不是很大的关系并且从外存中读入这个关系比计算该子表达式的时间少得多,则先计算一次公共子表达式并把结果写入中间文件是合算的
    当查询的是视图时,定义视图的表达式就是公共子表达式的情况
    遵循这些启发式规则,应用9.3.1的等价变换公式来优化关系表达式的算法。
    算法:关系表达式的优化
    输入:一个关系表达式的查询树
    输出:优化的查询树
    方法:
    (1) 利用等价变换规则4把形如σF1∧F2∧…∧Fn(E)变换为σF1(σF2(…(σFn(E))…))。
    (2) 对每一个选择,利用等价变换规则4~9尽可能把它移到树的叶端。
    (3) 对每一个投影利用等价变换规则3,5,10,11中的一般形式尽可能把它移向树的叶端。
    注意:
    等价变换规则3使一些投影消失
    规则5把一个投影分裂为两个,其中一个有可能被移向树的叶端
    (4) 利用等价变换规则3~5把选择和投影的串接合并成单个选择、单个投影或一个选择后跟一个投影。使多个选择或投影能同时执行,或在一次扫描中全部完成
    (5) 把上述得到的语法树的内节点分组。每一双目运算(×, ,∪,-)和它所有的直接祖先为一组(这些直接祖先是(σ,π运算)。
    如果其后代直到叶子全是单目运算,则也将它们并入该组
    但当双目运算是笛卡尔积(×),而且后面不是与它组成等值连接的选择时,则不能把选择与这个双目运算组成同一组,把这些单目运算单独分为一组

    例[5] 查询语句:检索学习课程名为MATH的女学生学号和姓名。
    该查询语句的关系代数表达式如下:
       πS#,SNAME(σCNAME=’MATH’∧SEX=’F’(C   SC   S))
    上式中, 符号用π、σ、×操作表示,可得下式
     πS#,SNAME(σCNAME=’MATH’∧SEX=’F’(πL
              (σC.C# = SC.C#∧SC.S# = S.S#(C×SC×S))))
    此处L是C、SC、S中全部属性,去除重复属性。
    
    展开全文
  • 在进行这两项工作的过程,第一项工作对第二项起着非常重要的作用,我们只有真正的搞清楚了业务需求以及业务逻辑,找到了功能模块之间在后台数据库关联的抽象模型,这样才能确定数据库应该有几张表,每张表有哪些...

    功能需求分析和数据库设计

    不论是Web开发还是Android开发,在设计后台的时候我们都要做的重要的事情不外乎两点:1. 需求分析;2.数据库表格的设计。在进行这两项工作的过程中,第一项工作对第二项起着非常重要的作用,我们只有真正的搞清楚了业务需求以及业务逻辑,找到了功能模块之间在后台数据库关联的抽象模型,这样才能确定数据库应该有几张表,每张表有哪些字段,表与表之间该如何联系。

    需求分析与功能模块设计

    一、 接到一个项目之后,一般情况下都会有相应的需求说明,首先我们得到的信息是要做一个什么性质的网站或者是App,在听完客户的相关需求之后,我们要做的就是将具体的业务如何体现在模块开发中,在整个模块的设计过程中大体是这样的几个步骤:1. 熟悉客户需求,并向客户咨询了解相关的模块信息要求;2. 根据用户提出的需求进行模块设计,并且确定各个模块的数据来源以及二级页面跳转需要传递的参数。3.明确前台控件对应的响应时间,针对不同的操作和不同的数据库表格进行联系。
    二、 根据需求分析进行数据库表格的设计,在设计数据库表格的过程中有这样两种不同类型的表格:1.权限管理的表格,这种表格的字段在设计的时候重点突出的是权限,不同的权限对应的字段设置不同的状态,也就是数据库字段对应的值。2.长文本类型的数据库,这类数据库一般指的是用户详情,或者是具体的详细的文本类型的数据。
    三、权衡表格数量,根据最优化原则,综合考虑,在设计数据库表格的过程中一定要想到的是后台编程对应的代码设计,好的数据库表格设计会给后台编写代码提供极大的便利,所以在设计数据库表格的过程中,我们必须将后台高效编码作为数据库设计的考虑因素之一。
    四、 明确数据库在整个项目中扮演的角色,在项目的整个开发过程中我们首先要明确的就是数据库是一个什么样的角色,在这里我想借助具有视频播放功能的网站来阐述,我们设计的数据库主要完成的是包含业务逻辑的数据展示和操作(关系型数据),表与表之间通过主外键是有关联的。而在视频播放网站的所谓的视频资源这样的数据则完全可以是另外的一个服务器数据存储系统。虽然都可称之为持久层但是却又各自不同的特点。

    数据库表格的划分和设计原则

    一、不要想着将所有的字段放在一张表中,在整个后台数据库表格的设计过程中,我们要明确的一点就是表格要有分工明确,逻辑清晰高效这样的特点。同时也不是表格越多越好,我们要做的是在到达分工明确简化明了这一要求的基础之上使我们的表格数量最小化。
    二、字段的设计,在确定数据库表格字段的时候我们一样要本着一个原则那就是归类原则,如果是富文本数据我们可以将之放在一个表中专门存储富文本数据,如果是权限管理或者是父子类标签数据我们可以单独成表,后续通过关联拿到相关的数据,总之要让自己的字段分门别类,前期设计划分的越明确后续项目维护就会越高效。
    三、在理解这一块内容的时候要时刻体现一个原则那就是“关系型”我们设计的数据库不是一个网盘文件,用于简单的存储数据,而是有逻辑有关系在里边的,对于用户型的应用,每个用户都拥有属于他自己特有的数据,为何数据是独有的就是因为相关表的数据和当前用户的ID是关联的是存在一一对应关系的,这里的用户ID就是一个关键,因为他是数据特有性实现的根本原因。

    总结:

    在项目的整个开发过程中,我们最好是通过实战去检验自己的每一个想法,面对任何的问题尤其是在编程中遇到的问题,实际操作才是根本。数据库设计也好,模块划分也好,只要你真正的去想去琢磨去设计,就一定能够分析出结果,设计出雏形,透过现象看本质,通过前台操作数据展示的流程我们就可以找到表格设计和管理的信息。

    --------------------- 本文来自 BlackFox丶 的CSDN 博客 ,全文地址请点击:https://blog.csdn.net/qq_37979178/article/details/78004034?utm_source=copy

    展开全文
  • 关系数据库设计:谈谈规范化技术

    千次阅读 多人点赞 2020-08-19 21:42:31
    通过实际案例介绍关系数据库设计的规范化技术(Normalization),为什么需要规范化,常见的第一范式、第二范式和第三范式,反规范化应用的场景以及外键的取舍问题。
  • 关系数据库设计

    千次阅读 2009-02-10 10:38:00
    关系数据库中,这种规则就是范式。范式是符合某一种级别的关系模式的集合。关系数据库中的关系必须满足一定的要求,即满足不同的范式。目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3...
  • 关系数据库基础

    千次阅读 2016-11-26 15:38:58
    数据库是按照数据结构来组织、存储和管理数据的仓库(图书馆),数据库技术产生于20世纪60年代末70年代初,其发展阶段为:人工管理阶段,文件系统阶段,数据库系统阶段。 人工管理阶段 20世纪50年代中期之前,计算机...
  • 关系数据库的查询优化

    千次阅读 2018-07-17 16:29:43
    关系查询优化是影响关系数据库管理系统性能的关键因素。 一、查询优化概述 查询优化的优点不仅在于用户不必考虑如何最好地表达查询以获得较高的效率,而且在于系统可以比用户程序的“优化”做得更好。 1. 优化...
  •  在任何一个关系数据库中,第一范式(1NF)是对关系模式的基本要求,不满足第一范式(1NF)的数据库就不是关系数据库。  所谓第一范式(1NF)是数据库表的每一列都是不可分割的基本数据项,同一列不能有多个...
  • 1.数据库设计14规则 1. 原始单据与实体之间的关系   可以是一对一、一对多、多对多的关系。在一般情况下,它们是一对一的关系:即一张原始单据对应且只对应一个实体。  在特殊情况下,它们可能是一对多或多对...
  • 关系数据库选型

    千次阅读 2018-07-03 23:15:44
    选择一款合适的SQL数据库是一项艰巨的任务,因为可选的产品很多。这既有好的一面也有不利的一面,选项增加意味着做出错误选择的概率也在增加。为此,需独具慧眼,谨慎而全面地对比每家厂商技术的优缺点,通过衡量...
  • 数据库判断关系是第几范式

    万次阅读 多人点赞 2020-05-30 16:08:38
    关系数据库中,这种规则就是范式。关系数据库中的关系必须满足一定的要求,即满足不同的范式。目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、第四范式(4NF)、第五范式(5NF)...
  • 关系数据库 入门简介

    千次阅读 2019-07-01 16:18:09
    关系数据库也叫Nosql数据库,全称是not noly sql非关系型...使用这种方式,用户可以根据需要去添加自己需要的字段,这样,为了获取用户的不同信息,不需要像关系数据库中,要对多表进行关联查询。仅需要根据i...
  • 文档数据库与关系数据库的比较

    千次阅读 2006-10-19 13:46:00
    随着应用领域的不断拓展和多媒体技术, 人们发现关系数据库的许多限制和不足,因而数据库技术进入了"后关系数据库时代"。文档数据库由此应运而生。本文概要地从数据格式、数据库结构和WEB发布数据三个方面比较了文档...
  • 关系数据库标准语言——SQL

    千次阅读 2019-07-08 08:18:00
    关系数据库标准语言——SQL 1.SQL的基本概念 1.基本表 ​ 一个关系对应一个基本表。基本表是独立存在的表,不是由其他表导出的。一个,或者多个机泵表对应一个存储文件。 2.视图 ​ 视图是从一个或者几个基本表导出...
  • 实时/历史数据库关系数据库的区别 实时数据库   实时数据库数据库系统发展的一个分支,它适用于处理不断更新的快速变化的数据及具有时间限制的事务处理。实时数据库技术是实时系统和数据库技术相结合的...
  • 关系数据库系统的查询处理 一、关系数据库系统的查询处理 1.查询处理步骤 关系数据库管理系统查询处理阶段 : 1)查询分析 :对查询语句进行扫描、词法分 析和语法分析 词法分析:从查询语句识别出正确的语言符号...
  • 在传统的数据库中,信息被分割成离散的数据段,而在文件数据库中,文件是处理信息的基本单位。一文件能非常长、非常复杂、能无结构,和字处理文件类似。 文件数据库和五、六十年代管理数据的文件系统不同,文件数据库...
  • 数据库:怎样判断关系是第几范式

    万次阅读 多人点赞 2018-03-05 16:06:20
    设计范式(范式,数据库设计范式,数据库的设计范式)是符合某一种级别的关系...在关系数据库中,这种规则就是范式。关系数据库中的关系必须满足一定的要求,即满足不同的范式。目前关系数据库有六种范式:第一范式(1
  •  在任何一个关系数据库中,第一范式(1NF)是对关系模式的基本要求,不满足第一范式(1NF)的数据库就不是关系数据库。  所谓第一范式(1NF)是数据库表的每一列都是不可分割的基本数据项,同一列不能有多个值...
  • 如何使用ERD设计关系数据库

    千次阅读 2019-04-03 17:18:02
    数据库在我们的日常生活变得越来越不可或缺。我们每天和每个地方处理数据 - 手机联系人,医疗...多年来,出现了许多数据库类型,例如分层数据库,关系数据库,对象数据库,XML数据库等。它们的硬件要求,效率以...
  • 数据依赖:在计算机科学,数据依赖是一种状态,当程序结构导致数据引用之前处理过的数据时的状态。其中最重要的是函数依赖和多值依赖。 函数依赖 理解方式1:设X,Y是关系R的两个属性集合,当任何时刻R的任.....
  • 数据库

    千次阅读 2017-03-25 18:08:20
    关系完整性是为保证数据库中数据的正确性和相容性,对关系模型提出的某种约束条件或规则。完整性包括: 1、域完整性: 域完整性是保证数据库字段取值的合理性。包括限制类型(数据类型),格式(通过检查约束和规则),...
  • 关系数据库由由埃德加·科德(IBM)在1969年左右提出。自推出后就成为商业应用的主要数据库模型(与其他数据库模型,如分级、网络或对象模型相比)。如今已有许多商业关系数据库管理系统(RDBMS),如Oracle,IBM ...
  • 关系数据库中,一张表的每一行数据被称为一条记录。一条记录就是由多个字段组成的。例如,students表的两行记录: id class_id name gender score 1 1 小明 M 90 2 1 小红 ...
  • 关系数据库设计规范化流程

    千次阅读 2011-09-15 14:59:42
    数据库表结构的设计关系到:数据库的存储效率、数据完整性、可扩展性及冗余数据。   规范化:确保数据正确地分布到数据库的表,防止操作异常及大量冗余信息的存储。数据冗余不仅占用物理空间,对数据的维护和...
  • 数据库关系模式的规范化

    千次阅读 2021-04-03 15:23:11
    在任何一个关系数据库中,第一范式(1NF)是对关系模式的基本要求,不满足第一范式(1NF)的数据库就不是关系数据库。 所谓第一范式(1NF)是数据库表的每一列都是不可分割的基本数据项,同一列不能有多个值,即...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 45,866
精华内容 18,346
关键字:

关系数据库中的关键字段是指