我偶然发现了一个日志数据库，该数据库旨在保存过去60天的数据并提供索引，以便快速进行数据分析。
数据库由26GB数据空间和10GB索引存储组成，在分析了我认为的指数之后，大约50％从未使用过或效率低下，因此我设置执行以下更改：
OLD
IX MODE SIZE
------------------------------------------------------------------------
PK_PerformanceData CLUSTERED 26,09 GB
IX_PerformanceData_Controller NON_CLUSTERED 2,07 GB
IX_PerformanceData_AppName NON_CLUSTERED 1,89 GB
IX_PerformanceData_ControllerMethod NON_CLUSTERED 1,73 GB
IX_PerformanceData_StartTime NON_CLUSTERED 1,35 GB
IX_PerformanceData_AppHost NON_CLUSTERED 1,30 GB
IX_PerformanceData_LogTime NON_CLUSTERED 0,79 GB
IX_PerformanceData_StatusCode NON_CLUSTERED 0,57 GB
IX_PerformanceData_ProcessException NON_CLUSTERED 0,54 GB
新
IX MODE SIZE
---------------------------------------------------------------------
CIX_PerformanceData_AppName_Controller CLUSTERED 26,99 GB
IX_PerformanceData_LogTime NON-CLUSTERED 3,62 GB
IX_PerformanceData_ProvId NON-CLUSTERED 3,61 GB
PK_PerformanceData NON-CLUSTERED 3,57 GB
IX_PerformanceData_ProcessException NON-CLUSTERED 3,34 GB
列：
VARCHAR(n) = Controller, AppName, ControllerMethod, AppHost
DATETIME = StartTime, LogTime
SMALLINT = StatusCode
BIGINT = Id, ProvId
BIT = ProcessException
我将字符串类型索引更改为单个CLUSTERED索引（可能有20种变化），因为我认为这会产生一个漂亮而花花公子的小B-TREE索引。此外，我删除了一些对期刊没有任何用处的指数。
在索引存储已占数据量的大约40％之前，我怀疑它降至10％以下。不幸的是，它们变得不合理地大，看起来每个索引都指向聚簇字符串文字，因此跳到大约52％的数据空间。
即使聚集索引的工作速度也快得多，因为空间消耗非常垃圾。任何人都可以解释这个观察结果，有没有最佳实践来解决我的问题？
答案 0 :(得分：1)
当您有聚簇索引时，它将成为引用该表的所有索引的叶节点上的指针。这可以帮助提高性能，如果您要检索的数据存储在聚簇索引中，则无需实际转到表中即可获取它。
最佳做法取决于您的需求。索引以磁盘空间为代价提高了读取性能。当您开始构建包含数据的索引时，例如使用include的覆盖索引，存储量会随着读取的性能而显着提高。我认为索引总是慢写，但我可能错了。
在我看来，最佳做法是找到适合您的要求和预算的余额。