SQL Server的空值处理策略

数据完整性是任何数据库系统要保证的重点。不管系统计划得有多好，空数据值的问题总是存在。本文探讨了在SQL Server中处理这些值时涉及的3个问题：计数、使用空表值以及外键处理。

用COUNT(*)处理空值

在数据库应用的设计中，我们往往会需要获取某些表的记录总数，用于判断表的记录总数是否过大，是否需要备份数据等。我们通常的做法是：select count(*) as c from tableA 。然而对于记录数巨大的表，上述做法将会非常耗时。在DELL 4400 服务器上做试验，MS Sqlserver 2000 数据库对于100万记录的简单数据表执行上述语句，时间在1分钟以上。如果在表的某个字段上做聚簇索引，第一次执行该语句的时间和没有索引的时间差不多，之后执行上述语句，速度很快，在1秒中以内，但当表的记录数发生较大变化后，再执行该语句又会经历一次耗时的过程。而且不是每个表都适合做聚簇索引的，对于数量巨大的表，如果需要经常增删操作，建聚簇索引是一个很不明智的做法，将会极大的影响增删的速度。那么有没有一个比较简单的方法快速获取表的记录总数呢？答案是有的。
在MS SQL 数据库中每个表都在sysindexes 系统表中拥有至少一条记录，该记录中的rows 字段会定时记录表的记录总数。下面是sysindexes 表的相关记录的含义：
列名 数据类型 描述
id int 表ID(如果 indid = 0 或255)。否则为索引所属表的ID
Indid smallint 索引ID：
0＝表
1＝聚簇索引
>1＝非聚簇索引
255＝具有text或image数据的表条目。
rows int 基于indid=0 和 indid=1地数据级行数，该值对于indid>1重 复。如果indid=255，rows设置为0。


当表没有聚簇索引时，Indid = 0 否则为 1。
那么现在大家应该知道如何获取表的记录总数了，只需执行如下语句：
select rows from sysindexes where id = object_id(tablename) and indid in (0,1)
该方法获取表的记录总数的速度非常快，在毫秒级就可以完成，相比select count(*) 要快上数万倍，但是大家在运用该方法是一定要主要，该方法得到的表的总记录数不是一个精确值，原因是MS SQL 并不是实时更新该字段的值，而是定时更新，当从实践来看该值和精确值一般误差不大，如果你希望快速的粗略估算表的大小，建议你采用该方法。如果你希望得到精确值，那么请在执行上述语句前执行DBCC UPDATEUSAGE(DatabaseName,[TABLENAME]) WITH ROW_COUNTS 强制更新该字段的值，但这样第一次更新时会耗费大量的时间，这样做的效果和建有聚簇索引的表 select count (*) 效果相差不大，所以如果你希望相对快速地得到精确的表的记录总数，那么你有两种选择，建聚簇索引或者先DBCC 再使用上述方法。

4.1是一个阿尔法测试版，此版本没有制作为傻瓜安装程序或许多有不便。不过，我自己颇为喜欢
压缩包形势的分发 :) 以下是我全新安装以及升级一个3.23.49的步骤。
一 全新安装
用WinRAR解压缩文件到C:mysql目录（默认目录，省心！！），在命令行下执行
c:mysqlinmysqld-??? --install
net start mysql
即可,非常简便,如果你装在其他的目录中,记得按照以前说的修改配置文件中的路径!
二 升级安装
无论是从3.23.x升级还是从4.0.x升级都是没大差别！
首先还是要备份老数据库，给自己准备一个后悔药以防万一！！
接着停止当前的mysql数据库并从服务中将其移除，如果WinMySQLAdmin还运行着的话一定要关闭！
除了data目录之外，全部用4.1版的文件覆盖老版文件！
从命令行下以 c:mysqlinmysqld-opt --skip-grant-tables 启动mysql，紧接着再执行
c:mysqlinmysql < c:mysqlscriptsmysql_fix_privilege_tables.sql 建立新版授
权表。
以上步骤如果无错，停止掉mysql c:mysqlinmysqladmin -u root shutdown 。
然后根据个人需要重新安装成系统服务！
这个版本的头文件我看了一下，觉得挺晕的，有兴趣的自己去看看！

作者：王猛 (HeartIcy@163.com)
丢了密码是非常痛心的事情，尤其是root密码丢了:( 。自己装装
玩的丢了也就丢了，但是万一是生产服务器挂了麻烦可就大了！
现在假设是由于被入侵造成的root密码丢失。这里我谈一下我自己
对这样一个问题的看法。
首先遇到这种问题我们没有必要慌张，整个恢复过程也是很简单的。
1 下载MySQL源码分发包，不用区分操作系统，我们需要的东西是一
样的。
2 重命名自己的mysql的data目录下的mysql文件夹为oldmysql。
3 将源码包中data目录下的mysql目录复制到你的mysql的data目录
下。
4 重新启动mysql，现在mysql的授权关系同全新安装的一样，空密
码登陆，然后自行调整授权。
5 打开oldmysql这个库检查到底出现了什么问题。
6 如果有备份对系统中原有的数据库进行完整性检测，以免被人修
改。
通过上述6个步骤已经可以完全恢复你对mysql的控制，重点就是最
后两步检查对方对改了那些权限，以及数据的完整性检测。

SQL Server中有几个可以让你检测、调整和优化SQL Server性能的工具。在本文中，我将说明如何用SQL Server的工具来优化数据库索引的使用，本文还涉及到有关索引的一般性知识。
关于索引的常识

影响到数据库性能的最大因素就是索引。由于该问题的复杂性，我只可能简单的谈谈这个问题，不过关于这方面的问题，目前有好几本不错的书籍可供你参阅。我在这里只讨论两种SQL Server索引，即clustered索引和nonclustered索引。当考察建立什么类型的索引时，你应当考虑数据类型和保存这些数据的column。同样，你也必须考虑数据库可能用到的查询类型以及使用的最为频繁的查询类型。
索引的类型
如果column保存了高度相关的数据，并且常常被顺序访问时，最好使用clustered索引，这是因为如果使用clustered索引，SQL Server会在物理上按升序（默认）或者降序重排数据列，这样就可以迅速的找到被查询的数据。同样，在搜寻控制在一定范围内的情况下，对这些column也最好使用clustered索引。这是因为由于物理上重排数据，每个表格上只有一个clustered索引。
与上面情况相反，如果columns包含的数据相关性较差，你可以使用nonculstered索引。你可以在一个表格中使用高达249个nonclustered索引——尽管我想象不出实际应用场合会用的上这么多索引。
当表格使用主关键字（primary keys），默认情况下SQL Server会自动对包含该关键字的column(s)建立一个独有的cluster索引。很显然，对这些column(s)建立独有索引意味着主关键字的唯一性。当建立外关键字（foreign key）关系时，如果你打算频繁使用它，那么在外关键字cloumn上建立nonclustered索引不失为一个好的方法。如果表格有clustered索引，那么它用一个链表来维护数据页之间的关系。相反，如果表格没有clustered索引，SQL Server将在一个堆栈中保存数据页。
数据页
当索引建立起来的时候，SQLServer就建立数据页（datapage），数据页是用以加速搜索的指针。当索引建立起来的时候，其对应的填充因子也即被设置。设置填充因子的目的是为了指示该索引中数据页的百分比。随着时间的推移，数据库的更新会消耗掉已有的空闲空间，这就会导致页被拆分。页拆分的后果是降低了索引的性能，因而使用该索引的查询会导致数据存储的支离破碎。当建立一个索引时，该索引的填充因子即被设置好了，因此填充因子不能动态维护。
为了更新数据页中的填充因子，我们可以停止旧有索引并重建索引，并重新设置填充因子（注意：这将影响到当前数据库的运行，在重要场合请谨慎使用）。DBCC INDEXDEFRAG和DBCC DBREINDEX是清除clustered和nonculstered索引碎片的两个命令。INDEXDEFRAG是一种在线操作（也就是说，它不会阻塞其它表格动作，如查询），而DBREINDEX则在物理上重建索引。在绝大多数情况下，重建索引可以更好的消除碎片，但是这个优点是以阻塞当前发生在该索引所在表格上其它动作为代价换取来得。当出现较大的碎片索引时，INDEXDEFRAG会花上一段比较长的时间，这是因为该命令的运行是基于小的交互块（transactional block）。