SQL语言艺术(五)了如指掌：理解物理实现

本章探讨表中数据不同的存储方式，以及特殊的物理实现对性能的影响

尽管数据库的物理结构和SQL没有直接的关系，但如何使用SQL却受到这些底层结构的影响

在优化数据的物理布局常碰到两个冲突的目标，一个目标是尽量以紧凑的方式存储数据，这有助于查询尽快找到所有数据。另一个目标是尽量将数据分散存储，以便多个线程可以并发写入，不会造成资源争用而互相妨碍

索引

数据的物理布局与数据的特征及预期用途密切相关，所以表和索引的物理设计，需要数据库管理员和开发者合作，根据业务需求，结合既有DBMS的特性，使物理设计尽可能最佳

当待查的键值指向大量记录时，通常效率较高的做法是从头到尾扫描并忽略索引，当一个字段包含较多重复值时，即低区别度，为该字段建索引没什么用。作为复合索引的第一个字段，也没有必要单独加索引，无论如何都不需要对一个字段建立两个索引。即使没有完整的键值，只要确保前面几个字节足以分辨数据，就能高效地搜索常见的树状或层状索引

当索引已含有其它信息时，就没必要再访问它所指的原始数据，在索引中加入额外的字段，就能提高某个频繁运行的查询的速度，这是因为查询所需要的数据可以全部从索引中获取，而完全不必再访问原始数据源

分区

分区可以提高并发性和并行性，从而提高了系统的可伸缩性

循环分区是一种不受数据影响的内部机制，一个表存储在多个分区中，数据会按照某方法循环地加载到各个分区，以保持磁盘I/O操作的平衡。循环分区可以看做是随意散布数据的机制，它并不根据实际的逻辑数据相关性来分组数据

数据驱动分区是根据一个或多个字段的值来定义分区，每条记录插入相应的分区。多数非常大的表是因为它包含了历史数据，最常查询的是那些较新的数据，我们可以根据日期进行分区，把常用数据和不常用数据分别放在不同的分区中

真正的分区要求逻辑上有一个单独的表，即所谓的分区视图(partitioned views)，它具有能被其它表参照的真正主键。此外，指定一个或多个字段作为分区键(partition key)，该键决定记录将被保存在哪个分区。这样，我们就能利用分区视图的所有优势，即在操作表时具有透明性，而且可以把保证数据完整性的任务交回给DBMS。更重要的是由于DBMS核心知道分区，从而知道如何利用这种物理结构进行优化。但如果DBMS不支持分区视图，处理起来就会非常复杂

分区的具体实现可以采用多种方式，每种方法分别适合不同的情况

哈希分区(hash-partitioning)

对分区键进行hash运算，根据结果分区。完全基于hash运算的结果，完全不考虑数据值的分布。哈希分区能保证根据分区键快速找到记录，但对范围搜索没有优势，因为hash函数会将连续的键值转换为非连续的hash值，再根据hash值确定物理地址

范围分区(range-partitioning)
根据连续数据的范围对数据进行分组。范围分区非常适合处理历史性数据，同之前讨论的分区视图概念最为接近

列表分区(list-partitioning)
最具手工风格的分区类型，适合定制解决方案，必须明确指定分区键的可能取值以及每种键值对应的分区

分区内部还可以建立子分区，例如在一个范围分区内建立hash分区

数据驱动分区能将一个表中的数据分散到多个独立分区，但这并不能解决并发问题。如果大部分分区都无人访问，存储最新数据的分区访问却过于集中，这样的分区方式显然不够理想。对分区表进行查询，当数据分区键均匀分布时，收益最大

分区是把双刃剑，一方面，它通过分区键将数据聚集在一起，利于高速检索。另一方面，对于并发执行的操作，分散数据可以避免访问过于集中的问题。但在实践中，这两个目标可能彼此矛盾同，到底用数据分区来分散数据还是聚集数据，完全取决于需求，所以首先要明白需要解决的主要问题是什么，并针对主要问题设计分区。而且两方面得失都要检查，看结果是否能够接受。理想的情况是为select设计的数据聚焦方式，与为insert设计的数据散布方式是一致的，只可惜这并不常见