小编Zai*_*rja的帖子

我有一个包含 20 列和大约 600,000 条记录的表。最大行大小仅为 100 字节左右。该表每隔几天重新填充一次，但记录数保持大致相同。

现在只有一个聚集索引：主键的 int 标识列。

我有几个依赖于这个表的查询和视图，通常需要 5-10 秒来执行。当我简单地选择所有记录 ( select * from myTable) 时，检索所有结果大约需要 4 秒钟。

我一直无法找到在 SQL Server 中选择 500,000 条记录的相关基准。这个时间是典型的吗？

这是我在表上执行的典型查询：

select  CO.Company
    ,CO.Location
    ,CO.Account
    ,CO.SalesRoute
    ,CO.Employee
    ,CO.ProductType
    ,CO.Item
    ,CO.LoadJDate
    ,CO.CommissionRate
    ,SUM(CO.[Extended Sales Price]) AS Sales_Dollars
    ,SUM(CO.[Delivered Qty]) AS Quantity
from    dbo.Commissions_Output CO
where   CO.[Extended Sales Price] <> 0
group by    CO.Company
        ,CO.Location
        ,CO.Account
        ,CO.SalesRoute
        ,CO.Employee
        ,CO.ProductType
        ,CO.Item
        ,CO.LoadJDate
        ,CO.CommissionRate

当我在表上至少有一个非聚集索引时，我得到以下结果：

扫描计数 18，逻辑读取 18372；CPU 时间 = 24818 毫秒，已用时间 = 8614 毫秒。 …

我们正在 SQL Server 中设计一个数据库来处理销售佣金。当前模式的图表如下所示：

这个项目只有我们几个人，我们的老板把这个设计交给了我们。我是一个新手，但我很担心这个Slot表，因为我们似乎正在朝着 EAV 模型前进，而且我认为我们的团队没有足够的经验来克服这些陷阱。

ASlot可以是公司、地点、地区、路线或位置（基于其SlotType）。我们有这些实体的表格，但管理层希望“灵活”地为彼此分配插槽 ( SlotHierarchy)。我不会陷入适用于每个槽位、槽位类型、槽位级别、槽位级别类型和员工职位分配的混乱的生效日期。所有生效日期都是因为管理层想要控制每一件作品。

计划是将Employeeget 分配到位置槽 ( SlotPositionAssignment)，然后可以将其分配到位置、路线或区域槽。一个职位在给定时间只能分配一名员工。不过，一个位置可以分配给任意数量的插槽。

因此，我们可能有PositionType“销售员”和SlotDesc“销售 1”和“销售 2”两个职位（插槽），每个职位都分配了一名员工。这两个职位可以分配到多个路线、地区、地点或公司时段。这SlotHierarchy有助于解决这个问题。

我的担忧：
恐怕我们可能会因此而自诩。我不介意编写额外的应用程序逻辑，但这似乎“太聪明了”。直言不讳并使用映射到现实生活中的表格而不是将它们隐藏为“插槽”不是更有意义吗？

我想取消将职位作为插槽并使用Position表格，或者可能只是PositionType在我们失去报告公司特定职位的能力时使用，例如“Rt 1 Manager”。当我提出这个问题时，我被告知它不会“灵活”，这就是它的结束。

有没有更好的方法来组织这个，或者做出一些妥协，或者我什么都不担心？我是新手，不介意犯错，只要我知道为什么我错了。