摘要

我計劃存儲在SQL Azure數據庫與下面的模式牌照名單：建議先進性能調整 - 除了基本的索引

架構

CREATE TABLE [dbo].[events](
    [id] [bigint] IDENTITY(1,1) NOT NULL, 
    [dateTimeCreated] [datetime] NOT NULL, 
    [registration] [varchar](14) NOT NULL 
) ON [PRIMARY] 

GO 

SET ANSI_PADDING OFF 
GO 

ALTER TABLE [dbo].[events] ADD CONSTRAINT [DF_events_dateTimeCreated] DEFAULT (getdate()) FOR [dateTimeCreated] 
GO

我只能想到運行以下一個查詢： - 在給定的日期/時間範圍內搜索註冊

到目前爲止我只能想到建立一個非聚集索引agaisnt dateTimeCreated和登記

問題

有可能最終會被數百萬行的10的。 *當行數最終確實增加很多時，有哪些選項（天藍色特定與否）可以提高性能？ *有關於查詢性能如何降低給定行數的指南？

來源

2015-02-10 David Hawkins

您應該創建一個集羣索引dateTimeCreated。 registration列也應該被編入索引，但它是否（以及如何）應該被編入索引取決於數據：您的registration對它們有一些疑問或它們是隨機的嗎？

背後Clustered Indexes核心思想：

在一個表中的數據行的排序順序存儲的唯一時間是當表包含聚簇索引。

這意味着，當你做對即聚集的列的搜索和值有一定的訂單能夠語義（您dateTimeCreated列）你取的情形產生正確的數據上升顯著。（SQL Server沒有獲取 - 儘可能多的 - 表頁，收集必要的數據。）

另外：（MSDN documentation link）無聚集指標

微軟Azure SQL數據庫不支持表。一個表格必須有一個聚集索引。如果創建的表沒有聚集約束，則必須在表上允許插入操作之前創建聚簇索引。

來源

2015-02-10 17:06:14

我會做ID的PK（和聚簇索引）

爲什麼BIGINT？
int最多可達40億（如果使用否定值，則可達80億）
不僅僅是更少的磁盤空間，還有更多的記錄被緩存在相同的內存量中。

COUNT（*）將n階
兩倍多的記錄需要花兩倍的計算

至於其他的欄目，如果你要搜索或排序它們創建索引。

來源

2015-02-10 18:13:02 Paparazzi

好點我會將其更改爲int謝謝 – 2015-02-10 18:29:45

我同意你的bigint建議，但是......您建議在pkey ID列上使用聚簇索引來加速'count'操作？這是SQL Server的默認設置，在這種情況下根本沒有用。 OP（@DavidHawkins）清楚地詢問'dateTimeCreated'和'registration'列的搜索性能。應該對這些列進行聚類，以顯着減少頁面抓取，從而提高性能。 – 2015-02-10 18:41:59

@PaulSasik好的，這是你的意見和你的答案。我會每次都使用身份證作爲PK（或者甚至沒有身份證）。我懷疑目的是爲了FK。對於insert中的一個，我可以獲取用於填充FK表的標識的值。取回日期時間的價值並不容易。並且getdate（）不保證是唯一的。 – Paparazzi 2015-02-10 18:49:52

建議先進性能調整 - 除了基本的索引

摘要

架構

問題

回答

相關問題