Win9x平台上SQL Server 2000的性能和局限

很多企业还在各种场合下使用各种版本的Windows 9x，因此，要在这些环境下使用SQL Server 2000，我们必须首先了解Windows 9x的性能和局限。
客户端软件

SQL Server 2000客户端软件是企业版、标准版和专业版都附带的。你可以仅使用SQL Server 2000安装盘里的客户端工具将客户端软件安装到客户机，也可以使用联通性选项（包含在SQL Server客户端访问许可证中）。这个软件的作用是管理SQL Server并可以在SQL数据库中进行ad hoc查询。
这个软件有一些局限。Windows 98和 Windows 95并不提供浏览器支持，这意味着SQL Server对话框不能显示服务器的列表。因此，当你使用注册服务器，注册服务器向导以及查询分析器登陆的对话框的时候，你需要手工输入正确的服务器名。
同样地，企业管理器和服务器代理这样的SQL Server工具必须由用户设置检测服务状态间隔。
服务器端软件
所有的Win9x 操作系统均不能为强化的SQL Server 2000系统提供高效的环境，因为公司级别应用程序的特性在这里是不可用的。因此，你不能在Win9x 系统上使用企业版的SQL Server 2000，不过你仍然可以使用个人版或是桌面引擎版。
SQL Server 2000个人版和桌面引擎比较适合小规模的项目，这些项目需要单独安装作为安全保障(例如，没有足够资金，仅使用win98的研究机构)。
SQL Server 2000桌面引擎是可以重分发版本的关系型数据库引擎，它不需要额外的许可证。然而，桌面引擎还是有一些严重的局限，主要包括以下几点：
它不能自动启动
它没有事件日志
SQL Server性能监视器不可用
它并不包含任何的SQL Server命令，也没有图形用户界面
它不支持named pipes、Banyan VINES servers或是AppleTalk Net-Libraries
它不支持Windows NT集成身份认证
使用多协议加密的Win98客户端不能连接到SQL Server
它不支持异步I/O，因此它不能使用某些I/O优化

问：我发现sysindexes索引表中的很多条目并不是我自己创建的。听说它们并不是真正的索引，而是SQL Server查询优化器自动创建的统计。怎样才能识别哪些是真正的索引，哪些是SQL Server自动创建的统计呢？
答：按照默认设置，如果表中的某列没有索引，则SQL Server会自动为该列创建统计。然后，查询优化器评估该列中数据分布范围的统计信息，以选择一个更为有效的查询处理方案。分辨自动创建的统计很简单，在SQL Server 7.0和SQL Server 2000中，自动创建的统计的前缀为_WA_Sys。
您还可以使用INDEXPROPERTY()函数的IsAutoStatistics属性来区分一个索引是真正的还是自动创建的统计，让SQL Server优化器选择需要创建的统计。您还可以为您管理的数据库启用“自动创建统计表”选项。
很多人忽略了下面的明显的结论。自动创建统计的存在意味着某个真正的索引可能会从中受益。请考虑下列代码的输出：
USE tempdb
GO
IF OBJECTPROPERTY(OBJECT_ID('dbo.orders'), 'IsUserTable')=1
DROP TABLE dbo.orders
GO
SELECT * INTO tempdb..orders FROM northwind..orders
GO
SELECT * FROM tempdb..orders WHERE orderid = 10248
GO
SELECT * FROM tempdb..sysindexes WHERE id = object_id('orders')
AND name LIKE
'_wa_sys%'
GO
该代码在tempdb中复制Northwind Orders表，选择一行，然后检查SQL Server是否添加了一个统计。很显然，该表没有OrderId列的索引，所以SQL Server自动创建了名为_WA_Sys_OrderID_58D1301D 的统计。OrderId列统计表的存在表明Northwind Orders表将得益于附加的索引。
以下查询显示了为数据库中每个用户表自动创建的统计的数量，该数据库至少有一个自动创建的统计。
SELECT
object_name(id) TableName
,count(*) NumberOfAutoStats
FROM
sysindexes
WHERE
OBJECTPROPERTY(id, N'IsUserTable') = 1
AND INDEXPROPERTY ( id , name , 'IsAutoStatistics' ) = 1
GROUP BY
object_name(id)
ORDER BY
count(*) DESC
并不是所有的统计都可被真正的索引所替代。在某些情况下，SQL Server会为一个表自动创建超过50个统计。很明显，这些表的索引策略很差劲。对表及自动创建的与之相关联的统计的快速记数可以帮助您确定哪些表需要索引。
—Microsoft SQL Server开发团队

/*--------------------------------------------------
/*作者：翁 彦 enhydraboy@yahoo.com.cn
/*--------------------------------------------------
这是一个在我实际一个项目中遇到的问题。03BHL01001（上海）和03BHL01001(上海)比较的结果是一样的。导致引起的重复的主键问题。
03BHL01001（上海）和03BHL01001(上海)差别，就在于前者的括号是全角的括号字符，后者是半角的括号字符。全角的括号字符和半角的括号字符的ascii码显然是不一样的。全角的（ ASCII码是0xA3A8 ，而半角的( 是0x28。那么为什么SQL Server会认为是一样的呢？
问题其实就出在数据库的排序规则上，让我们在仔细研读一下SQL Server的文档。SQL Server的排序规则由这样几部分组成，代码页、区分大小写、区分重音、区分宽度。最后一个在SQL Server的联机帮助中没有进一步提及，其实本篇遇到的问题就是由于这个原因造成的。区分宽度：指定 SQL Server 区分相同字符的单字节表示法（半角）和双字节表示法（全角）。如果没有选择，则 SQL Server 将认为相同字符的单字节表示法和双字节表示法等效。
缺省，安装SQL Server中文版的时候，SQL Server帮你选择的排序规则是Chinese_PRC_CI_AS(Chinese-PRC, case-insensitive, accent-sensitive, kanatype-insensitive, width-insensitive),是中文，不区分大小写、区分重音、不区分假名、不区分宽度。因此，自然就认同03BHL01001（上海）=03BHL01001(上海)。
所以，正确的选择应该是，后缀为WS的中文排序规则。本例中我们应该选择Chinese_PRC_CI_AS_WS。
我们来看一下，指定排序规则是Chinese_PRC_CI_AS_WS后，怎么样了？

select 1 where '03BHL01001（上海）'='03BHL01001(上海)'
collate Chinese_PRC_CI_AS_WS
（所影响的行数为 0 行）

看来这个问题解决了。
重要提示：
如何察看使用那个排序规则呢？可以使用下面的SQL语句。
SELECT *
FROM ::fn_helpcollations()
可以查询所有排序规则的信息。
查出所有中文排序规则的信息
SELECT * FROM
(
SELECT *
FROM ::fn_helpcollations()) A
WHERE name like 'Chinese%'

问：怎样使用Transact-SQL以编程的方式确定我的SQL Server计算机有多少个处理器？
答：以下语句将返回您需要的信息：

EXEC master..xp_msver N'ProcessorCount',
N'ProcessorType'

但是，我热衷于教给人们捕鱼的方法，而不是给他们一盘现成的冻鱼条，所以我不满足于简单的答案。最近一个同事问我这个问题，我一时想不起来适当的命令，但我知道SQL Server企业管理器在SQL Server属性对话框的处理器选项卡中显示计算机的处理器数量。并且，通过在服务器上运行简单的Transact-SQL语句，企业管理器几乎可以得到所有需要的信息。此外，运行SQL事件探查器还可以快速查看企业管理器生成的语句。
我常常会细数使用SQL事件探查器和观察SQL Server运行情况所带来的好处，以下是将这一建议付诸实现的另一个例子。借助SQL事件探查器，我只花费三分钟即将企业管理器对xp_msver扩展存储过程的调用的分离出来。在这种时候，我总是会先想到SQL事件探查器。

问：为了从查询中返回指定数量的行，使用 TOPN 子句比使用SET ROWCOUNTN 语句要快吗？
答：在正确进行了索引的情况下，TOP N 子句和SET ROWCOUNT N 语句是一样快的，但是如果数据未经过排序，TOP N 要快一些。在输入未排序的情况下，TOP N 操作时使用一个经过排序的小的中间临时表，而且操作时仅仅替换该表的最后一行。如果输入是近似排序的，TOP N 引擎必须删除或插入最后行，但只需几次操作即可。近似排序意味着您正在处理的堆集在初始构建时可进行有序的插入操作，并且不需要进行很多的更新、删除、向前移动指针等操作。
　
排序一个近似排序的堆集比排序一个巨大的表要更有效率。在一次测试中，使用TOP N 来对一个由无序插入操作构建的并且含有同样的行数的表进行排序，发现TOP N 的效率也不高。通常，在进行过索引和未进行过索引的情况下，I/O时间都是一样的；但是如果没有进行过索引，SQL Server 必须要进行一次全表扫描。处理器时间和实耗时间说明近似排序的堆集要更有效率一些。但I/O时间是相同的，因为不管怎样SQL Server都要读取所有的行。