Mysql
MySQL 聚集索引還是非聚集索引？（數據庫設計）
我知道這對 SE 這個角落的你們來說可能是一件基本的事情，但我在找出設計數據庫的最佳選擇時遇到了一些麻煩。
我正在創建一個自定義應用程序，使用者將在其中將數據輸入到表中（讓我們將此表稱為“清單”）至少每分鐘 1 個條目，每個條目都將從輸入欄位中獲取數據，並且在添加新行時，目前日期和時間也被添加到
datetime列中。稍後，前端的應用程序使用者每周至少會瀏覽此表 4 次，以導出之前輸入的數據。
我希望它們按日期進行大量排序，因此我計劃在日期列上為 MYSQL DATE = 的前 8 個字元創建索引
00/00/00（id 省略時間部分）。據我所知，索引會減慢數據的插入和更新速度，因為每次輸入新數據時都需要重建索引。
這聽起來像創建索引（除了主鍵）效率低下$$ id $$）如果使用者將至少每分鐘輸入一次數據，可能連續 2 小時（每天）並且必須每分鐘重建索引（？）新數據進來。
我知道這張表會不斷增長，因為他們需要連續多年跟踪記錄，這就是為什麼我想在日期列上放置一個索引以使其在速度方面成為未來的證明。但事實上他們如此頻繁地向其中輸入數據並且每次都必須重建索引，這讓我對如何進行有點迷茫。
我在想一個非聚集索引會解決這個問題嗎？我看過幾個解釋這兩者的影片，似乎仍然需要對非聚集索引進行重建？
任何幫助和性能提示將不勝感激
關於主鍵：
- 每個表必須有一個
PRIMARY KEY.- PK（在 MySQL 的 InnoDB 引擎中）始終是“集群的”
- PK 以外的索引是非聚集的。
- PK是“獨特的”。它唯一標識每一行。
在你的問題中：
- 每分鐘一個
INSERT非常慢。（所以，這裡沒有性能問題，不管表上的索引，不管其他什麼。）- “導出”行——你的意思是“讀取”（
SELECT）還是“存檔”（SELECT，然後DELETE）？（請提供更多詳細資訊。）- “MYSQL DATE 的前 8 個字元 = 00/00/00”——您沒有儲存該
DATE部分嗎？如果沒有，則將其設為一TIME列。如果您只想“提取”時間（從 aDATETIME中，請參閱TIME()函式。- “索引……減慢數據的插入和更新速度，因為每次輸入新數據時都需要重建索引。” 不不不。除非有明確的請求，否則不會重建索引——這很少得到保證。
- 擁有索引確實會稍微減慢寫入速度，但索引可能會顯著加快讀取速度。所以，不要害怕有索引。
- 10 年後，您將擁有大約 500 萬行。隨著桌子的發展，這只是中型。不是問題。但是，對於訪問單個行或行組，強烈建議使用索引（無論是 PK 還是輔助）。
- “我想在日期列上放置一個索引，以使其在速度方面成為未來的證明。” ——那並不是“面向未來”的。它會幫助一些
SELECTs人，但不會幫助其他人。向我們展示這些選擇，以便我們推荐一組對這些選擇最優化的索引。- 稍後，如果您添加/刪除/更改索引（主索引或輔助索引），將會付出一些努力，可能涉及復製表。現在擔心這個還為時過早。