选择最佳的散列大小

所选择的 UltraLite 缺省最大散列大小（4 字节）适合于大多数部署。您可以增加大小以包含包括行 ID 在内的更多数据。但是，此更改可能增加索引的大小并将其分段存储在多个页间。结果，这种更改可能增加数据库的大小。增加最大散列大小的影响取决于表中的行数：例如，如果只有几行，大的索引散列键将仍适合索引页。在这种情况下，不会产生索引碎片。

当选择最佳散列大小时，应考虑数据类型、行数据和数据库的大小（尤其是表包含许多行时）。

确定您是否选择了最佳散列大小的唯一方法是在目标设备上针对 UltraLite 客户端应用程序运行基准测试。除了数据库大小自身的更改外，您需要观察不同散列大小如何影响应用程序和查询性能。

数据类型

如果要散列列中的全部值，请注意下表中各数据类型所需的大小。仅当 UltraLite 确实需要时，它才使用最大散列大小，并且从不超过指定的最大散列大小。如果列类型不使用全字节限制，UltraLite 始终使用较小的散列大小。

数据类型	用于散列整个值的字节
FLOAT、DOUBLE 和 REAL	不散列。
BIT 和 TINYINT	1
SMALL INT 和 SHORT	2
INTEGER、LONG 和 DATE	4
DATETIME、TIME、TIMESTAMP 和 BIG	8
CHAR 和 VARCHAR	若要散列整个字符串，最大散列大小（以字节为单位）必须与声明的列大小相匹配。在 UTF-8 编码的数据库中，始终将声明的大小乘以因子 2，但不超过允许的最大 32 字节。例如，如果在非 UTF-8 编码的数据库中声明一个列为 VARCHAR(10)，则所需大小为 10 字节。但是，如果在 UTF-8 编码的数据库中声明同样的列，则用于散列整个字符串的大小为 20 字节。
BINARY	最大散列大小（以字节为单位）必须与声明的列大小相匹配。例如，如果声明一个列为 BINARY(30)，则所需大小为 30 字节。
UUID	16

例如，如果为分别声明为 INTEGER 和 BINARY (20) 的两列复合索引设置 6 字节的最大散列大小，则基于数据类型大小需求，将发生以下情况：

散列 INTEGER 列中行的整个值并将其存储在索引中，因为散列整型数据只需要 4 字节。
只散列 BINARY 列的前 2 个字节并将其存储在索引中，因为 INTEGER 列使用了前 4 个字节。如果剩余的 2 字节不能散列 BINARY 列的适当数据量，则增加最大散列大小。

行数据

存储在数据库中的数据的行值也会影响散列索引的有效性。

例如，如果有一个在给定的列条目之间共享的公用前缀，则选择只能散列前缀的大小可能会使散列无效。在这种情况下，需要选择一个可确保不仅只能散列公共前缀的大小。如果公共前缀很长，应考虑根本不散列值。

如果非唯一索引存储许多重复值，并且 UltraLite 无法散列整个值，则散列可能无法提高性能。

数据库大小

每个索引页都具有一些固定的开销，但实际的索引条目使用了大部分的页空间。较大的散列大小表明每个索引条目较大，这意味着一页上能够容纳的条目较少。对于大表，具有大散列的索引比具有小散列或无散列的索引使用更多的页。需要更多页会增大数据库的大小，并降低性能。因为高速缓存只能保存固定数量的页面从而导致 UltraLite 交换页面，所以通常会出现性能降低。

下表给出了散列的大小如何影响存储索引中数据所需的页数的近似值。

表	页面大小	散列大小	条目数	所需页数
表 A	4 KB	0	1200	3 页
表 B	4 KB	32 个字节	116	3 页
表 C	4 KB	32 个字节	1200 个条目	11 页

另请参见

使用DocCommentXchange 讨论此页。