我對本質上是一個日誌表的集羣PK,顯然不應該聚集。如何使生產數據庫上的羣集PK非羣集?
當我這樣做:
alter table mytable drop constraint pk_mytable
它需要對數據庫副本的絕對年代在我的機器(5+分鐘)上,以便將不可避免而不引起超時或超時本身對生產DB工作。
爲什麼沒有這種瞬間操作?它在做什麼?
有沒有辦法實現這個沒有我的網站離線?
更新:該表有10幾百萬行,和幾個5?其他非聚集索引
感謝
我對本質上是一個日誌表的集羣PK,顯然不應該聚集。如何使生產數據庫上的羣集PK非羣集?
當我這樣做:
alter table mytable drop constraint pk_mytable
它需要對數據庫副本的絕對年代在我的機器(5+分鐘)上,以便將不可避免而不引起超時或超時本身對生產DB工作。
爲什麼沒有這種瞬間操作?它在做什麼?
有沒有辦法實現這個沒有我的網站離線?
更新:該表有10幾百萬行,和幾個5?其他非聚集索引
感謝
聚簇索引的物理設定的MS SQL Server(我以爲是你使用的是什麼),在磁盤上記錄的順序。所以這會導致整個IO堆,因爲它會重寫整個表。
如果不指定聚集索引,我相信將SQL反正爲您創建一個,因爲它使用的是交叉參考指標,而不必從表中讀取記錄。
SQL不會爲您創建一個,您將留下所謂的堆。請參閱http://www.brentozar.com/blitz/heaps-tables-without-primary-key-clustered-index/ –
那Nigel知道他的東西:) – adambird
我不知道你爲什麼要做到這一點,但這裏是最好的方法:
我懷疑,當您試圖刪除主鍵時,表上存在某種形式的鎖定,一般來說,它實際上是每個表上都有聚簇索引的好習慣。這實際上加快了刪除和更新等操作。除了你的桌子是一個日誌桌這個事實之外,你想放棄這個的理由是什麼?同樣,一般來說,如果我所討論的表是一些需要併發/大插入快速的登臺表的形式,我纔會傾向於堆,因此我會問這個問題,是否有性能問題,即量化插入到表時,另一種可行的理由想刪除聚集主鍵是集羣的關鍵是錯誤的,即廣,易揮發,而不是單調遞增的,除非你有沒有影響固態基於I/O子系統通過隨機I/O,就像基於旋轉磁盤的存儲一樣。 Nigels在他所說的內容中正確,這是一個例外是SQL Azure,這需要**每個**表都有一個聚集索引,他們的HA體系結構依賴於此。
嗨安德魯,跌幅限制應該是相當快速。但是,您不會告訴我們密鑰的組成或表中包含的行數。我不認爲放棄約束不會使SQL重寫表,所以我認爲其他事情正在發生。桌子上有其他索引嗎?你可以放下他們,然後重新創建?我剛創建了一個1表。700萬行,需要5分鐘才能在2個字段上創建聚集的PK,但是需要0秒才能刪除該約束,只有4個用於刪除索引。 –
「顯然不應該聚集在一起」 - 爲什麼?它需要這麼長時間的原因是它不得不重建所有的NC索引(因爲它現在是堆,並且NC索引的葉級頁面包含不同的值,具體取決於表是堆還是具有聚簇索引。 –