高效SQL查询之索引（III）
先说说这些误区。所谓“误区”，有一些是新手很容易犯的错误或者很容易忽略的问题，另外一些，则是像“耗子吃了盐会变成蝙蝠”一样，让我们从小就认为是正确的事情。如下：
1、 表上不管用得着用不着，都加个聚集索引。
我们知道，表以两种方式组织物理存储：有聚集索引的“聚集表”；没有聚集索引的“堆”。在聚集表中，数据行按照聚集索引的顺序存储（这也是为啥一张表最多只能有一个聚集索引的原因）；堆中，数据行的存储可以认为是不确定的。
在偶《写有效率的 SQL 查询（ II ）》中曾经介绍过 DB 引擎如何在聚集表中通过非聚集索引查找目标数据：从非聚集索引树根开始 seek ，查找到目标索引行，然后通过索引行上存储的聚集索引键值，爬聚集索引树，并最终通过聚集索引行上的指针拿到目标数据。
但是堆上的非聚集索引存储的不是聚集索引键值，它存储的是指向目标行的指针。也就是说，如果在同样的表是堆，通过非聚集索引 seek 数据将省掉爬聚集索引树的损耗，而可以直接通过非聚集索引行上的行指针直接拿到目标数据。也就是说，在某些情况下，使用堆可以提高系统效率。
这个“某些情况”，就是你的需求，你的系统行为。一般情况下，所有人对要在什么样的字段上创建聚集索引都非常了解；但是不是所有的人都对应该在什么样的系统行为下，不创建聚集索引了解。假设你的表中有字段 col1, col2,col3,col4 等等， col1 、 col2 的分布密度很低。你观察了系统行为，发现一半的查询是 XXXX where col1 = YYYY ，另一半的查询是 XXXX where col2 = YYYY 。这种情况下，使用堆就是更好的选择。
2、 primary key 就是聚集索引。
primary key 上是得有索引，但是这个索引可不见得一定得是聚集索引。尽管语句
create table testPK
(
id int identity ( 1, 1) primary key ,
fname varchar ( 64)
)
会在 id 列上创建聚集索引。当然，一般主键都是聚集索引，但也仅仅是“一般”而已。个人感觉，聚集索引的唯一目标就是数据检索，它应该建在什么字段上，完全由系统行为决定。“一般主键都是聚集索引”也仅仅是因为多数情况下， primary key 字段上建所有更有益于效率而已。
create table testPK
(
相关文档：
方法(1)
SELECT stuff((select ','+ltrim(ColumnName) from #A for xml path('')
),1,1,'')
/*
102,103,104,105
*/
方法(2)
DECLARE @s NVARCHAR(1000)='';
SELECT @s+=ColumnName+',' from #A;
SELECT @s; ......
针对 SQL Server 内正在执行的每个请求返回一行。sys.dm_exec_connections
、sys.dm_exec_sessions
和sys.dm_exec_requests
服务器范围动态管理视图映射到 sys.sysprocesses
系统视图（先前为系统表）。
注意：
若要执行在 SQL Server 以外的代码（例如，扩展存储过程和分 ......
1. 查看数据库的版本
select @@version
2.查看数据库所在机器操作系统参数
exec master..xp_msver
3. 查看数据库启动的参数
sp_configure
4.查看数据库启动时间
select convert(varchar(30),login_time,120) from master..sysprocesses where spid=1
查看数据库服务器名和实例名
print ''Server Name.... ......
下面提出了10条和DB2 SQL性能相关的10条因素：
1、提供适当的统计信息
对DB2优化管理器（otimizer）而言，如何更加有效的执行SQL语句是由存在于DB2 catalog中的统计信息决定的，优化器利用这些信息决定最优化的路径。
因此，为了保持系统能够做出最佳选择，需要经常的运行Runstats命令，来保持系统统计信息的及时有效。� ......
