关闭

对数据库模型进行性能优化

425人阅读 评论(0) 收藏 举报

在一个数据库应用程序中,程序是从一个健全的数据库模型开始的。明白了这一点后,我们来看几种可以优化数据库模型的方法,通过这些方法可以提高查询效率。
(1) 少许的逆规范化(denormalization)大有帮助。尽量避免这样的数据库模型:它有一个名为Gender的表,表中有3个值。如果你有一个1:1关系的表,而且它经常被它的父表访问,那么你可以考虑合并这两张表。
(2) 让应用程序多承担一些责任。如果可以通过应用程序更容易地析取数据,为什么还要生成视图来强制数据以某种确定方式出现呢?
(3) 对数据进行水平分割。如果你有一个表示Web站点点击率的表,则可考虑把它按月份划分为12个表。如果数据是分布式的,那么你的负荷就变成了原有的1/12。这也可以让你把一些数据放在各个独立的服务器上,然后使用分布的划分视图来更新和查看数据。这样做使你可以对当前月份使用更加积极的索引策略,并且对已经过去的月份使用更高的填充度。
(4) 在行中保持尽可能少的内容。换句话说,不要使用一个char(255)类型来存储一个用户名的值,这只会造成空间的浪费。
(5) 为了不破坏引用的完整性,要避免使用触发器。使用外键约束要快得多,并且这种约束更适合处理大多数的操作。
(6) 避免使用text类型的字段。尝试找出对字段的确切要求是什么。如果你准备最多插入2000个字符,那么使用varchar(2000)会更加有效。
(7) 除非你要使用多种语言,否则不要使用像nvarchar和ntext这样的Unicode数据类型。然而要牢记,当你使用DTS从另一个数据源(如Access)转换数据的时候,DTS经常在服务器上创建Unicode的列。如果你的公司打算使用多语言,那么你就会需要这些数据类型。
(8) 避免在标识列上创建聚集索引。聚集索引对于范围查询执行起来更好,如一个日期。如果在标识列上存在聚集索引,你的数据就有收到“热点”的风险。注:“热点”是由于很多人更新同一数据页所引起的。
(9) 可能的话,就不允许列为NULLS。如果你知道你总是会得到地址信息的话,那么你就不需要为空的列。处理NULLS会增加额外的开销。
(10) 在某些情况下,如果表中存在惟一的数据列,那么要避免使用标识列。例如,如果用户名的值是惟一的,就不要另外创建没有必要的键。这样可以防止从子表中创建不必要的连接来确定用户名。这可能会占用一些存储空间,但可以给你节省大量的查询时间。要灵活处理这种实际情况,但如果行中已经存在惟一的值,那么为什么还要人工去给它分配一个呢? 


 
0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:69538次
    • 积分:1078
    • 等级:
    • 排名:千里之外
    • 原创:26篇
    • 转载:21篇
    • 译文:0篇
    • 评论:8条
    文章分类
    最新评论