我有一個數據庫跟蹤用戶狀態的單個表。當我完成處理該行時，不再需要將其保存在數據庫中並可以刪除。查詢性能是否從刪除SQL數據庫中的行增加？
現在讓我們說我想跟蹤行而不是刪除它（用於歷史目的，分析等）。它會更好於：
在同一個表保留數據和標記行作爲「拿來主義」（有一個額外的列或類似的東西）
從表中刪除的行將其插入到只創造了歷史目的
對於選擇＃1一個單獨的表，我不知道是否留在數據庫中的不必要的行會開始影響查詢性能。 （我所有的查詢都在索引列上，所以也許這並不重要？）
對於選擇＃2，我想知道是否不斷刪除行最終會導致諸如碎片之類的問題？
查詢性能將是從長遠來看好：
什麼，直到永遠發生插入：
表的增長，指數增長，指數的表現（查找）是的尺寸減小表格，特別是插入性能受到傷害。
什麼用delete發生的事情：
表網頁獲得支離破碎，所以刪除的空間不重複使用100％符合市場預期，更接近50％，在MySQL。所以這個表格仍然會增長到您預期數據量的兩倍。索引被分割併成爲大片：它包含您的新數據，但也包含舊數據的結構。這取決於你的數據結構有多糟。然而，這種情況穩定在一定的表現。這一業績點有2個好處：
1）表的大小是比較有限的，所以潛在的全表掃描速度更快
2）你的表現是可以預見的。
由於存在碎片，但此性能點不等於您的數據量的兩倍左右，所以它往往會變得更糟（以自己爲基準）。然而，刪除方案的好處在於您的數據集較小，因此您可以在每個合理的時間段內重建一次索引，從而提高性能。
替代
有兩個備選方案，你可以看看，以提高性能：
切換到MariaDB的：這個收益對大數據集約8％的性能（我的觀察，數據集只有大約200GB的壓縮數據）
看看分區：如果你有一個方便的分區參數，你可以爲您創建一系列「小型表格」並防止刪除，重建和歷史數據管理的邏輯。這可能會爲您提供最佳的性能配置。
我比空間更擔心查詢性能。如果空間不是問題，你會說選項＃2是更好的選擇嗎？如果我的閱讀正確，查詢性能並不像選項2那樣糟糕。 – jnortey
我會使用常量刪除或分區。你的數據結構如何？主鍵等（用這個更新你的問題併發送消息，然後我會看看那個場景）。 –
如果大部分表是標記爲刪除，你會爲你尋找非刪除的記錄絆倒他們。將is_deleted添加到許多索引可能會有所幫助。
如果您是純粹在年齡刪除記錄，然後PARTITION BY RANGE(TO_DAYS(...))是一個很好的方式來建立表。 DROP TABLE是即時的，ALTER TABLE ... REORGANIZE ...創建新的一週（或月或......）分區也是即時的。詳情請參閱my blog。
如果您將「移動」記錄添加到另一個表中，則由於存在碎片，表格不會收縮很快。如果你有足夠的磁盤空間，這不是一個錯誤處理。如果某些查詢需要查看當前和歸檔記錄，請使用UNION ALL;它非常容易和高效。
嗯，這是MySQL的。不應該標記兩者。 – jnortey
對於選擇＃2而不是在將行轉移到另一個表之後刪除行 - 您是否可以不重用它們。將行標記爲不再使用，並在您需要跟蹤當前狀態並首先找到使用時搜索那些行 - 如果沒有添加額外的記錄。這樣你就可以避免碎片。不要說這是一個很好的解決方案 - 只是一種避免碎片的方法，如果你沿着這條路線走下去的話。 – PaulF
感謝PaulF的建議，但是我想盡可能避免重複數據。 – jnortey