知足常乐，顺其自然
我们在学sqlserver的时候，大多教科书和前辈们都说状态少的字段不要建索引，由此带来的开销还不如不建索引，但是这句话有多少人真的知道，
或者说有多少人真的对此有比较深刻的理解，而不是听别人道听途说。。。这样记得快，忘记的也不慢。。。这篇我来分析一下这句话到底有几个意思。
一：现象
首先我们还是用测试数据来发现问题，我先建立一个Person，有5个字段，建表sql如下：
DROP TABLE dbo.PersonCREATE TABLE Person(ID INT [......]
曾今有件事情让我记忆犹新，那年刚来携程不久，马上就被安排写一个接口，供企鹅公司调用他们员工的差旅信息，然后我就三下五除二的给写好
了，上线之后，大概过了一个月。。。DBA那边报告数据库出现大量锁超时，并且及时根据sql的来源将email发到了我们部门，指出sql读取时间过长，
并且缺少nolock，影响了大量机票订单入库，然后我就拿着sql去生产环境跑了下，22s。。。花擦。。。项目上线时间太久，版本已经不存在了，无法
回滚。。。原本准备撤下接口。。。看了下撤下接口跟加上nolock时间相差不多，最后决定先加上nolock，发布紧急单。。。然后再优[……]
很久以前我们在写sql的时候，最怕的一件事情就是sql莫名奇妙的超级慢，慢的是撸一管子回来，那个小球还在一直转。。。这个着急也只有当事人才
明白，后来听说有个什么“评估执行计划“，后来的后来才明白应该避免表扫描。。。
一：表扫描
1.现象
”表扫描“听起来很简单，不就是一行一行的扫嘛，你要说”执行计划”的话，我也会玩，为了更可观，我build一个表，再插入三行数据，如下图：
上面的Person我是一个索引都没建，然后where一下，看看表扫描是啥样的？？？
果然是看到了万恶的“表扫[……]
说到聚集索引，我想每个码农都明白，但是也有很多像我这样的猥程序员，只能用死记硬背来解决这个问题，什么表中只能建一个聚集索引，
然后又扯到了目录查找来帮助读者记忆。。。。问题就在这里，我们不是学文科，，，不需要去死记硬背，，，我们需要的就是能看到在眼里面的
真实东西。。。。。我们都喜欢聚集索引，因为它能够把无序的堆表记录变成有序，还玩起了B树。。。这样就把复杂度从N降低到了LogMN。。。
这样的话逻辑读，物理读就下来了。
一：现象
1：无索引的情况
还是老规矩，看个例子感受下，首先我有一个Product表，里面没有任何索引，如下图：
&nbs[……]
RavenDB是一个在.NET下的文档型数据库，它具有高扩展性，支持MapReduce，提供RESTful的接口。同时它又支持ACID的事务。下面是一个RavenDB的系列教程，从入门到精通。
今天研发中心办年会，晚上就是各自部门聚餐了，我个人喜欢喝干红，在干红中你可以体味到那种酸甜苦辣。。。人生何尝不是这样呢？？？正好
ceo从美国带了干红回来，然后我就顺道开心的过了把瘾。。。。一个字。。。爽。。。。喝着有点多。。。到现在头还疼。。。。回来地铁上想这个
周末忙着找房子，书一点都没看，也没在博客上接着忽悠，想起了上篇博客有个哥们说普及普及DBCC，虽然有点迷迷糊糊的。。。看能不能写出点新
花样。。。。不管学什么语言，还是数据库，你得看的比人家深一层。。。最可悲的就是停留的在表层，这样每次版[……]
李志强 &nb[……]
1. 还是使用原始的person表，插入6条数据，由于是4000字节，所以两条数据就是一个数据页，如下图：
1 DROP TABLE dbo.Person2 CREATE TABLE Person(ID INT IDENTITY,NAME CHAR(4000) DEFAULT 'aaaaa')3 --插入6条数据，刚好3个数据页4 INSERT INTO dbo.Person [......]