插入/更新可擴展性（更多記錄，持續更長的查找 — 解決方案？）
之前發布過這個，但從未收到明確的答案。
我正在從事一個 ETL 項目，基本上是將“票證”的 JSON 記錄輸入 MySQL 數據庫。（實際上想想，可能是遷移到 SQL server，但我不確定這會不會有很大的不同）。
這些 JSON 記錄是每張工單的“目前數據”。
所以它會說，例如：
Ticket_Id: 1 Ticket_Subject: Hi Ticket_Issue: Greeting Ticket_Status: Open
將來我可能會得到這樣的記錄：
Ticket_Id: 1 Ticket_Subject: Hi Ticket_Issue: Greeting Ticket_Status: Closed
這些更新記錄按它們生成的順序儲存……所以很容易瀏覽每一天，解析 JSON，並使用 Ticket 記錄執行插入/更新到 SQL 數據庫/表中。
這就是問題所在。數據庫中目前有 100k 票。在 6 個月內可能會有 500k 張門票。
ETL 過程已經相當緩慢，我需要努力優化每一步。現在，我想專注於 SQL 插入/更新。
目前它正在查找 100k 行……很快它將查找 500k……最終 200 萬……你明白了。這目前不可擴展。
幸運的是，我知道這些票在 30 天不活動後會“存檔”/不可編輯。它們永久“關閉”，永遠不會再更改或更新。
因此，可能有一個邏輯解決方案以某種方式傳輸、鎖定、移動、分區、忽略……我根本不知道……這些“關閉/存檔”票證……所以我只需要執行日常查找反對任何一天的 30k 活躍門票。不是一百萬。
這似乎是一個極其常見的問題（幾乎是任何大型插入/更新難題）……但我在網上沒有找到很多簡單的想法。
我想知道這個問題的簡單、可維護的解決方案是什麼。即使“最簡單的”可悲的是兩張不同的桌子或者你有什麼。我在執行“聯合”選擇語句時沒有問題 — 實際上，“選擇”查詢時間已經非常快而且不是問題。問題是插入/更新/查找/寫入時間。
有任何想法嗎？
在插入記錄時解析 JSON，而不是稍後。（好的，也許您需要在到達和處理之間的“暫存”表中收集 JSON。）
解析 JSON 時，僅提取您需要在 MySQL 中操作/搜尋/等的欄位。保守一點。不要提取很多欄位。將 JSON 保留原樣，以防您稍後需要詳細資訊。將其壓縮並將其儲存到 BLOB 中甚至會很好——以節省空間，從而減少 I/O。
您將對數據進行哪些查詢？研究它們對於數據倉庫的設計至關重要。
正確索引（等），增長10倍的表可能只慢 10%。不要驚慌，但請查看查詢。我見過十億行的桌子很好地嗡嗡作響。
聽起來您每分鐘只插入大約 2 行；那是對的嗎？每秒 100次是開始變得具有挑戰性的時候。
在我們討論了我提到的一些問題之後，讓我們擔心“歸檔”。