刪除/添加索引所花費的時間少於添加列。這是為什麼？

我使用的是 10.1.25-MariaDB-1~xenial，但引擎是 innodb。

預設情況下，我正在執行更改，它確實線上更改。

當我添加列時，我們的基礎架構中的 50G 表至少需要 50 分鐘，但是當我執行刪除和添加 3 列的複合索引時需要 8 分鐘。

關於它在做什麼的任何想法？

如果我添加 PK 指數/英國指數，持續時間也會發生變化。

讓我用簡單的方式說。當您創建一個新表/索引然後插入 10 行時，索引值將是 1 到 10。現在您要刪除表中的 5 和 6 行，這樣就形成了孔。下次在插入第 11 到 20 行時，需要重新填充第 5 行和第 6 行索引，這就是為什麼需要時間。如果您刪除一列並重新創建索引，那麼值是自動遞增的，這就是它更快並且沒有漏洞的原因。

（僅指 InnoDB 表。）

ADD COLUMN重建曾經的記錄，為額外的列騰出空間。（MySQL 8.0 有更快的方法。）

ADD INDEX可以做副業；然後將索引放置到位。它可以遍歷表，收集新索引的列，加上PK的列，排序，建構結果的BTree。唯一棘手的部分是在進行所有操作時跟踪更改。（PK 列是二級索引如何連結到實際行。）

幾乎任何涉及PRIMARY KEY( DROP, ADD, 等) 的事情都是非常昂貴的，因為數據儲存在磁碟上的順序是由 PK 控制的。（簡單地使用 PK 值並不昂貴。）

UNIQUE索引增加了驗證唯一性的複雜性。（我不清楚這需要多少額外成本。）

一旦ALTER完成，更改將是永久性的並且將被保留。例如，永遠不需要“重建索引”。（好吧，有某種例外FULLTEXT。）

關於版本的注意事項：10.1 大約等於 MySQL 5.6。5.6 和 5.7 中發生了一些索引性能變化。到目前為止，8.0 已經有了顯著的改進（即時添加列）。在 5.5 及之前的版本中，幾乎所有ALTER操作都是通過完全重建表來完成的。

關於歷史的註釋：創建 MySQL（因此 MariaDB）的想法是作為 RDBMS 做得相當好，具有足夠的功能來完成大多數任務。多年來，出現了某些痛點，並且最終已經、正在或將要解決。Speed ofALTER TABLE是你擊中的那個；您使用的版本僅部分解決了它。

引用自：https://dba.stackexchange.com/questions/224537