我想知道是否將10個條目插入到SQL Server表中。 如果我刪除其中一個，id/index是否會相應更改？SQL Server，如果元素被刪除，id是否會更改？
例子：
1 | Simon Cowell | 56 years
2 | Frank Lampard| 24 years
3 | Harry Bennet | 12 years
如果我刪除＃2，將哈利班納特的指數變化爲2？
謝謝:)
編輯： 對不起，我的憤怒，有一個糟糕的一天。是的，我應該自己研究它，我應該被低估。 我不要求任何東西，我只想說我很抱歉：
由於您似乎在混淆「id/index」，所以我們來談談一下關於關係數據庫上下文中的主鍵和索引。
分配給SQL數據庫中行的「id」或主鍵是該行的唯一標識符。它可以由一列或多列組成。 （當涉及多個列時，它被稱爲「複合」或「多部分」鍵）。主鍵應該只是作爲尋址行的唯一句柄：主鍵不應該包含任何有關該行代表的實體的信息，特別是如果該信息有可能變化的信息;一個例子是一個零件號碼，後綴代表零件製造的金屬類型;如果這種金屬可能會從鈦轉變爲不鏽鋼，那麼這個零件號將作爲主要關鍵是一個不好的選擇;最好有另一列存儲金屬類型，而不是製作主鍵的金屬類型後綴部分。 「有意義的」主鍵在傳統的非關係數據庫中可能有一定意義，但在關係數據庫中它們是可以避免的。
當試圖強制執行主鍵的唯一性時，數據庫引擎可以使用索引，以便快速測試鍵值是否存在。它可以使用二進制算法來查找值，避免需要逐行掃描實際數據「強力」，尋找值。 但引擎在幕後使用的輔助主鍵管理的索引與主鍵本身不一樣。
如果你有一個簡單的順序整數作爲你的主鍵，它們的數量是無限的，所以當它被分配到的行被刪除時，當它變爲可用時，不需要重用整數。因此，關係數據庫引擎不會自動嘗試重用它，並且當數字序列中的「間隙」由數據庫創建時，它絕不會通過任何方式更改已分配給表中所有其他行的主鍵值刪除。其他表中的許多其他行可能會引用這些值並使它們變爲可變會造成混沌或巨大的低效率。
散列算法是數據庫引擎可以快速測試關鍵值存在的另一種非常有效的方法。它計算散列文件中鍵的位置，如果它存在的話，然後在那裏尋找它。這些行的存儲順序並不特別，所以這些方案經過優化，可以在大表中快速查找記錄，而不是用於剔除具有共同特徵的記錄，例如郵政編碼10023中的所有客戶。
不可以。如果需要，可以設置觸發器或邏輯;但是，它不會自動執行此操作。
這裏是一個鏈接，介紹你觸發器，如果你有興趣：http://www.sqlteam.com/article/an-introduction-to-triggers-part-i –
爲什麼評論你自己的答案？如果您需要添加更多詳細信息，請點擊「編輯」鏈接 –
我同意你的意見，但這是一個後想，我不知道它是否真的添加到OP的問題。 –
不，它不會自動改變
不，它不會。希望這是你所希望的答案。對於任何自動生成的標識符（例如IDENTITY列），應該儘可能忽略數據類型並將其視爲不透明的「一團」身份信息。
它在插入過程中被賦值，並且您可以將其用於交叉引用目的，但是它的數值不是您應該使用或依賴的。它只是該行的穩定標識符。
這將非常簡單自己嘗試一下。 – Laurence
這就像***您的***銀行帳號更改，因爲***我***關閉了我的帳戶。唯一標識符是永久*唯一標識符*。那個價值***是***那一行。更改該值將使其成爲不同的行*（就像更改您的銀行帳號將使其成爲不同的銀行帳戶）*。 – MatBailie
我沒有低估它，但我懷疑它是downvoted，因爲你似乎在問如何做一些在關係數據庫中被認爲是不好的做法 - 重用和/或變異主鍵值。 – Tim