使用隨機值作為主鍵時的InnoDB聚集索引性能

Question

默認情況下，我的InnoDB存儲引擎的主鍵是自動遞增整數。 為了隱藏數據庫中的行數，應用程序代碼為主鍵實現了一些隨機生成器。

這是典型方案的示例：

CREATE TABLE `MUSIC_LINK` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `project_id` int(11) unsigned DEFAULT NULL,
   PRIMARY KEY (`id`),
) ENGINE=InnoDB AUTO_INCREMENT=15 DEFAULT CHARSET=latin1;

我正在讀一本書，才發現InnoDB使用按主鍵排序的聚簇索引。 本質上，這意味着數據庫文件中的記錄由主鍵值索引和排序。 只要下一條記錄的主鍵始終大於插入的最后一條記錄（這是默認情況下，由於自動增量約束），就很好。

當主鍵不再自動遞增時會發生什么？ 為了使文件按主鍵排序，每次插入小於最大主鍵的主鍵時，都必須進行大量重寫。

我是否誤解了聚集索引如何在InnoDB中工作？ 因為這聽起來像一個巨大的性能問題。

Answer 1

InnoDB：

使用AUTO_INCREMENT PRIMARY KEY ，“下一個”行將放置在保存表數據的BTree的“末尾”。 這是有效的，並且“最后一個”塊將被大量更新。

注意：塊保留在buffer_pool中， 最終將它們寫入磁盤。

對於GUID，UUID，MD5，SHA1等“隨機” PK，要插入的“下一個”行需要進入保存數據的BTree中的某個“隨機”位置。 如果buffer_pool足夠大，則必要的塊仍將位於其中。 因此，效率與AI並沒有太大不同。

另一方面，如果數據太大而無法容納到buffer_pool中（或者其他活動使塊不斷溢出），則插入將需要在修改塊之前獲取該塊。

例如，如果該表的大小是buffer_pool中可容納的大小的20倍，則下一次隨機寫入將有20的緩存塊中有1的機會。 也就是說，在INSERT有95％的時間必須等待磁盤讀取。

但是...您引發了對INSERTs的討論。 SELECTs呢？ 選擇有什么模式（如果有）？ 如果仍然是“隨機”，則PK的類型無關緊要。 另一方面，如果選擇傾向於到達“最近”項（例如新聞），則AI對於大型表將獲勝，因為緩存了所需塊的可能性增加了。

簇

評論暗示對“集群/ ed / ing”有些困惑。 一些定義（在MySQL / MariaDB上下文中）：

• 一組具有相同數據的服務器，可以一起工作。 NDB群集vs Galera群集vs Clustrix（第三方提供）
• “聚集索引”是將數據附加到索引時。 在InnoDB中，PK始終與數據一起聚集。 （注意：MyISAM和其他供應商不一定會這樣做。）
• 當要獲取的記錄在磁盤上的布局中彼此相鄰時（請考慮PK 或輔助索引），則這些行將“聚集在一起”。 值得注意的是，獲取一個塊會獲得所需的幾行。

所以，回到評論：

• 在PRIMARY KEY跳轉（由於使用了我所謂的隨機PK，或者只是由於未按某些相關順序獲取行）被卡在了表中。
• UUID具有“排序順序”，但是它對大多數事情都沒有用。