博客园-邀月工作室

《Microsoft Sql server 2008 Internal》读书笔记--第六章Indexes:Internals and Management(3)

邀月 — Sun, 07 Feb 2010 17:43:00 GMT

阅读: 663 评论: 4 作者: 邀月发表于 2010-02-08 01:43 原文链接

《Microsoft Sql server 2008 Internal》读书笔记--目录索引

上节主要学习了聚集健的依赖（The Dependancy on the Clustering key）和建立非聚集索引的聚集键的三个基本要点：聚集键应该是惟一的、窄的、静态的。本节我们继续深入学习物理的索引结构(physical Index Structures),这一部分分为两类：一、聚集索引的物理结构。二、非聚集索引的物理结构。

今天我们先来看第一部分： 聚集索引的物理结构

索引页(index pages)的结构和前面学过的数据页(data pages) 非常类似。惟一区别是前者存的是索引记录，而后者存的是数据记录。像SQL Server中大多数其它类型的页一样，索引页也是固定的8K大小或8192字节。索引页也有一个96字节的Header,在每个页的末端都有一个两字节的偏移数组，用以指示每行在页中的偏移量。一个非聚集的索引拥有全部三类分配单元，分别是IN_ROW_DATA，ROW_OCERFLOW_DATA和 LOB_DATA。每一个索引在目录视图sys.indexes中对应一行。index_id是1(聚集索引）或2-250,256-1005（非聚集索引)。正如data pages一样，251-255是系统保留值。

索引行格式 （Index Row Format）

索引行(Index rows)和数据行(Data rows)的结构非常类似。但有两个主要的区别：一、一个索引行不能有稀疏列(Sparse columns)。一个稀疏列可以用于索引，但不能作为主键，并且在创建索引时不能定义为稀疏列。二、如果一个聚集索引被创建时未定义成惟一(unique),那么重复键值包含一个唯一标志(uniquifier)。

另外两个区别是：一个索引行没有使用TagB或FSize行头部值(row header value) ,作为FSize字段（本来是行末尾的固定长度部分）的替代，页头部(page header)Pminlen的值被用于解码一个索引行。Pminlen Value表明行末尾的固定长度部分的偏移量。如果索引行没有可变长度列或可空列，那就是行的末尾。仅当索引行在字段Ncol有可空列，同时空位图 (null bitmap)也被设置（这句翻译不好，原文是Only if thd index row has nulable columns are the field called Ncol and the null bitmap both present)。Ncol字段包括一个表明索引行有多少列的值，这个值被用于决定在null bitmap中有多少bits。数据行有一个Ncol字段和空位图（决定是否任何列允许为空），而索引行只有一个空位图和一个Ncol字段（决定索引的任何列是否允许Nulls,如下表：

Information	Mnemonic	Size
Status Bits A	TagA Bits1 through3	1 byte
Fixed-length data	Fdata	pminlen-1
Number of columns	Ncol	2 bytes
NULL bitmap(1 byte for each column in table; 1 indicates that the corresponding column is NULL)	Nullbits	Ceiling (Ncol / 8)
Number of variable-length columns only Present if >0	VarCount	2 bytes
Variable column offset array;Only present if VarCount>0	VarOffset	2 * VarCount
Variable-length data;if any	VarData

聚集索引结构(Clustered Index Structures)

聚集索引的叶级是数据本身。当一个聚集索引被创建时，这些数据被物理复制并基于聚集健排序。聚集索引的行结构和Heap的行结构完全相同，除了以下一种情况：

当一个聚集健没有被用"UNIQUE" 定义时。在这种情况下，SQL　Server必须确保内部惟一性。为此，每个重复行需要一个附加的惟一值。

带 Uniquifier限定符聚集索引行(Clustered Index Rows with uniquifier)

正如前面所了解的，当没有使用UNIQUE属性时，SQL Server会增加一个4字节的惟一标志符以确保每一个nonunique健值的惟一。因为聚集键被用于识别非聚集索引(书签查询)所引用的基本行，这就需要一个惟一的方式去指向聚集索引的每一行。

SQL Server仅仅在必须的时候增加唯一标志（uniquifier),也就是说，当重复键被加到表里的时候。我们看一个例子：

代码

Use TestDb
go

IF OBJECTPROPERTY(object_id('Clustered_Dupes'), 'IsUserTable') IS NOT NULL
    DROP TABLE Clustered_Dupes;
go

CREATE TABLE Clustered_Dupes
(
    Col1    CHAR(5)    NOT NULL,
    Col2    INT        NOT NULL,
    Col3    CHAR(3)    NULL,
    Col4    CHAR(6)    NOT NULL
);
go
CREATE CLUSTERED INDEX Cl_dupes_col1
ON Clustered_Dupes(col1);
go
SELECT indid, keycnt, name
FROM sysindexes
WHERE id = OBJECT_ID ('Clustered_Dupes');
go

第二列KeyCnt，显示了一个索引的键值数量。这个结果是;

indid keycnt name
1 2 C1_depes_Col1

这个值是2（需要注意这是在兼容性视图 sysindexes,而不是在目录视图sys.Indexes中）。如果使用"UNIQUE"属性，这个值应该是1。因为在一个非惟一的健上创建一个聚集索引是不被推荐的，原因是这样SQL Server为保证行惟一将不得不浪费时间和空间。这个已经在前面讨论过了。

聚集索引的非叶级(The Non-Leaf Level(s)of a Clustered Index)

当一个B-Tree被创建时，为了导航到索引的叶级，它包含了叶级的数据行。非叶级的每一个行(针对叶级的每一个页(Page))有一个项(entry)，这个项包含了一个索引键值和一个6字节的指针，指向这个页。在本例中，页指针由一个2字节的FileID和一个4字节的PageNumberlnTheFile组成。SQL Server并不需要一个8字节的RID，因为slot Number不需要被存储。这个项(entry)的索引键部分总是显示能被用于指针页的最小值(mininum value)。注意，这并不是实际的最低值(Lowest value)。仅仅是页最低的可能值。（当一个页上的具有最低值的行被删除时，这个级上方的索引行并没有被更新）

分析一个聚集索引的结构(Analyzing a Clustered Index Structure)

我们先看一个例子：

代码

CREATE TABLE Employee
(
EmployeeID        Int                NOT NULL    Identity,
LastName        nchar(30)        NOT NULL,   -- created as fixed width to make our row size exactly 400 bytes (to simplify the math/visualization)
FirstName        nchar(29)        NOT NULL,
MiddleInitial    nchar(1)        NULL,
SSN                char(11)        NOT NULL,
OtherColums        char(258)        NOT NULL    DEFAULT 'Junk'
)
go

注意我们每行刚好400字节，换句话说，每个数据页(8096/400=20.24)可以放20行数据。这里有个原因是IN_ROW数据行不能跨页。

在上面的定义中，这个表是一个Heap ,我们给它加一个聚集索引

-- Add the clustered index
ALTER TABLE Employee
ADD CONSTRAINT EmployeePK
PRIMARY KEY CLUSTERED (EmployeeID)
ON [PRIMARY]
go

我们使用前面介绍过的DMV来查看索引的存储状态：

代码

------------------------------------------------------------------------------
-- Analyze the Employee Table's Clustered Index
------------------------------------------------------------------------------

SELECT index_depth AS D
    , index_level AS L
    , record_count AS 'Count'
    , page_count AS PgCnt
    , avg_page_space_used_in_percent AS 'PgPercentFull'
    , min_record_size_in_bytes AS 'MinLen'
    , max_record_size_in_bytes AS 'MaxLen'
    , avg_record_size_in_bytes AS 'AvgLen'
FROM sys.dm_db_index_physical_stats
    (DB_ID ('IndexInternals')
    , OBJECT_ID ('IndexInternals.dbo.Employee')
    , 1
    , NULL
    , 'DETAILED');
go

结果：

从上图中我们看到：正如我们所期望的那样，80000行数据的表一个 4000页的叶级。从Minlen我们看到，非叶级的行长度只有11字节。这个结构很容易被细分成:4字节对应EmployeeID,6个字节对应页指针，每行仅增加一个字节的开销(overhead)。为什么呢？因为我们的索引行只包含一个固定宽度的列，并且这些列中没有一个允许空值(Null),因此，不需要在索引页放置一个空位图。此外，你可以在结果中看到，在Level 1仅仅只有7页数据，回忆以前我们介绍的B-Tree存储结构，我们再看看以上数据的存储结构：

我们可能通过DBCC IND命令进一步了解索引页的存储明细。

代码

IF OBJECTPROPERTY(object_id('sp_tablepages'), 'IsUserTable') IS NOT NULL
    DROP TABLE sp_tablepages;
go

CREATE TABLE sp_tablepages
(
    PageFID         tinyint,
    PagePID         int,
    IAMFID          tinyint,
    IAMPID          int,
    ObjectID        int,
    IndexID         tinyint,
    PartitionNumber tinyint,
    PartitionID     bigint,
    iam_chain_type  varchar(30),
    PageType        tinyint,
    IndexLevel      tinyint,
    NextPageFID     tinyint,
    NextPagePID     int,
    PrevPageFID     tinyint,
    PrevPagePID     int,
    CONSTRAINT sp_tablepages_PK
        PRIMARY KEY (PageFID, PagePID)
);
go
--TRUNCATE TABLE sp_tablepages;
INSERT sp_tablepages
EXEC ('DBCC IND (IndexInternals, Employee, 1)');
go

SELECT IndexLevel
    , PageFID
    , PagePID
    , PrevPageFID
    , PrevPagePID
    , NextPageFID
    , NextPagePID
FROM sp_tablepages
ORDER BY IndexLevel DESC, PrevPagePID;
GO

部分结果;

注意上图中黄色部分，页数是完全连续的，这是因为表创建时我们在空表中建立了聚集索引，然而从Root往下，就不一定连续，因为索引被从叶级到Root按照(对应的每一个叶级)排序。这很重要，想像我们查询：

Select e.* from dbo.Employee as e where e.EmployeeID=27682

为了找到所有 EmployeeID=27682的行，（记住，这是聚集索引键值）SQL Server开始从Root页开始沿着叶级向下浏览，root Page我们已经知道是234 (IndexLevel最高2）,我们进·一步用DBCC Page命令分析：

DBCC TRACEON (3604)
go
DBCC PAGE (IndexInternals, 1, 234, 3)--参数3表示Grid格式，这里复习一下。哈，考试内容啊。

结果如下：

根据结果，我们大致判断一下27682应该在24881与37321之间, 也就是在第三页与第四页之间，为了精确定位，我们不得不沿FileID1的第三页的子页(ChildPageID)235,命令如下：

DBCC PAGE (IndexInternals, 1, 235, 3)
go

结果：

继续：

DBCC PAGE (IndexInternals, 1, 1616, 3);
go

小结：通过预览一个行结构，我们复习了两样东西，索引内幕和进程。并通过一个聚集索引值查找一个行。这个方法在从一个非聚集索引攀（检索已经聚集的表的数据时）执行一个书签查找(bookmark lookup)时被用到。为了更好地理解非聚集索引是如何被使用的，我们需要继续了解非聚集索引是如何被存储，以及它怎样找到数据行。这正是下一节将要了解的内容。快两点了，打个盹先。

评论: 4　查看评论　发表评论

最新新闻：
· Android命名冻酸奶之后是姜饼(2010-02-10 14:11)
· MySpace中国全面转型：欲争夺数字音乐版权(2010-02-10 14:02)
· 王冉：中国会成全球最大移动互联网市场(2010-02-10 13:42)
· 冷静，社交游戏！(2010-02-10 13:38)
· 百度新宠：网络视频(2010-02-10 13:37)

编辑推荐：.NET Reflector即将商业化

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

程序物语(九):解读你的生存法则

邀月 — Sat, 06 Feb 2010 02:01:00 GMT

阅读: 1108 评论: 10 作者: 邀月发表于 2010-02-06 10:01 原文链接

　　昨天，与一位朋友聊天，他刚吃完公司的年夜饭，情绪非常低落。我断断续续地了解了他的的近况。由于工资收入不佳，股市几乎赔去十之六七，家人的生活成本的压力非常大，据他自称，已经严重影响了家庭的稳定。

　　我这位朋友的经历非常典型，他的现状其实提出了一个极为现实的问题：程序人该如何解读自己的生存法则？

　　第一条路：我们一般人都有一份稳定的工作，作为收入的主要来源。另外，一般都有一些额外收入，例如股市房市晃悠或干点私活，或合伙业余创业。

　　当然，还有第二条路：如果你不用考虑生存问题，专心进入某一行业的高层管理，那也挺诱人，虽然路途挤了，累了，像春运的无座站票，但终点是让你满意的。与春运不同的是，每个人基本都能到家，而这条路只有极少极少数的人能成功走完。失败的经历，我们叫它人生财富；成功的经历，那是财富人生！所以，对绝大部分的人来说，这条路是可以修炼，不可强求结果。

　　我们可能还是得从稳定的基本工作做起。人过了一定的岁数，比如很多人喜欢提到的30大关，心态会慢慢的起变化，请注意，是从内而外的，先是自己觉得好像需要改变，然后老板也觉得需要更新鲜的血液来补充，于是有意无意地给你压力，这更加剧了你内心的争斗。我的朋友就是处于这个当口。有句古话：“千里马常有，而伯乐不常有”。意思是说有才能的人很多，关键是要有会识别人才的能力，而识别的功夫只有伯乐才能做得到。伯乐很少有，于是大量的千里马被埋没了。

　　牢骚可以发，人的情绪是需要发泄，而不是压抑。发泄过后，有两种结果：

　　一种是：心情舒服了，继续过日子，更加埋头做技术。

　　另一种：不断总结，寻求人生境界的突破。最重要的是付出实实在在的行动。

　　我们今天就来看看，问题究竟出在哪儿？

　　首先，问题从自身找起。有人说过，在沙滩上要想被人找到，你必须成为贝壳，而不是一粒沙子！我觉得，之所以有今日之困境，重要的原因是我们是百里马而不是千里马。当然，有些人是一专多能的百里马，但仍然不是千里马。这对伯乐的要求太高了，因为百里马实在是太多了，每年有数百万的增量从各个学校涌入马厩抢槽抢草，伯乐即使有心也无力啊，招呼不过来。像NBA的角色球员，主教练是不会为你量身定做战术的，只有核心才有资格让教练付出脑细胞来做这些战术设计。所以，百里马的首要技能是识途，至少知道自己的槽在哪儿，什么地方的草料最有保障，更重要的是，知道自己在什么位置最容易被拉风的伯乐看到。

　　这里有个建议：即使内在的修炼是关键，也要注意适当的外在表现 。我们时常看到有人在采访或其他公开场合侃侃而谈，头头是道，那形象帅呆了。很少人去想，这些人除了颇具慧根之外，背后付出了多少的努力。台上三分钟，台下十年功，那真不是唬人的。我们常犯的两类错误是：过于封闭或过于沉不住气。过于封闭者，则秉持“大中华局域程序员”的本色，长期划地为牢，跟人交谈，三句必扯到程序，也不管听者对此感兴趣还是讨厌。可地球人都知道，在中国闷头做技术是是很伤人的，有点像葵花宝典，不，比葵花宝典还要惨，同样失去很多，至少练那玩意儿可以给你天下第一的快感。如今的现实，过长时间思绪封闭，大多数人只会收获抑郁和淘汰。（不绝对，不要找我算账啊。）酒香不怕巷子深，一句话害死多少懵懂少年哪。过于沉不住气者，则缺乏城府和做人的深度，心里藏不住事，有什么情绪都挂在脸上，该说的时候说，该沉默的时候还是忍不住说,，忘了那句古训“祸从口出”。不妨换一种思路：平时多用心，读书看好文，培养自己独特的分析能力，注意观察团队成员的爱好，尽量做到话出见效，要求高点，那叫“画龙点晴”。厚积薄发，你会收获意想不到的东东。

　　智商、情商、财商是现代人成功必备的核心要素。智商，反映一般人的生存能力。情商，反映一个社会人的生存能力。财商，则反映现代经济人的生存能力。这里，我承认有的人智商很高。但是，说句实话，跟程序打交道的人有几个人傻啊，这应该是最精英的群体之一，只是很多人不注意自己的策略和方法去展现，去发挥而已。所以，大多数人的智商差距不大，情商的差距可以靠后天的悟性和修炼来弥补，而财商，则可能是我们最最欠缺的东东。学都没地方学。失败了更是代价不菲。这就是我们所处的环境。

　　其次，要有敏锐的选槽意识。马儿的寿命本不长，何况还有疾病等意外因素的困扰，要想保持数百里的水平也不易啊，所以，要不断地选好的槽。跳槽的意义，在于得到更大的槽，更适合你的槽，为你量身定做的槽。既然现实的状况是“千里马不常有，伯乐更不常有”，那么，就让百里马来相伯乐吧。如果在一个团队，你始终做的是代码、数据、架构，由于公司的经营策略等问题，你无法在这里得到成长性的回报，你的努力由于种种原因打了水漂，那么，就不妨换个槽口试试。当然，前提是你有更强的奔跑能力，这样做基于两个原因：一、人往高处走对个人和团队都是适用的，个人不适应团队，个人被淘汰。同样，个人成长过快，团队停滞或进展缓慢，团队被抛弃。这是社会的自然法则，是良性的竞争。二、根据需要层次说，人的一生有五个层次，在人生的每个阶段都应有更高的追求，最高的目标应该是自我价值的实现。而30岁，正好是一个关口，从某某层次上升的关口。那，谁为跳槽买单？这个要看，你所代表的是一个职位，还是一种无可替代的能力。如果是职位，团队没有损失。如果是后者，团队巨亏。当然，跳也有跳的技巧，关键是成熟的心智和信心。雄关漫道真如铁，而今迈步从头越。信心源于行动。

　　这里要说的是，如果你只是为了换槽而换，一个换一个，可能永远也不会得到价值的累积。 因为，你只服务于一个老板。你的收入绝大部分来源于此。他的经营境界的高低，直接决定了你的价值。而你，是被动的。所以，邀月的建议是：既然打着灯笼也找不到伯乐，不妨多添几口槽吧。比如巴菲特，比尔·盖茨，google的创始人谢尔盖·布林和拉里·佩奇，****。善于理财的高手，哪一个人是因为只为一家公司工作的？他们善于多渠道的投资，善于从0到1，更善于从1到1,000,000乃至更多。这才是他们高明的地方，也是财商的魅力所在。他们知道：把所有鸡蛋放在一个篮子里是多么疯狂。

　　此外，社会的因素可能更重要，但那是一个更为复杂的系统，比起灵魂之树的神经网络更为繁杂，我们确实没有精力去深究，暂且略去。但请不要忘记：自身的修炼是前提。

　　结语：程序世界里，生存是第一要务，是第一层关口，解码正确，则不断升级成功。解读失败，则是无言的Over结局。虎年将至，兼以此文作为牛年的总结，在这里邀月祝愿所有的百里马得其善所，冲关成功！祝愿所有千里马奋蹄疾驰，所向披靡！

所有程序物语系列文章：

http://www.cnblogs.com/downmoon/category/226146.html

评论: 10　查看评论　发表评论

编辑推荐：.NET Reflector即将商业化

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

《Microsoft Sql server 2008 Internal》读书笔记--第六章Indexes:Internals and Management(2)

邀月 — Thu, 04 Feb 2010 13:51:00 GMT

阅读: 849 评论: 18 作者: 邀月发表于 2010-02-04 21:51 原文链接

《Microsoft Sql server 2008 Internal》读书笔记--目录索引

上篇主要介绍了索引中的基本概念B-Tree及分析索引的工具，下面我们继续学习理解索引的存储结构。这一节太费时间了，整整看了两个晚上，将近六个小时.累啊！

The Dependancy on the Clustering key

从上面的学习我们了解到：索引结构被分为两类索引组件：叶级(leaf level)和非叶级(non-leaf Level(s)) 。

一个聚集索引的叶级包含索引键和数据。“聚集索引的叶级除了键值还有什么？”答案是“其他的任何东东(everything else)”。也就是说，表中的所有行的列都在一个聚集索引的叶级中。换种说法是：当一个聚集索引被创建的时候，数据(data)变成了聚集索引的叶级，同时，表中的数据被聚集键复制和排序。一旦被创建，一个聚集索引被逻辑维护而不是物理维护，排序被通过一个双链列表（称为页链page Chain)维护。（注意：在一个堆(Heap)中页是不会有任何方式互相链接的。 ）在页链中的页的排序和数据页中行的排序，均是基于聚集索引的定义。决定哪些列用于索引是一个重要的性能参考指标。

由于数据页的实际页链只能被一种方式排序，所以一个表只能有一个聚集索引。而且，通常情况下，大多数在使用聚集索引的时候性能更佳。然而，聚集键需要被慎重选择，为了适当选择索引键，你必须理解索引是如何工作的。即聚集键的内部依赖，特别是非聚集索引。

位于聚集键上的非聚集索引的依赖(dependency)在SQL Server 7.0时代存储引擎被重新架构时就已经存在了，它最初是用于（当使用一个非聚集索引去引用表中相应的行时）行如何被标识。如果一个表有聚集索引，行被聚集键标记(和查找）。如果没有聚集索引，则行被物理行标识(identifier RID)标记（和查找）。查找相应的数据行的处理就好像查找书的书签。

非聚集索引仅仅包含索引定义的数据 。当在一个非聚集索引中查找一行的时候，你通常不得不到实际的数据行以得到没有包含在非聚集索引部分的数据。为了检索这部分附加数据，你必须深入表的内部。

首先，最重要的是，所有聚集索引必须是惟一的。为什么必须是惟一的首要原因是非聚集索引项能够准确地指向一个特定的行。考虑到如果一个表被最后一个名字（last name)的不惟一的值聚集，问题来了。如果一个非聚集索引存在于一个惟一的值，比如社会安全号（对我们而言就是身份证号），一个查询社会安全号为 123-45-6789的索引，结果，聚集键是“Smith”,那么多个最后名字为Smith的行出现，到底是哪个？这个社会安全号为 123-45-6789的特定行，如何被有效定位？

为了聚集键能被有效使用，所有非聚集索引项必须准确地指向一行。因为SQL Server中的指针是聚集索引，所以，聚集索引必须是惟一的。如果你创建一个聚集索引时没有使用Unique关键字，系统在必要时会自动向这些行添加一个惟一标志列以确保内部的惟一性。这个惟一标志(uniquifier)是一个4字节的整数，当行的聚集键不惟一时，自动被回到数据行，一旦被添加，它变成了聚集键的一部分，意味着它在每一个非聚集索引中被复制。　

第二，如果一个聚集键(Clustering key)被用于从一个非聚集索引到一个聚集索引的（数据）内部查找相应的数据行，那么,这个聚集键是表中最被过多使用的数据。所有列都组织索引键，这些键被包含于每一个非聚集索引附加于实际数据行中。结果，索引键的宽度变得重要了。考虑一个拥有12个非聚集索引和一百万数据的表的一个聚集索引拥有64字节的聚集健。不计算内部和结构头部，仅仅用于存储在每一个非聚集索引键的索引键将是732MB,而如果聚集键只有8字节的话，这开销是92MB，而如果4 字节的话，将只有46MB。尽管这只是一个粗略的估计，它表明如果你使用了一个过宽的聚集键，将浪费大量的空间（以及潜在的缓存池内存）,性能的损耗是比较可观的。因此，一个过宽的非聚集索引是应该避免的。

第三，因为聚集索引键是整个表中最冗余的数据，你应该确信你的聚集键是不易变的(not volatile）,如果一个聚集健改变，它有以下几个副作用：1、它会引起聚集索引内的记录的搬迁，造成页page的分离与碎片。2、它引起每一个非聚集索引被修改，以便于所有相关的非聚集索引的行的索引键的值被纠正。这既浪费时间和空间，导致需要整理的碎片，增加了不必要的开销（每个列重组聚集键）。

这三个属性：惟一、窄和静态也被用一个好的主键（但不总是）。因为你只有一个主键（仅仅一个聚集键）。SQL Server使用一个惟一的聚集索引以强化主键约束。然而，并不是每一个表的创建者（唉，别睡着了，说你呢！）都知道这一点。于是，主键没有被坚持这些标准(举例，当主键被选为数据的自然健(natural key)，即，如一个宽的7个列的100个字节组合)，那么使用一个聚集索引去强化惟一性，并在每一个非聚集索引复制完全的100字节的列组合将具有极强的反作用。l因此，对一些不知情的（unsuspecting）数据库开发人员（具体就是刚才睡觉的那几位),一个非常宽的聚集健在创建表时就被系统不知不觉的加上了，好消息是：你可以定义主键是非聚集索引，并且轻易地在一个不同的列上创建一个聚集索引 。当然，你必须知道什么时候和怎样做这些。

最后，一个表的聚集键也应当以Insert时产生最小碎片为依据。尽管一旦聚集索引被创建后只有一个逻辑排序被维护，这个结构的维护确实有开销。如果行需要持续地被插入在随机点（如插入一个以last name排序的表中），那么这个表的逻辑排序的维护成本比总是插入一个以自增长列排序的表（总是在表的末尾处）略微有些提高。

小结：表的聚集键应该基于表的用途，同时也应当基于SQL Server在聚集健的内部依赖。聚集键应该是惟一的、窄的、静态的，最好，不断增长？（ ever-increasing)。

好的聚集键的例子如下：

■、单个列键被定义为一个不断增长的自增长列(如int 或bigint)

■、一个不断增长的日期列(date而不是datetime)，紧跟着一个惟一的行标识（如自增长列）组成一个复合键，这对基于日期分区的表非常有用。如SalesDate(8字节）+SalesNumber(4字节）组合为12字节，注意在SQL Server 2008中，一个日期列(date)不包含时间。但是单独的一个日期列(date)并不是一个好的聚集键，因为它不惟一。

■、一个GUID能被成功地用作一个聚集键，因为它本身就是惟一的。相对的窄(12字节）,可能是静态的。然而，仅仅在不断增长的模式下，GUID 才适合被用作聚集健。在一些情况下，GUID是在SQL Server的外部被生成或在SQL Server内部用 NewID()生成，这种模式下产生的碎片抵消了这个列作为聚集健的作用。如果可能，请选择NEWSEQUENTIALID()函数或选择其他列。如果你想用GUID作为一个主键，并且不是自增长的，你可以把这个列作为一个非聚集索引代替聚集索引。

总之，没有一个通用的最好的绝对有效的法则来决定一个聚集键的选择。然而，一个表如果只有一个索引，并且是非聚集索引，那么在聚集健上的非聚集索引依赖将不再相关。如果是聚集索引，可以采取任何形式。幸运的是，大多数表有一个以上的非聚集索引，大多数的表有一个聚集索引性能更佳。因此，第一步：精心选择聚集键，第二步，查找一个正确的平衡，选择适当的，最小数量的非聚集索引。

非聚集索引 （ＮonClustering Indexes)

正如前面所述，所有索引中有两类主要组件：叶级(leaf level)和非叶级(non-leaf Level(s)) 。一个聚集索引的叶级就是数据。一个非聚集索引叶级是一个独立的、额外的结构（一些数据的copy),特别地，一个非聚集索引取决于它的叶级形式的定义，非聚集索引由索引键，任何包含性列、数据行的书签(bookmark)值,,一个蜚聚集索引的数量跟表中的数据行一样多，除非索引定义时使用了过滤谓词 (Filter predicate)。过滤谓词在SQl Server 2008是新增的。

非聚集索引的工作方式有两种：

１、辅助指向数据或直接回答查询。当一个非聚集索引拥有查询中请求的全部数据时，这就是所谓的“查询覆盖(query covering)”，这时索引被称为覆盖索引，此时，非聚集索引被用于直接回答查询而避免了书签查询(bookmark lookup)，一种对于非聚集索引异常昂贵的查询。

２、当一个非聚集索引没有包含查询中请求的全部数据时，这个查询被一个索引能找到的谓词驱动，此时，书签查询发生。如果一个表有一个聚集索引，非聚集索引被用于驱动查询去通过聚集键找到相应的数据行。如果是Heap(没有聚集索引），查询值是一个8字节的RID，实际行位置如下格式 FileID:PageID:SlotNumber。这个8字节值：2字节:4字节:2字节。后面还有深入了解。

非聚集索引的设置与否并不会影响数据页被组织。SQL Server　2008中，一个表中可以有999个非聚集索引。SQL Server 2005中是249个。实际使用环境中，你尽可能少数量的使用（因为一些例外(Exception)，比如Filtered Indexes）。

总而言之，非聚集索引不会影响基表，相反，基表的结构会影响非聚集索引的结构。如果你想减少开销和架构最佳性能，你最好理解这些。

约束和索引(Constaits and Indexes)

有关Primary Key约束和UNIQUE 约束，请查看MSDN:

http://msdn.microsoft.com/zh-cn/library/ms191236.aspx

http://msdn.microsoft.com/zh-cn/library/ms191166.aspx

一个基本的区别是后者可以是NUll,前者不允许NUll,两者都不允许重复。

Indexes Creation Options

CREATE INDEX命令的更多选项，请查看MSDN:

http://msdn.microsoft.com/zh-cn/library/ms188783.aspx

后面一节将学习物理的索引结构。

评论: 18　查看评论　发表评论

编辑推荐：.NET Reflector即将商业化

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

《Microsoft Sql server 2008 Internal》读书笔记--第六章Indexes:Internals and Management(1)

邀月 — Tue, 02 Feb 2010 04:29:00 GMT

阅读: 797 评论: 0 作者: 邀月发表于 2010-02-02 12:29 原文链接

《Microsoft Sql server 2008 Internal》读书笔记--目录索引

在第五章主要学习了table的内部存储结构，第七章《Special storage》中将继续深入学习存储机制，那将是本书最难理解的一章。第六章主要介绍index的基础知识，第八章是《query Optimizer》,下面我们先来看看第六章：Indexes:Internals and Management。这一章分为三部分：

1、介绍Index的使用、概念和内部构造,你也将了解索引如何被存储和它们是如何被检索的。

2、深入了解数据被修改时内部存储发生了什么，是如何发生的，以及SQL Server如何确保一致性(consistence)。你还将了解到修改数据的索引（对性能的）的潜在影响，比如整理。

3、索引的管理和维护。

前言：索引的好处是不言而喻的。一个良好的索引可能将你的查询请求从数百万的I/O下降到few甚至更少。同样，一个过度的索引设计(over-indexing)比起不用索引可能后果更为严重。因此，掌握必要的索引物理存储及存储引擎、策略、优化知识对于一个SQL设计人员是至关重要的。

首先，我们来一起学习第一部分：

索引分为聚集索引 (clustered index)和非聚集索引(nonclustered index)两种，在聚集索引的表中，表数据是按照聚集键排序被逻辑存放的。当你找到你要的数据时，搜索同时完成。而非聚集索引的表中。索引结构是完全和数据自身分离的。当你开始查找索引的时候，你必须按照某些引用指针(Reference Pointer)的排序得到实际的数据。

关于如何创建索引(index)，请查阅MSDN:
http://msdn.microsoft.com/zh-cn/library/ms188783.aspx

◆SQL Server Index B-Tree

在SQL Server中，索引被按照B-Tree结构组织，B-Tree即(balanced-tree),SQL Server使用一种特殊的B+tree结构。不像通常的树，B-Tree总是倒的(inverted)，它的根root(单个page)在顶部,叶(Leaf)在底部。中间级别的level取决于多种因素。B-Tree是一个在不同场合被重载(overload)的词,在本书中。它意味着整个的索引结构，如下图所示：

重要的是，我们需要理解SQL　Server中B-Tree是如何被构建的(constructed)，以及每一个Level中包含什么。我们通过一些简单的概念入手。

首先，索引有两个很基本的组件：一个叶级(leaf level)，一个或多个非叶级(non-leaf levels)。后者主要用于叶级的导航。此外，第一个中间级(first intermediate level)也被用于整理分析和在大序列索引查询的驱动预读(read-ahead)。

非页级(non-leaf Level)的存在主要是为了在叶级帮助迅速导航到一行的架构，而不是直接到数据本身。每个非页级存储了自下而上在每一页(page),直到Root级被创建。越高的级（即距离leaf越远的）存放更少的信息, 因为每个处于该级的行只包含位于下一级的最小键值，加一个指针。实际上，这些key（最多900字节或16个列）在SQL　Server中有助于保持索引树相对的小。

下面我们使用一个包含1,000,000（即1百万）“行”的索引的叶级为例。首先我们得明确，无论是leaf leave还是non-leaf level都是被存储在SQL Server pages(8KB pages)中。在这个例子中，non-leaf“‘ 行”将有4000字节。也就是说，每页只能存储两行。对于一个百万“行”的表而言，我们的索引的叶级将有500,000页。相对而言，这是一个非常宽的行结构，然而，我们并没有浪费很大的空间。假如我们叶级页有两个3,000字节的行，我们仍然每页两“行”，于是我们将浪费2,000字节的空间。

注意，这里为什么用"行"而不用数据行(Data Rows)，这是因为：这个页级可能是聚集索引（这自然就等于数据行），也可能这些叶级行是一些非聚集索引的包含性非键值列被加到索引的叶级中的行。当包含性列被使用时，叶级页可以包含更宽的行（超过900字节或16列限制）。在本例中，索引创建时页级将是4GB大小，(500,000个8kb大小的page)。如果使用最大限制，那么最后长到Root的树将会更小，并且最多有8个级，如下：
■ Root page of non-leaf level(Level 7)=2 rows=1 page(8 rows per page)

■ Intermediate page of non-leaf level(Level 6)=16 rows=2 page(8 rows per page)

■ Intermediate non-leaf level(Level 5)=123 rows=16 page(8 rows per page)

■ Intermediate non-leaf level(Level 4)=977 rows=123 page(8 rows per page)

■ Intermediate non-leaf level(Level 3)=7,813 rows=977 page(8 rows per page)

■ Intermediate non-leaf level(Level 2)=6,2500 rows=7,813 page(8 rows per page)

■ Intermediate non-leaf level(Level 1)=50,000 rows=6,2500 page(8 rows per page)

■ Leaf level(Level 0)=1,000,000 rows=500,000 page(8 rows per page)

更小的键大小将会有更快的级别，以同样数据为例，如果有更小的索引键将在非叶级带来更小的行大小，因此可以存储更多的行。如果只有20字节，将可以每而存储404行数据：

■ Root page of non-leaf level(Level 3)=4 rows=1 page(404 rows per page)

■ Intermediate non-leaf level(Level 2)=1,238 rows=4 page(404 rows per page)

■ Intermediate non-leaf level(Level 1)=50,000 rows=1,238 page(404 rows per page)

■ Leaf level(Level 0)=1,000,000 rows=500,000 page(2 rows per page)

请记住：更窄而不是更宽的键(key)将给索引带来更好的效率。最重要的是：索引的大小（即级的数量）取决于三点：1、索引定义。2、基表(table)是否有一个聚集索引。3、索引叶级的page数量。其中，叶级页的数量直接表中行大小和行数量。这并不是说在索引中一定要使用窄索引。有时还要适当使用宽索引。此外，像"包含性列"和filtered indexes也会影响索引的大小和用途。当然，最重要的是，使用正确的索引。不是吗？
分析索引的工具(Tools for Analyzing Indexes)

一、使用sys.dm_db_index_physical_stats

select * from sys.dm_db_index_physical_stats(DB_ID('testdb'),null,null,null,null);

关于sys.dm_db_index_physical_stats的更多使用，请参看MSDN：
http://msdn.microsoft.com/zh-cn/library/ms188917.aspx

二、使用DBCC IND命令,这是一个MSDN未公开的命令。

exec ('DBCC IND(testdb,[dbo.Fixed],-1)')

下一节将继续学习物理索引结构(phisical Index Structure)。

评论: 0　查看评论　发表评论

编辑推荐：.NET Reflector即将商业化

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

《Microsoft Sql server 2008 Internal》读书笔记--第五章Table(6)

邀月 — Mon, 01 Feb 2010 07:41:00 GMT

阅读: 900 评论: 1 作者: 邀月发表于 2010-02-01 15:41 原文链接

《Microsoft Sql server 2008 Internal》读书笔记--目录索引

上篇文章中提到五种典型的存储结构：一、固定长度的行；二、可变长度的行；三、Null和可变长度列；四、时间和日期数据；五、SQL_variant 数据。今天我们继续来看可变长度的行的存储：可变长度的列要比固定长度的列的存储复杂一些。

我们先来测试一个表Variable，有三个variable 列和两个固定长度列:

CREATE TABLE variable  
(
Col1 char(3)       NOT NULL,
Col2 varchar(250)  NOT NULL,
Col3 varchar(5)    NULL,
Col4 varchar(20)   NOT NULL,
Col5 smallint      NULL
);

SELECT object_id,  type_desc,  
    indexproperty(object_id, name, 'minlen') as minlen
    FROM sys.indexes where object_id=object_id('variable');
 
SELECT  name, column_id, max_inrow_length, pc.system_type_id, leaf_offset  
 FROM sys.system_internals_partition_columns pc
    JOIN sys.partitions p  
          ON p.partition_id = pc.partition_id
    JOIN sys.columns c
         ON column_id = partition_column_id AND c.object_id = p.object_id
WHERE p.object_id=object_id('variable');

可以看到:

现在，插入一行数据：

INSERT variable VALUES  ('AAA', REPLICATE('X', 250), NULL, 'ABC', 123);

说明:REPLICATE函数仅仅填充了250个X到col2,很有用的一个函数哟，特别在填充测试数据的时候。

我们可以按照前一篇所述的方法来查看data pages的存储状况：

简要说明：

1、还记得前面学过的存放顺序吗？先固定列，再可变列。所以Col1和Col5要先存储，并且偏移量为正值，而col2\Col3\col4偏移量分别是-1,-2,-3。正好表示它们分别是可变列的第一、第二、第三个序号。

2、0500表示该行有5列。

3、04代表null Bitmap没有使用。

4、0300代表共有三个可变长度的列。

5、0e01代表第一个可变列的结束位置，与第二个可变列的位置相同。这是为什么呢？可能有人猜出来了，因为插入的是Null,所以实际上并没有数据存储到行中。这与固定长度的行不同。固定长度的行，Null值也占用存储空间。

6、该行数据的总长度为273字节，计算方法是0X1101,经过字节换算，应该是0X0111=273

那么，存储这行数据到底用去多少空间呢？可变长度列意味着更大的开销(overhead),它们的实际长度是无法预测的。即便对于固定长度的列，开销的数量也会取决于表中列的数量。记住：Null bitmap必须有足够的空间来存放每列的bit值。此外，每行还必须包含2个字节overhead和行底部的行偏移量数组

再来看第三种存储：Null和可变长度列

可能，有人看了上面的图会说，可变长度的列既然并不存放实际数据，那么应该不会占用空间。可为什么还是有2个字节的偏移呢？这个-2是从哪儿来的呢？

因此，我们不能说SQL Server一点空间也不用。实际上，它仍然用了两个字节来存放了偏移数组。我们看一个例子：

CREATE TABLE dbo.null_varchar
    (
      id INT PRIMARY KEY IDENTITY(1,1),
      col1 VARCHAR(10) NULL,
      col2 VARCHAR(10) NULL,
      col3 VARCHAR(10) NULL,
      col4 VARCHAR(10) NULL,
      col5 VARCHAR(10) NULL,
      col6 VARCHAR(10) NULL,
      col7 VARCHAR(10) NULL,
      col8 VARCHAR(10) NULL,
      col9 VARCHAR(10) NULL,
      col10 VARCHAR(10) NULL
    );
GO

SET NOCOUNT ON
INSERT INTO null_varchar(col10)
   SELECT 'a';
INSERT INTO null_varchar(col1)
   SELECT 'b';
INSERT INTO null_varchar
   SELECT '','','','','','','','','','c';
INSERT INTO null_varchar
   SELECT  'd','','','','','','','','','';
GO

从红色部分显示，0x03fe意味着0000001111111110，从右往左看，第一列是not Null,第10列是not Null,其余列是Null。共11列，后5列被忽略了。

同理：0x07fc意味着0000011111111100，从右往左看，第一列和第二列是not Null,其余列是Null。

第四种存储方式:日期和时间格式

CREATE TABLE times (
    a char(1),
    dt1 datetime,
    b char(1),
    sd smalldatetime,
    c char(1),
    dt2 datetime2,
    d char(1),
    dt date,
    e char(1),
    dto datetimeoffset,
    f char(1),
    t time,
    g char(1),
    t0 time(0),
    h char(1),
    t1 time(1),
    i char(1),
    t2 time(2),
    j char(1),
    t3 time(3),
    k char(1),
    t4 time(4),
    l char(1),
    t5 time(5),
    m char(1),
    t6 time(6),
    n char(1),
    t7 time(7));
GO


INSERT INTO times
SELECT
    'a', '01:02:03.123',
    'b', '01:02:03.123',
    'c', '01:02:03.123',
    'd', '01:02:03.123',
    'e', '01:02:03.123',
    'f', '01:02:03.123',
    'g', '01:02:03.123',
    'h', '01:02:03.123',
    'i', '01:02:03.123',
    'j', '01:02:03.123',
    'k', '01:02:03.123',
    'l', '01:02:03.123',
    'm', '01:02:03.123',
    'n', '01:02:03.123';

需要说明的是：

对于datatime和smalldatetime,存储值为0意味着日期是'1900-01-01"，对于其他类型的日期值为693595意味着日期是"0001-01-01"

你可以通过这个语句查看对应的日期：

SELECT DATEADD(dd, 693595, CAST('0001/1/1' AS datetime2));

结果为默认值：1900-01-01 00:00:00.0000000

第五种：SQL_variant 数据

在此略去。

关于存储行更多的信息，在后面的第七章学习中将继续展开。

下一节将继续学习列和行的存储相关操作。

评论: 1　查看评论　发表评论

编辑推荐：.NET Reflector即将商业化

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

《Microsoft Sql server 2008 Internal》读书笔记--第五章Table(5)

邀月 — Sun, 31 Jan 2010 14:32:00 GMT

阅读: 762 评论: 1 作者: 邀月发表于 2010-01-31 22:32 原文链接

《Microsoft Sql server 2008 Internal》读书笔记--目录索引

前面我们学习了数据页的存储结构以及如何检查一个data page。那么如何查询一个物理页呢？

记得在上篇文章时，我们介绍了了一个未公开的DBCC PAGE命令。该命令前需要知道页的具体参数，如
--查询testdb数据库的第一个文件的第157页的数据页
--DBCC PAGE (testdb,1,157,1);

那么，如何查询第一页(first_page)的值呢？我们来看一个例子：假定我们创建一个表Fixed，语句如下：

CREATE TABLE Fixed  
( 
Col1 char(5)     NOT NULL, 
Col2 int         NOT NULL, 
Col3 char(3)     NULL, 
Col4 char(6)     NOT NULL  
);
INSERT Fixed VALUES ('ABCDE', 123, NULL, 'CCCC');

用下列语句，可以查询Fixed表的first_page的值。

SELECT object_name(object_id) AS name,  
    rows, type_desc as page_type_desc, 
    total_pages AS pages, first_page 
FROM sys.partitions p  JOIN sys.system_internals_allocation_units a 
   ON p.partition_id = a.container_id 
WHERE object_id=object_id('dbo.Fixed');

结果为:
name rows page_type_desc pages first_page
Fixed 1 IN_ROW_DATA 2 0xEE0000000100

我们将这个十六进制结果转化一下，00　10　00　00　00　EE。

前两个group代表一个2字节的文件数。这里是0x0001，页数是00EE,十进制是。可以通过一个function来转换。

CREATE FUNCTION convert_page_nums (@page_num binary(6)) 
   RETURNS varchar(11)  
AS  
  BEGIN 
   RETURN(convert(varchar(2), (convert(int, substring(@page_num, 6, 1))  
          * power(2, 8)) +  
             (convert(int, substring(@page_num, 5, 1)))) + ':' +  
               convert(varchar(11),  
   (convert(int, substring(@page_num, 4, 1)) * power(2, 24)) +  
   (convert(int, substring(@page_num, 3, 1)) * power(2, 16)) +  
   (convert(int, substring(@page_num, 2, 1)) * power(2, 8)) +  
   (convert(int, substring(@page_num, 1, 1)))) ) 
  END;

SELECT dbo.convert_page_nums(0xEE0000000100);

结果为1:238

警告：first_page列并不一直是指向表的第一页。毕竟这是一个未公开的命令。

第二种获取页实际数字的方式是使用另外一个未公开的命令DBCC　IND。例如：

DBCC IND(testdb, fixed, -1);

得到如下类似结果：

PageFID    PagePID    IAMFID    IAMPID    ObjectID    IndexID    PartitionNumber    PartitionID    iam_chain_type    PageType    IndexLevel    NextPageFID    NextPagePID    PrevPageFID    PrevPagePID
  1    238    1    239    1029578706    0    1    72057594041925632    In-row data    1    0    0    0    0    0

第三种方式是使用一个未公开的function：sys.fn_PhysLocFormatter

SELECT sys.fn_PhysLocFormatter (%%physloc%%) AS RID, * FROM Fixed;

结果：
RID Col1 Col2 Col3 Col4
(1:60928:0) ABCDE 123 NULL CCCC
请注意这个结果有所不同。

下面将分别介绍五种类型的存储方式：

一、固定长度的行；二、可变长度的行；三、Null和可变长度列；四、时间和日期数据；五、SQL_variant 数据

首先，我们来看第一种:固定长度的行的存储。

我们以前面创建的Fixed表为例：

一旦表被创建，我们可以从目录视图中查看到相关列的信息；

SELECT object_id,  type_desc,  
    indexproperty(object_id, name, 'minlen') as min_row_len 
    FROM sys.indexes where object_id=object_id('Fixed'); 
 
SELECT  column_id, name, system_type_id, max_length as max_col_len
FROM sys.columns  
WHERE object_id=object_id('Fixed');

结果：

object_id    type_desc    min_row_len
1029578706    HEAP    22

column_id    name    system_type_id    max_col_len
1    Col1    175    5
2    Col2    56    4
3    Col3    175    3
4    Col4    175    6

注意：sysindexes目录视图包含列minlen和xmaxlen，存储了行的最小和最大长度。在Sql Server2008中，这些值在任何视图中是不可用的，除非你通过一个未公开的function:indexproperty读取它。对于一个只包含固定长度的列的表来说，indexproperty函数通过传入的minlen返回值等于列长度的总和（从sys.columns.max_length)加上4个字节。它不包含列数目的两个字节和用于null位图的字节。

通过以下语句可以查看列的偏移量：

SELECT  c.name AS column_name, column_id, max_inrow_length,  
         pc.system_type_id, leaf_offset  
 FROM sys.system_internals_partition_columns pc 
    JOIN sys.partitions p  
      ON p.partition_id = pc.partition_id 
    JOIN sys.columns c 
         ON column_id = partition_column_id  
            AND c.object_id = p.object_id 
WHERE p.object_id=object_id('fixed');

Col1    1    5    175    4
Col2    2    4    56    9
Col3    3    3    175    13
Col4    4    6    175    16

对了，如何显示Buffer数据，请参看上篇内容
简要说明：

1、第一个字节：状态位A是0x10显示bit4打开，bit5未打开。我们得知该行没有可变长度列。

2、第二个字节未使用。

3、第三和第四字节是0x16等于22,显示了固定长度的列长度之和。

4、各列的偏移量分别为4,9,13,16。

5、第22字节处是0400,表明列数为4

6、null bitmap未使用。

说实话，这节和下节是本书第二难理解的内容。最难理解的内容要数第七章了。呵呵。邀月确实有点半生不熟。共同学习是我的目的。

评论: 1　查看评论　发表评论

编辑推荐：.NET Reflector即将商业化

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

程序物语(八):我心戚戚

邀月 — Fri, 29 Jan 2010 04:12:00 GMT

阅读: 1273 评论: 7 作者: 邀月发表于 2010-01-29 12:12 原文链接

　　有人说，地上本没有程序员这条路，走的人多了，也就成了路。

　　其实，程序员真正成为一个面向公众开放的职业，的确是不长的。大约从上世纪八十年代中期，特别是九十年代网络的普及，程序员便如一夜春风万树开，突突冒了出来，望去一大片一大片满是的。客观上，由于我们所处的社会环境，经历了极为深刻的社会变革，不仅仅是上辈人不适应，反应快的年青人面对这种变革也有些手足无措。于是，出现了许许多多的指导类书籍，如《****精通****》，《***实战***》，也有像《****速成**》之类的快餐文化，更有许多培训机构，像“北大****”等提供了你无法拒绝的服务内容。

　　接触这些内容无疑是有益的，至少开阔了我们的眼界，丰富了我们的思路。邀月在这里想要说的是，你不能把这些当成生活的重心。比起外在的交流，我更相信内心的修炼对一个人的影响，而修炼的对象是情商。

　　如果你是一位女性读者，请善待你的男友或爱人，他们活得并不容易，从事程序员或相关行业是一项很艰苦的工作，很可能未到40岁，他们的身体机能已经衰老到60岁了，而且，他们还要承担社会责任和人们对他们的高期望。他们努力了，可这个行业有太多的不确定性。请不要抱怨他们，他们面对的抱怨多得也许你无法想像。

　　如果你是一位男人，更请珍爱你的女友或爱人。问问自己：在你二十多岁的事业无为期，是谁把自己生命中最好的年华给了你？这个阶段的女人是最具无私精神的，她不求回报，只相信你会给她带来幸福。她可以不要物质享受，因为你没有。她可以不讲究生活品质和情调，因为你也没有时间和精力。当她需要你陪伴的时候，你却在加班或解决技术难题。当她略带羡慕地提到朋友出国旅游时，你千万要记得那是你也应该让她享受的。请相信：你得来这一切，全是因为她给你带来幸运，无论如何不要把她付出的这一切看成是理所当然的。

　　人生，有很多场战争，爱情战、婚姻战、良心战、命运战，一场场打下来，女人的心变得很脆弱，即使不用锄头挖，墙角也会自然塌！男人的信条是：永不放弃！你可以错误，但不能退却。情感之路不会有不劳而获的事等着你，你的心智成熟到什么地步，你会有什么样的收获。用你的坚强保护你的女人，保护你的家人，给她们一间永不漏雨的小屋。《蜗居》中的郭海萍和苏淳最后被导演捆在了一起，现实中经历这样的风雨还能在一起的概率跟彩票中五百万的机率大致相当。

　　 除了情感的修炼，还有一项更重要的能力培养是商业的敏锐性。

　　在某一段时期，我们总是会沉浸在一个技术领域，对外界不闻不问。如果你的生活周期一直如此，那么是很可怕的。你可能不知道，危机就像沙漠中的饿狼，已经来到你的身后，就等你回头呢。我时常跟新来的程序员说，不要因步自封，把自己限制在一个“程序员”的套子里而不自知。因为，你处在一个商业社会里，你首先要解决的是生存问题，不是一个人，是你的一家人。而没有一点点商业嗅觉，你也无法完成你的程序生涯，你百分百会中途退场！

　　这阵子，海南的房产炒得很火。很多人在议论，房价从２****涨到7****元，却很少有人想为什么我没赚一把呢？我想先问几个问题：天朝的旅游指导文件是在什么条件下出台的？出台的前六个月你有没有从其他渠道来了解相关背景？中国经济和旅游业的宏观背景如何？现阶段中国的海洋与能源的解决方案？民间游资是在什么样的海域作什么规律的流动？****。
　　如果这些问题，你都有清晰的答案，那么，恭喜你，无论如何，有一天你一定会成为你想成为的那种人。所以，请记住一定要搞清楚：狼来的前几天晚上，羊圈里究竟发生了什么？如果你只是一只普通的羊，过着跟其他羊无二的生活，即幻想着有一天会成为会飞的羊，对不起，你一定会像其他羊一样，最终死在倒塌的羊圈里。

　　所以，在人生的某个阶段，宁静的小岛，心灵的积淀，是必须的。人生，不总是步履匆忙在向前，有时可能在倒退，辨清方向，更好。请相信我一句话：生活不是我们的目的，生活得更好才是我们的目的。

　　怎么做？据国外研究，每个人都有自己的情绪周期，一般为五周左右。（这是针对西方人的，因为东方人含蕴，可能周期更长些。）在这个周期中，人的情绪像正则曲线一样起伏，其中有两周左右是人情绪最佳时期，这两周内几乎是文如泉涌，思路敏捷，出口成章，有股无法抵制的兴奋，有用不完的精力。所以，用心记录一段时间，记下自己最佳的情绪周期，情绪好时，惜之，不佳时，运用其他方法调节之。既然是活，为什么不每天活得更好一点呢？既然是做，为什么不每天做得更好一点呢？

所有程序物语系列文章：

http://www.cnblogs.com/downmoon/category/226146.html

评论: 7　查看评论　发表评论

编辑推荐：.NET Reflector即将商业化

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

《Microsoft Sql server 2008 Internal》读书笔记--第五章Table(4)

邀月 — Thu, 28 Jan 2010 06:25:00 GMT

阅读: 743 评论: 0 作者: 邀月发表于 2010-01-28 14:25 原文链接

《Microsoft Sql server 2008 Internal》读书笔记--目录索引

上篇我们主要学习了元数据(metadata)的存储及利用目录视图来查询这些信息，今天，我们继续学习数据页(Data Pages)。

数据页(Data pages)是包含已经添加到数据库的表中的用户数据的结构。正如前面所看到的，数据页有三类，每类数据页以不同的方式存储数据。复习一下，分别是in-row data pages、row-overflow data pages和LOB data pages。与其它类型的page一样，data pages也是固定的8K大小或8192 bytes。它由三类组件组成：the page Header,data rows和the row offset array,如下图所示：

1、Page Header

正如上图所示，每个data page (除去96 bytes,还有8096 bytes存放data,row overhead和row offset)。你可以使命下面的DBCC Page命令来查看。

2、Data Rows for in-Rows

Page Header的下面是row data,单个数据行最大可以存放8060 bytes的in-row data，这就是以前数据行不能超过8060限制的原因！有些行也可以在独立的页面(pages)中存放row-overflow data和LOB数据，存储在一个给定的page变量中的行数取决于表结构及数据被存放的结构。一个拥有全部固定长度列的表每页能存储相同的行数。一个拥有可变长度列的表在页中存放不同的行数以适应数据的实际长度。保持行长度尽量短，允许更多的行以适应页面，减少了I/O,改善了高速缓存命中率(cache-hit ratio)。

因此，作为系统架构师或数据库Designer，实在有必要了解这些啊。邀月深有体会。呵呵。程序很烂，是后天的，但数据结构不合理，那是先天的，两者的杀伤力同样惊人！

３、Row Offset Array

行偏移数组(row offset array) 是一个2-byte entries的块(block),每个项说明对应数据行在页开始的偏移，每行(row)有一个两字节的项。尽管这些字节不会和数据一起存储在行中，它们能影响适应page的行数。行偏移数组揭示了行在页上的逻辑顺序。比如，如果一个表有一个聚集索引，SQL Server按聚集索引键的顺序存放数据。这并不意味着数据是物理按聚集索引键的顺序存放，而是行偏移数组的Slot 0 指向聚集索引键序列的第一行(row),Slot 1 指向第二行,等等。当我们要快速查看实际页的时候，这些行的物理位置可能在页的任何位置。

检查数据页(Exampling Data Pages)

DBCC page命令可以帮我们查询：MSDN文档中中没有提供此命令，微软真的很那个啊。语法为：

DBCC PAGE ({dbid | dbname},filenum,pagenum[,printopt])

其中，最后一个参数可以是0,1,2,3,默认为0,有兴趣的朋友可以比较下这个参数的区别。我们作个示例：

DBCC traceON(3604)
go
--查询testdb数据库的第一个文件的第157页的数据页
DBCC PAGE (testdb,1,157,1);
GO

查询结果如下：

此外，还有更详细的第Ｘ到第X行的数据显示。更多信息，请查看:

http://support.microsoft.com/?scid=kb%3Ben-us%3B83065&x=15&y=13http://blogs.msdn.com/sqlserverstorageengine/archive/2006/12/13/More-undocumented-fun_3A00_-DBCC-IND_2C00_-DBCC-PAGE_2C00_-and-off_2D00_row-columns.aspx

http://support.microsoft.com/?scid=kb%3Ben-us%3B83065&x=8&y=12

查询结果分为四部分：BUFFER、PAGE HEADER、DATA、和OFFSET TABLE(即真实的offset array) ，

注意，要想得到类似上图的查询的明细信息，必须选择打开TRACEON开关，语法为：

DBCC traceON(3604)
GO

关于DBCC TRACEON (Transact-SQL)的更多用法，请参考MSDN
http://msdn.microsoft.com/en-us/library/ms187329.aspx

比如你想得知系统硬件的相关信息，可以通过DBCC traceON(3205)打开跟踪开关。

数据行的结构(the structure of data rows)
一个表的通用结构如下图所示：

其中：状态位A包含一个关于行的位图信息。这个bits有如下含义：

      Bit 0 Versioning information; in SQL Server 2008, it's always 0.
      Bits 1 through 3 Taken as a 3-bit value, 0 indicates a primary record, 1 indicates a forwarded record, 2 indicates a forwarded stub, 3 indicates an index record, 4 indicates a blob fragment, 5 indicates a ghost index record, and 6 indicates a ghost data record.
      Bit 4 Indicates that a NULL bitmap exists; in SQL Server 2008, a NULL bitmap is always present, even if no NULLs are allowed in any column.
      Bit 5 Indicates that variable-length columns exist in the row.
      Bits 6 Indicates that the row contains versionings information.
      Bits 7 Not used in SQL Server 2008.

状态位Ｂ显示了该记录是前一记录的复本？？这句邀月不理解。原文是Only one bit is used in the status Bits B field,indicating that the record is a ghost forwarded record.
下表显示了表数据行的存储信息：

Information	Mnemonic	Size
Status Bits A	TagA	1 byte
Status Bits B (not used in SQL Server 2008)	TagB	1 byte
Fixed-length size	Fsize	2 bytes
Fixed-length data	Fdata	Fsize --4
Number of columns	Ncol	2 bytes
NULL bitmap(1 byte for each column in table; 1 indicates that the corresponding column is NULL)	Nullbits	Ceiling (Ncol / 8)
Number of variable-length columns	VarCount	2 bytes
Variable column offset array	VarOffset	2 * VarCount
Variable-length data	VarData	VarOff[VarCount] -- (fsize + 4 + Ceiling (Ncol / 8) + 2 * VarCount)

有趣的是，当你创建一个表的时候，固定长度的列是先被存储的，比如这样一个语句

CREATE TABLE dbo.Demotable2010(
               int PKID,not null
               emp_fname  varchar(10)   NOT NULL,
               phone      char(12)      NOT NULL,
               job_level  smallint      NOT NULL
);

首先存储的是pkid,再是phone,job_level,最后才是 emp_fname,因为它是可变长度的。

后一篇我们将继续学习固定长度的行和可变长度的行的存储。真累啊！

评论: 0　查看评论　发表评论

编辑推荐：.NET Reflector即将商业化

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

程序物语(七):项目经理预成长

邀月 — Wed, 27 Jan 2010 08:34:00 GMT

阅读: 1082 评论: 3 作者: 邀月发表于 2010-01-27 16:34 原文链接

所有程序物语系列文章：

http://www.cnblogs.com/downmoon/category/226146.html

　　最近，一些汇聚点滴感悟的文章得到了大家的关注，邀月希望得到更多的交流，尤其是指出不足之处，今天，根据自己的体会，我来谈谈项目经理的“初始化”阶段。

　　新人工作一段时间后，或长或短，可能一至两年后，有可能出任项目经理。此时，考验你能力的时候真正来临。项目分很多类，如基础研究项目，大型综合性项目。这里我们选取小的商业应用型项目为例。

　　刚开始，我们是没什么经验的，好在有热情。但这是项目，是一个讲究人与人之间配合的技巧性的活，光靠热情是难以持久的。退一步说，你是能力很强的聪慧之人，什么都拿得起放得下，那你充其量只是个精兵，而不是一个好的管理者。管理者的目标让整个组织的效率更高，管理者是没有那么多时间老是冲锋在前的，请深刻体会这一点。 因此我们得掌握一些基本的“技术”，讲究一些策略，力求避免未做勇士，先做烈士。

　　需要先补的课程是，项目的三要素：时间、成本、范围。

　　第一：时间

　　如果三峡项目做得很漂亮，质量很高，专家也很满意，惟一不足的是项目比预期推迟了两年半，那么这个项目的考评可能从A+会直降到C-甚至D-。因为这样一个大项目群，耽误一天便产生数以亿计的成本损耗。我们的项目虽然小，但道理是相通的。所以在执行项目之前。项目的时间至关重要。

　　客户有个时间表，老板有个预期的时间表，每个项目成员都有个时间表，作为项目经理，必须把这些协调起来，达成一个各方满意的结果、按照利益相关方的优先级别排序。这里有个分析的小技巧：请注意，老板说是下月底完工，你得有两手准备。一方面：alpha版一定要在下月上旬先给老板看下，给他一个初步印象，避免到时心里落差过大，情绪失控，万一有错，也来得及修正。另一方面，不要做得太细太完善，既浪费时间，又不给领导提意见的空间，领导只会怪你不会做事。于是，你得留一些简单的易于完成的小破绽给领导。是不是很委琐？！我相信这样做，对项目组有利。当然，看具体的人，看性格。

　　第二：成本

　　项目花下去多少成本，预算时要心中有数。多大的西瓜多大的秤。这个成本包括时间成本、人力成本、费用成本等。在项目中间要勤计算挣值。这是一个很关键的指标。投入与产出必须有一定的正相关系数关系。“人有多大胆，地有多大产”的教训在我身上太深刻了，记住，什么事都不要拍脑门，项目中没有任何板上钉钉的事，特别在公开会议上，要控制自己的情绪和言行。 有时候，一时不必要的斗气，让项目成员苦不堪言。

　　第三：范围

　　有了时间、成本的到位分析。范围就是一件简单的事了，简单的说，范围就是项目需要完成的程度。时间长、成本允许，可以内外兼修，各环节都做得漂亮，各方满意，自己也挺有成就。这是理想中的理想，基本上在实际中属于空想的范畴。所以，如何控制好范围，而又保持好项目成员的积极性，是一门学问，水很深哪！项目经理的一个基本观念是：项目是独立核算的,项目的考评是本项目完成到什么程度 ，而不是为了别的项目组或者为了下一次项目做了多少。如果这个项目可能为了别的项目组做出一些牺牲或额外努力，请尽量避免！如果必须得做，也需要在项目组会议上言明，为自己项目组争取既得的回报，不一定非得物质的，比如领导的心知肚明，客户的理解和感激等，这些会帮你加分。千万不要偷偷摸摸的干，把项目成员的暗中努力不当回事，“我是雷锋我怕谁”已经不能用来唬人了，这是个讲究科学、兼顾效益的商业社会。

　　有人会问，在这三者冲突的情况下，如何取舍。邀月的建议很明确：先砍功能，也就是范围，把一些能推到项目二期的先往后推，向范围要时间。所以，在项目开始之前，要给项目孵出20%左右的可压缩时间，这个只有项目经理自己清楚，不必言明。

　　最不可取的就是项目经理挥刀自宫，让整个项目组在低成本下高速运行，这样的项目最后成败我们先不说，在项目成员的眼中，你基本上与黄世仁无异，甚至不用等到项目结束，就已经*****了。所以在第一次项目中一定不要让项目成员感觉跟你就是为了体验雪山草地，他们配合你，一是出于利益，二才是看你这个人值不值得跟。都看着你呢。所以，遇到不顺事先忍着，抓重点，回头再总结。这就是前文所说的做人、做事的原则：为什么级别的事情，就得付出什么级别的代价！

　　其实，第一次，不要将成败看的太重，教训要自己书写。有人说，哪怕只打一次仗，一个兵才会淬火成为真正的军人。谁没有第一次呢?做人，要经得起失败，但得明明白白地失败。　

　　有人说程序员的人生有三重境界。第一重、见山是山，见水是水。刚入门的程序员基本只能看到表面的东西，由于各种原因，没法了解更深入。第二重、见山不是山，见水不是水。成长并有经验后，看到的表面现象渐渐有头脑中成型，犹如行军详细地图已经了然于胸。第三重、见山亦是山，见水亦是水。大悟之后，举重若轻，外松内紧，处事看似笨拙，实则暗藏玄机，惜语如金，然字字珠矶。此时，胸中亦有各种框图，然表面内敛以藏拙，见人说人话，见鬼与鬼语，谓之通灵也。

　　要想修炼到气定神闲的第三重境界，那就用心和智慧体验吧！

评论: 3　查看评论　发表评论

编辑推荐：.NET Reflector即将商业化

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

《Microsoft Sql server 2008 Internal》读书笔记--第五章Table(3)

邀月 — Tue, 26 Jan 2010 16:06:00 GMT

阅读: 917 评论: 3 作者: 邀月发表于 2010-01-27 00:06 原文链接

《Microsoft Sql server 2008 Internal》读书笔记--目录索引

在上一篇中，我们主要学习了如何在系统视图中察看我们创建表和索引的元数据信息，今天，我们继续学习数据存储的元数据结构。
数据存储无数据(Data Storage Metadata)

还记得Haep吗？，就是没有聚集索引的表。每一个Heap和索引都在sys.indexes视图中有一行记录，SQL2008中每个表和索引能被存储在多个分区中。sys.Partitions包含一个Row对应于每一个Heap或索引的分区。每一个Heap或索引至少有一(到1000)个分区，即使你没有定义分区结构。因此，sys.indexes与sys.Partitions是一对多的关系，在SQL2008中用了一个词"hobt" (Heap Or B-Tree)来称谓表或索引在一个分区中的子集(subset),所以在sys.partitions中有一列是hobt_id。实际上，hobt_id和partition_id是一一对应关系。这两列的值也完全一样。

示例：

代码

CREATE TABLE dbo.employee(
               emp_lname  varchar(15)   NOT NULL,
               emp_fname  varchar(10)   NOT NULL,
               address    varchar(30)   NOT NULL,
               phone      char(12)      NOT NULL,
               job_level  smallint      NOT NULL
);
go
alter table dbo.employee
add Emp_ID int    identity(1,1)
alter table dbo.employee
add constraint PK_Employee primary key (Emp_ID)
go
SELECT  object_id, name, index_id, type_desc
FROM sys.indexes
WHERE object_id=object_id('dbo.employee');

结果：

每一个分区（无论是一个Heap或者索引）能存储三种类型的行，分别存储在自己特定的页面（pages）中。即in-row data pages（可以理解为规则数据）、row-overflow data pages和LOB data pages。针对于一个特定分区的一个特定的页面被称为allocation unit(分配单元)，每个分区在视图sys.allocation_units中有多个行，因为每个分区我们多个分配单元。总有一个分配单元针对n- row data,也可能有分配单元针对LOB data和row-overflow data,下图展示了这种关系：

查询目录视图 (Querying Catalog Views)

其实前面已经多次应用，这里我们再练习一下sys.allocation_units

代码

SELECT object_name(object_id) AS name,
    partition_id, partition_number AS pnum,  rows,
    allocation_unit_id AS au_id, type_desc as page_type_desc,
    total_pages AS pages
FROM sys.partitions p JOIN sys.allocation_units a
   ON p.partition_id = a.container_id
WHERE object_id=object_id('dbo.employee');

结果如下：

再增加不“规则列”

alter table dbo.Employee
add Desc_Long Nvarchar(4000) null,
Notes text null,
LongVar Nvarchar(max)

结果：

你也可发创建一个或两个索引来测试索引视图，应该注意到仅仅增加一个聚集索引并不会改变sys.allocation_units的行数，但却改变了partition_id 数字，因为创建一个聚集索引的时候表完全被内部重建了 。你可以从经下语句的结果中看到这个差异：

代码

SELECT  convert(char(8),object_name(i.object_id)) AS table_name,
    i.name AS index_name, i.index_id, i.type_desc as index_type,
    partition_id, partition_number AS pnum,  rows,
    allocation_unit_id AS au_id, a.type_desc as page_type_desc,
    total_pages AS pages
FROM sys.indexes i JOIN sys.partitions p
        ON i.object_id = p.object_id AND i.index_id = p.index_id
    JOIN sys.allocation_units a
        ON p.partition_id = a.container_id
WHERE i.object_id=object_id('dbo.employee');

大家可能注意到rows和Pages都是0,那是因为我们还没有插入任何数据。

到目前为止，我们并没有查询关于page的分配信息情况。在SQL2000中sysindexes表包含了三列关于空间分配的信息：first,root和firstIAM,

在SQL2008中这三个列名改为first_page,root_page,和first_iam_page，但只在MSDN未公开的sys.system_allocation_units中可以查到。 而公开的一个视图是sys.allocation_units。看来，微软还是藏了不少压箱货啊！呵呵。

关于更多的目录视图的知识，请看MSDN:

http://msdn.microsoft.com/zh-cn/library/ms174365%28SQL.90%29.aspx

下一节将更深入学习数据页Data Pages

评论: 3　查看评论　发表评论

编辑推荐：.NET Reflector即将商业化

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库