Question

我有一个包含大约五个可能索引列的数据库，所有索引列都以不同方式有用。我们称之为系统，源，热，时间和行。一起使用System和Row将创建一个唯一键，如果按System-Row排序，数据库也将按五个索引变量的任意组合进行排序（按照我在上面列出的顺序）。

我的问题是我使用了这些列的所有组合：有时我想将每个System-Row加入到下一个System-（Row + 1），有时我想要GROUP-WHERE by System-Source-Heat，有时候我想查看System-Source WHERE Time在特定窗口中的所有条目等。

基本上，我想要一个索引结构，其功能类似于这五个索引的每个可能的排列（当然是以正确的顺序），而不是实际进行每个排列（尽管我愿意在必要时这样做）。我正在做统计/分析，而不是传统的数据库工作，因此索引的大小和创建/更新它的速度不是问题;我只关心加速我的即兴查询，因为我倾向于思考它们，运行它们，等待5-10分钟，然后再也不再使用它们。因此，我主要担心的是将“等待5-10分钟”缩短为更像“等待1-2分钟”。

我的排序数据看起来像这样：

Sys So H Ti R
1   1  0 .1 1
1   1  1 .2 2
1   1  1 .3 3
1   1  2 .3 4
1   2  0 .5 5
1   2  0 .6 6
1   2  1 .8 7
1   2  2 .8 8

编辑：它可能会简化一些事情，系统几乎总是需要作为第一列包含在排序顺序中的任何其他4列中。

Answer 1

如果您仅关注SELECT速度而不关心INSERT，那么您可以将所有组合实现为INDEXED视图。您只需要原始表的24倍存储空间，制作一个表和23个INDEXED VIEW，每个5列。

e.g。

create table data (
    id int identity primary key clustered,
    sys int,
    so int,
    h float,
    ti datetime,
    r int);
GO
create view dbo.data_v1 with schemabinding as
    select sys, so, h, ti, r
    from dbo.data;
GO
create unique clustered index cix_data_v1 on data_v1(sys, h, ti, r, so)
GO
create view dbo.data_v2 with schemabinding as
    select sys, so, h, ti, r
    from dbo.data;
GO
create unique clustered index cix_data_v2 on data_v2(sys, ti, r, so, h)
GO

-- and so on and so forth, keeping "sys" anchored at the front

请注意，但是 Q. Why isn't my indexed view being picked up by the query optimizer for use in the query plan?（在链接文章中搜索）

<小时/> 如果空间是一个问题，那么下一个最好的事情是在4列中的每一列上创建单独的索引，以系统引导，即（sys，ti），（sys，r）等。如果这将有助于它们可以一起使用查询，否则它将恢复为全表扫描。

Answer 2

很抱歉花了一些时间才回到这里，我不得不在其他地方工作几周。无论如何，在尝试了很多东西（包括这里建议的所有内容，甚至是蛮力“为每个排列方法制作索引”）之后，我还没有找到任何可以显着提高性能的索引方法。

但是，我找到了一个替代的非索引解决方案：只选择我感兴趣的行和列到中间表中，然后使用那些而不是完整的表（所以我使用大约5密耳的行6个col而不是30 mil的35 cols）。初始选择和表创建有点慢，但之后的步骤要快得多，我实际上节省了时间，即使我只运行一次（考虑到我改变事物的频率，它通常不止一次）。

我怀疑这种巨大改进的原因对于大多数SQL用户来说是显而易见的（可能是关于页面文件大小的东西），如果是这样，我会道歉。我唯一的理由是，我是一名统计学家，试图教我自己如何做到这一点，虽然我很擅长做我想做的事情（最终），但我对的机制的理解怎么它正在做的是令人沮丧地接近“它是一个神奇的黑盒子，不要担心它。”

索引结构，以最大化索引列的任何组合的速度

2 个答案: