SQLServer内核架构剖析

我们知道，数据页包含数据行。索引页包含索引行。数据行就由行管理器来控制。而索引行，由索引管理器来负责。

而单行上的检索、修改、执行，又被事务管理器和锁管理器影响着。事务，有显性事务和隐性事务两种。而锁，又有共享锁、排它锁、更新锁、意向锁。而锁，还分为行锁、页锁、表锁、数据库锁。而锁，又有死锁的可能性。锁的不同，加上事务的影响，这个行是否能读、能修改，能怎样的读（读一致还是脏读），是等待事务和锁，还是可以进行，就受了很多影响。因为一张数据页上放的行是有限的，尤其还有填充度的影响（如填充度为80%，就这个数据页面只能填充80%就必须分页，以防以后有数据插入的时候，就非常影响数据插页，这也是性能影响比较大，尤其在插入数据比较多的情况下）。SQLSERVER的一张数据页默认是64K，除去填充度和数据头，也没有多少可存储的数据了。这就是为了关系型数据库都劝阻大家要小表大数据。也就是说，列要少，列要短，频繁访问的列要在前。数据可以海量。如果行长了，你想要检索和更新多少数据页，这需要多少页面调度，面临着页面失效和锁机制的影响。而且，大文本和可变行，都是指针存储，需要跳转查找，更浪费了不少时间。

而索引管理器，最主要在维护着索引B树。没有索引页，我们就要做全表扫描了，那需要载入多少数据页，而且还要逐行扫描，如果遇上事务和更新锁，就更有问题。所以，索引是非常重要的。而一个表，可以建立很多索引。索引，能直接找到所需要的行，而无须全表扫描。但是，你的索引如果仅仅是男女，或者你的索引涉及到可变行，都对索引不利。索引，不宜建立多。否则维护索引页的成本和消耗也非常多。索引页更要涉及到插页、拆页，频繁改动涉及到索引的字段，会让索引页剧烈变动，尤其数据量越大影响越大。我就不在这里讲解如何利用索引优化SQL了，否则一本书也讲不完。