TokuDB + MariaDB 10：我應該使用聚集索引嗎
我有一張大表（200 列.. 我知道，但這不是我的設計），它會快速增長，而且我會有很多無用的行，由 IP（
varchar32 列）標識。該表每天將獲得數十萬行，我需要刪除該列中具有特定 IP 的數千行。在白天定期（也許 5 分鐘）我需要選擇行並避免使用特定 IP 的行。我可能會在晚上進行刪除，以免給數據庫帶來太多負擔。
我應該在該列上使用聚集索引還是正常索引？TokuDB 聲稱沒有與 InnoDB 不同的性能損失，但我們仍然在談論 200 列（為了公平起見，其中很多是空的（或 null 或 0））。
我還需要在其他一些
varchar列上添加更多索引，以及我將在這些列上執行選擇。有些將具有巨大的基數，因為它們是“以毫秒為單位的時間戳”。我會從聚集索引中受益還是受害？
如果沒有更多架構和工作負載資訊，這是一個很難回答的問題，但是聚集二級索引的主要好處是它不僅包含索引列和表中的所有其他列。“正常”二級索引包含索引列和主鍵（用於通過 PK 索引查找 SELECT STATEMENTS 的其他列）。
二級聚集索引的缺點是所有數據都儲存了兩次。一次用於您的 PK，一次用於聚集二級索引。如果您的數據是可壓縮的，這可能不是什麼大問題，但聚集索引肯定會比非聚集索引佔用更多的磁碟空間。
現在為了利益。如果您正在執行範圍掃描，或者您的查詢需要多行來獲取同一個 IP 地址，則聚集二級索引的性能將明顯優於非聚集二級索引。如果您的數據庫比您的記憶體大得多，那麼您將在返回的每行中節省 1 個 IO，這會對您的查詢產生重大影響。
表上的插入性能受此選擇影響，但您沒有提及是否存在插入性能問題。
@Recct 和其他人在這種情況下
最好的選擇是將 IP 用作 4byte (ip v4) 或 9byte(ip v6) 整數類型。它減小了列和索引的大小。它們作為數字進行比較，選擇範圍比 varchars 快得多。
Timestamp 也是如此。
因此，像 (ip,timestamp) 這樣的集群索引對於像這樣的查詢更有利
Select * From table Where (not (ip=xxx) ) and (timestamp between yyy and zzz)varchar 的聚集索引在您的情況下不會帶來太多好處，因為您不能為它們使用範圍。因此，您將期望以與正常索引幾乎相同的方式處理查詢。