我正在使用EntityFramework6.0在C# 4.5 / SQL2012中重新制作我的“票证应用程序”。之前的开发是在没有任何额外索引的情况下仓促进行的。该应用程序运行良好,但我希望v2是‘它应该是’。在我走得更远之前,我需要“肩膀上的垫子”和单词--是的.你的权利--☺
在其他应用程序中,我的主键总是ID (int)列,它碰巧是集群的,因为它似乎是SQL的缺省值。之后,我只添加了一个“当我想要的时候”的非聚集列。
所以简而言之..。带有id、类型(事件或请求)、状态(打开、搁置、解决、.)、主题等的表.带有id的表junctionTicketAssignee受让人和带有ticketId和assigneeId的表ticketId
门票与受让人的关系是多对多的。大多数情况下,我只需根据票证的ID获取票证或受让人。在票证概述中,默认情况下,票证是按日期(desc)排序的状态'open‘&’on-驻点‘列出给当前受让人的。
为此,我现在有以下索引:
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我已经把这些和我对索引的基本知识结合起来了。我在正确的轨道上吗?
发布于 2014-02-06 16:28:52
有很多不同的方法来计算你的索引策略是否正确。
首先,在互联网上找到一篇关于索引的文章,并阅读不同类型的可用索引。
然后,使用实际的执行计划运行一些查询,并查看输出。然后找一篇关于执行计划的文章,然后快速浏览一下。
有时,执行计划会提示缺少索引,并试图将您推向正确的方向。
玩得开心。是的-你在正确的轨道上。
https://stackoverflow.com/questions/21608134
复制相似问题