SQL Server里用空间多占点，换索引查询速度提升的那些事儿

SQL Server里用空间多占点，换索引查询速度提升的那些事儿

这事儿说白了，就是咱们在数据库里做的一个非常常见的交易：用硬盘上那点不值钱的空间，去换CPU和内存那点宝贵的时间，硬盘空间现在多便宜啊，加个一块两块的TB硬盘花不了太多钱，但是用户的等待时间、系统的响应速度，那可是真金白银，用户体验不好，客户可能就走了，数据库管理员和开发人员们就琢磨出了各种“浪费”空间的方法,让查询跑得飞快。

最典型的一个例子就是索引，索引就是个“路标”或者说是“书的目录”，没有索引的时候，数据库要找一条数据，就得把整张表从头到尾翻一遍，这叫“全表扫描”，表小的时候还行，要是表里有几百万、几千万甚至上亿条数据，那查询速度可就慢得吓人了，这时候，你建一个索引，就相当于给这本厚厚的书做了一个详细的目录，数据库不用再一页一页去翻，直接查目录，唰的一下就定位到数据在哪一页了,速度自然就上来了。

这个“目录”本身也是要占地方的，你想想，一本书的目录是不是也占了好几页纸？数据库的索引也一样，它需要额外的磁盘空间来存储，你建的索引越多、越复杂，占的空间就越大，这就是典型的“用空间换时间”，你愿意多花点硬盘空间来存这些索引,查询的时候就能省下大量的时间。

具体有哪些“浪费”空间的方法能提升速度呢？

多建几个索引，覆盖不同的查询路子

（来源：基于SQL Server索引设计的基本原则）一张表可不是只有一个用途，有的查询按名字找，有的查询按创建时间找，还有的查询按地区和状态一起找，如果你只在“名字”上建了索引，那么按“时间”查询的语句就享受不到好处了,还是得慢吞吞地全表扫描。

常见的做法是针对那些经常被用在查询条件（WHERE子句）里的列，以及用来排序（ORDER BY）和分组（GROUP BY）的列，分别建立索引，用户表除了给“用户名”建索引，可能还得给“注册时间”、“最后登录IP”等常用查询条件都建上，这样，不管用户从哪个角度查，数据库都有现成的“小路”可以抄近道，代价就是，这张表的总空间大小，可能数据本身占一半,索引占了另一半甚至更多。

建“包含列”索引，让查询彻底不回头

（来源：SQL Server中引入的包含列索引特性）这是个更高级一点的技巧，普通的索引就像目录，只告诉你数据在哪一页，数据库通过索引找到数据的位置后，还得回到真正的数据页去把其他列的信息取出来，这个“回表”的操作也是要花时间的。

SQL Server允许你创建一种叫“包含列”（INCLUDE）的索引，简单说，就是在这个“目录”里，不仅记录了关键字的页码，还把一些常用的其他列的信息也直接抄在这个“目录”后面，你有一个查询是“查找某个城市的所有用户，并返回他们的姓名和电话”，你可以创建一个在“城市”列上的索引，然后把“姓名”和“电话”这两个列作为“包含列”加进去。

这样一来，数据库只需要查这个索引就齐活了，索引里既有查询条件（城市），又有需要返回的结果（姓名、电话），它根本不需要再跑回原始的数据页去拿数据了，一次索引查找，所有数据都拿到了，速度非常快，这么干的代价就是索引变得更“胖”了，因为它额外携带了更多列的信息,占用的空间自然就更大了。

使用“索引视图”，预先把复杂结果存起来

（来源：SQL Server的索引视图功能）有时候查询特别复杂，不是简单查一张表，可能涉及多张表的连接（JOIN），还有分组汇总（GROUP BY）的计算，每次执行这个查询，数据库都要吭哧吭哧地现场连接、现场计算,非常耗时。

对于这种雷打不动、每天要跑无数次的复杂查询，SQL Server提供了一个“大杀器”——索引视图，你可以先创建一个普通的视图，把这个复杂的查询逻辑定义好，在这个视图上创建一个唯一的聚集索引，一旦你创建了这个索引，SQL Server就不再是每次查询时临时计算了，它会像对待一张真实的表一样,把视图的查询结果实实在在地存储起来。

以后你再查询这个视图，数据库就直接从存储好的结果里读取数据，速度快得就像查一张简单的表，这相当于你用空间把复杂的计算过程给“买断”了，代价是什么呢？首先是存储这个结果集需要空间，一旦底层的基础表数据有变动（比如插入、更新、删除），SQL Server必须自动去更新这个索引视图里的数据，以保证数据一致，这会增加数据修改操作的开销，所以这招一般用在那些查询非常频繁,但底层数据又不经常变动的场景。

故意让数据“冗余”一点

（来源：数据库设计中反规范化技术的实践）按照教科书上规范的数据库设计，数据不应该重复存储，但有时候，为了速度，我们不得不故意“犯规”，有一张订单主表，一张订单明细表，如果要查询“某个用户的所有订单总金额”，就得把两张表连接起来,然后按用户分组求和。

如果这个查询压力非常大，你可能会考虑在订单主表里直接加一个“订单总金额”的字段，每次新增或删除明细时，用触发器或者应用程序同时更新主表里的这个总金额字段，这样，查询的时候直接查主表就行了，省去了连接和现场计算的巨大开销，这就是用空间的冗余（重复存储了总金额）换取了查询时间的极致优化，这带来了数据一致性的风险,需要小心维护。

总结一下

在SQL Server里，这种“空间换时间”的戏码天天都在上演，核心思想就是认清现实：硬盘空间是廉价的，而用户体验和系统性能是昂贵的，通过合理地多建索引、使用包含列、甚至采用索引视图和适当的反规范化手段，我们可以大幅提升关键查询的速度，这一切都不是免费的，需要DBA和开发者仔细权衡，找到空间消耗和性能提升之间的最佳平衡点，避免过度设计，毕竟维护这些“捷径”本身也是需要成本的。