MySQL / mariadb innodb：行大小是否會影響復雜的查詢性能？

Question

我的MariaDB 10服務器上有一個具有數百萬行（統計事件）的InnoDB表，歷史上每一行都有一個長的user-id char（44）字段（用作非唯一鍵）以及其他30個int / varchar字段（行大小） （大約240個字節）。 我的系統可以進行同類群組分析，渠道，事件細分和其他常見統計信息-因此某些查詢非常復雜，包含許多聯接。 現在，我有機會添加4字節的int字段，並將其用作用戶ID和所有查詢的主要非唯一鍵。 但是由於實現細節，我需要在此表中保留舊的符號char（44）用戶ID-一些數據源不是我的，僅發送具有符號用戶ID的事件。

因此，問題是：通常來說，保留或刪除此char（44）字段會影響復雜查詢的性能嗎？ 它只會像其他char字段一樣保留，並且不再用作查詢的鍵。 我不希望拆分表，因為有很多代碼取決於它的結構。

謝謝！

---

對Aria進行了測試，發現對於我的目的，即使在簡單的連接上，它也比InnoDB慢1.5倍。 具有“冗余”行格式的InnoDB的運行速度甚至更快。 所以-不，Aria不是妥協，它甚至比myISAM慢。 我想InnoDB是Maria10中的XtraDB，這說明了速度。

還對自連接查詢進行了一些測試，發現如果不使用此字段，則保留或刪除char（44）字段不會對查詢性能產生影響。

從char（44）鍵移到int可使查詢速度提高2倍！

Answer 1

切換到較短的整數鍵將有助於提高查詢性能。 固定長度字符列的索引開銷並不可怕。

如前所述，將更多的RAM和/或某些SSD磁盤填充到數據庫服務器中的成本很可能比重構程序要少。

真正有助於查詢性能的是創建適當的復合 覆蓋索引 。 如果您有僅通過這樣的索引就可以滿足的查詢，那么事情將會變得更快。

例如，如果您做了很多

SELECT integer_user_id
  FROM table
 WHERE character_user_id = 'constant'

那么(character_user_id)上的復合索引將使此查詢非常快速。

添加大量索引時要小心：在具有多個索引的表中對INSERT或UPDATE會付出一定的代價。