你真的不想這麼做,原因很多。
首先,如果頁面打開,可能會出錯。假設用戶在id = 4
的條目的編輯頁面上,那麼當您刪除id = 3
的條目並根據您的建議更新ID時。現在,當編輯人員提交時,ID將從他的頁面中取出,他將更新新條目4而不是舊條目4.現在,這是一個直截了當的簡單示例,但除此之外,還有更多的東西在這個級別可能會出錯。其次,編程時涉及很多工作。首先,你需要更新你的專欄。然後,你還需要確保MySQL知道給出下一個條目的號碼。然後,所有這些都必須在一個環境中工作,以確保我們不會在上述問題上遇到很多問題(這非常困難)。與沒有做任何事情的選擇相比,這是很多工作。
第三個問題是存在巨大的性能開銷。想象一下擁有一個擁有成千上萬條記錄的數據庫,然後刪除一個低ID的條目。突然間,具有更高ID的所有條目都必須更新。這可能意味着您的網站變得沒有響應,因爲它正在完成這項任務,並且無法在同一時間處理太多其他事情(事實上,爲了確保我們不會像第一點那樣遇到問題,我們必須確保我們不會同時做其他任何事情(或者確保我們在不同的數據副本上工作),因爲我們可能會在整個更新過程中產生一個結果
我的建議與其他人所說的一致:只要保持原樣,不要擔心這一點。auto_increment
僅用於一個目的:輕鬆地爲每個值賦予唯一的標識符。使用此標識符來標識和引用也許還可以對這些標識符進行排序的情況下,但沒有更多的是有一定的順序(即使這樣人們會不同意與此使用它)。
而不是試圖更新ID,我們應該尋找另一個地方來解決這個問題。如果問題純粹是你對此的感受,那很簡單。您可能並不感覺良好,但您只需要說服自己,更新所有這些ID不是您正在尋找的解決方案。如果你在其他地方使用數字,這個問題可能會更復雜一些。但是,總是有可能使用PHP爲每個條目生成數字,如果數字用於生成HTML內容,那麼絕對是這樣做的合理位置。如果您提供更多關於使用連續數字的地方的詳細信息,那麼可以考慮如何解決這種情況。
什麼都不做,這是它應該如何工作。 – JvdBerg
除了在數據庫中標識**記錄之外,您不應使用_anything_的ID。正因爲如此,我們沒有理由永遠不在乎記錄的ID是什麼模式,它的順序是什麼,或者其他什麼。 **只要給定表中的所有ID都是唯一的(它們將與auto_increment一樣),那麼**並不重要。 – sgroves
訴諸身份證以符合無用的規則具有良好的序列號是一個巨大的數據完整性洞,而不是說主要的性能殺手。保持原樣,auto_increment不會給你連續的數字,你可以用它來稍後顯示,它只有一個目的,那就是唯一標識一條記錄。 –