Question

我正在使用Entity Framework 6.0重新编写C＃4.5 / SQL2012中的“票证应用程序”。之前的开发是在没有任何额外索引的情况下匆忙完成的。该应用程序工作正常，但我希望v2'应该是'。在我再往前走之前，我需要'垫肩'和单词--yea .. ur do''a'right--☺

在其他应用程序中，我的主键始终是我的ID（int）列，它碰巧被聚集，因为它似乎是SQL的默认值。之后我刚刚添加了一个非聚集的列，当我感觉到它时。

所以简而言之.. 表格票证，包含ID，类型（事件或请求），状态（打开，暂停，已解决，...），主题等。带有ID和名称的表格受让人 带有ticketId和assigneeId的表 junctionTicketAssignee

票据＆amp;受让人关系是多对多的。大部分时间我只会通过它的身份证获取机票或受让人。在故障单概述中，默认情况下会列出状态为“打开”的票证。 “按住”按日期（desc）排序，分配给当前受让人。

因此我现在有以下索引：

in 'ticket'
PK_ticket = PRIMARY KEY NON-CLUSTERED (ticket.id ASC)
IX_ticket = UNIQUE CLUSTERED (ticket.id ASC, ticket.dateCreate DESC, status ASC, type ASC)
IX_type = NON-UNIQUE NON-CLUSTERED (ticket.type)
IX_status = NON-UNIQUE NON-CLUSTERED (ticket.status)

in 'assignee'
PK_assignee = PRIMARY KEY CLUSTERED (assignee.id ASC)

in 'junctionTicketAssignee'
PK_junctionTicketAssignee = PRIMARY KEY CLUSTERED (ticketId ASC, assigneeId ASC)
FK_Assignee = PRIMARY KEY assignee.id -> FOREIGN KEY junctionTicketAssignee.assigneeId
FK_Ticket = PRIMARY KEY ticket.id -> FOREIGN KEY junctionTicketAssignee.ticketId

我把它与我对索引的基本知识结合起来。我是在正确的轨道上吗？

Answer 1

如果您的索引策略是正确的，有很多不同的方法可以解决。

首先在互联网上找到一篇关于索引的文章，并阅读不同类型的索引。

然后在实际执行计划中运行一些查询，并查看输出。然后找一篇关于执行计划的文章并快速扫描一下。

有时执行计划会暗示缺少索引，并尝试以正确的方向刺激你。

玩得开心。是的 - 你走在正确的轨道上。

在选择正确的SQL索引时需要建议

1 个答案: