2017-06-09 38 views
2

我目前正在使用一個包含大約10.000+條記錄並且正在增長的數據庫。這是一個帶有維護日誌的數據庫,我在該數據庫上執行一些分析以提取有關維護的一些數據。分析結果存儲在不同表中的同一個數據庫中。刪除後重置數據庫記錄Id

維護表:

------------------------------------------ 
|id  remainingdata 
|1  testing 
|2  alsotesting 
|3  testing1 

分析結果表:

------------------------------------------ 
|id  maintenanceid  remainingdata 
|1  1     result1 
|2  1     result2 
|3  2     result3 
|4  3     result4 
|5  3     result5 

進行後分析,這個原因的分析可以重新做的日誌記錄可以被更新。當重新分析維護記錄時,將從表中刪除所有分析記錄(包含維護記錄的外鍵)並重新輸入。假設我重新分析所有3個維護記錄。我的結果表格現在看起來像這樣;

------------------------------------------ 
|id  maintenanceid  remainingdata 
|6  1     result1 
|7  1     result2 
|8  2     result3 
|9  3     result4 
|10  3     result5 

我面臨的問題是,當10.000+記錄被刪除並可能進入每週的AUTO_INCREMENT數得到非常高的速度非常快。因爲我想要將來證明我的數據庫,我需要找到解決這個問題的方法。

注意:結果表中的ID僅用於保留重複項,其他表中沒有任何對它們的引用。

我已經想到了2個可能的解決方案,這對我自己來說都是有利有弊的;

  1. 更改PK爲BIGINT,並希望它不打MAXVALUE

雖然最大值是非常大的還有打它在未來的風險,我不真的想要冒這個風險。

  • 在刪除任何記錄,重置AUTO_INCREMENTTOP(id)
  • 這似乎是最好的解決方案給我,但我很感興趣,如果有反對的論點,這將重置id值到當前表中的最大id,如果所有記錄都被重新分析,它會回到1.

    我想知道我的解決方案的意見是什麼或者是否有人解決這個問題的更好辦法。 在此先感謝

    +0

    你不能使用TRUNCATE TABLE選項來重置AUTO_INCREMENT列嗎? – Sujith

    +0

    @Sujith不是所有的記錄都會被刪除,有時只是1或2 –

    回答

    1

    請轉至BIGINT解決方案。真。

    一個無符號BIGINT可以hold numbers大如9223372036854775807

    隨着10K每週的預期收益率,這意味着你的應用是面向未來的922337203685477周,或17737253917028年,或221715673962人們的生活順序,預計每人約80歲。這大約是世界人口的三倍。

    仍有擊中它在未來的風險,我真的不希望有這種風險

    你可以肯定的是,當達到限制時,你的生命已經結束,解決問題的任務是給其他人。