MySQL InnoDB 與 PostgreSQL 的 Partial Index(es) 是不一樣的東西...

MySQL InnoDB 指的 Partial Index 是:

An index that represents only part of a column value, typically the first N characters (the prefix) of a long VARCHAR value.

PostgreSQL 指的 Partial Indexes 是:

A partial index is an index built over a subset of a table; the subset is defined by a conditional expression (called the predicate of the partial index). The index contains entries only for those table rows that satisfy the predicate. Partial indexes are a specialized feature, but there are several situations in which they are useful.

先講結論,PostgreSQL 可以做掉 MySQL InnoDB 的 Partial Index 想做的事情,而且還更多。

MySQL InnoDB 的 Partial Index 是設定對 prefix index (對字串前面的 n bytes),可能的情況是 CHAR(32) 只對前面 16 bytes 索引。

PostgreSQL 的 Partial Indexes 受益於許多方面而更強大。因為有 Indexes on Expressions,所以除了可以像 MySQL 對 prefix 索引外,也可以索引 suffix,甚至是索引透過 string function 得出來的值。

像是 PostgreSQL 可以設定「我只要索引一月一日出生的人的 username」:

CREATE INDEX test_index ON test_table (username) WHERE birth_month = 1 AND birth_day = 1;

在 MySQL 裡需要反正規化後下 index,或是拆出另外一個表格再下 index 的問題,在善用 PostgreSQL 這些功能就可以省下不少功夫...

MySQL 對 VARCHAR 的 Index 空間佔用的問題...

之前不知道從哪邊學到錯的東西... 實驗後發現搞錯了。對 MySQL 的 VARCHAR 欄位下 index 所實際佔用的空間仍是實際大小,而非最大長度。

測試方法是建立表格,schema 是 CREATE TABLE test (id INT UNSIGNED PRIMARY AUTO_INCREMENT, data VARCHAR(255)) ENGINE=InnoDB;,在 inndo_per_file 打開的情況下測試。

這是 1M rows,其中 data 都是 "a",這是 OPTIMIZE TABLE 後的結果:(以下每個都有 OPTIMIZE TABLE)

-rw-rw---- 1 mysql mysql     8586 Jul 30 22:42 test.frm
-rw-rw---- 1 mysql mysql 37748736 Jul 30 22:42 test.ibd

這是 ADD INDEX (data) 後的結果:

-rw-rw---- 1 mysql mysql     8586 Jul 30 22:46 test.frm
-rw-rw---- 1 mysql mysql 50331648 Jul 30 22:46 test.ibd

一樣是 1M rows,但 data 都是 "a" * 100 (一百個 a) 的結果:

-rw-rw---- 1 mysql mysql      8586 Jul 30 23:14 test.frm
-rw-rw---- 1 mysql mysql 146800640 Jul 30 23:15 test.ibd

這是 ADD INDEX (data) 後的結果:

-rw-rw---- 1 mysql mysql      8586 Jul 30 23:21 test.frm
-rw-rw---- 1 mysql mysql 260046848 Jul 30 23:23 test.ibd

實驗可以看出來 MySQL 的確是依照內容的實際長度索引,而非用欄位的最大長度做。

Percona 的「Advanced MySQL Query Tuning」...

先前在「Percona 要講進階的 MySQL Query Tuning...」提到 Percona 所辦的 Webniar「Advanced MySQL Query Tuning」的投影片放出來了:「Advanced MySQL Query Tuning」。

這份內容需要 B+Tree 操作的背景知識才能了解。裡面講了很多 GROUP BYORDER BY 混用時的 index 技巧,以及各種奇怪的 hack 方式。

內容很有用,能吸收多少就看個人造化 :p

Percona XtraBackup 2.1.1

Percona 宣佈 Percona XtraBackup 2.1.1 (第一個 2.1 GA 的版本):「Announcing Percona XtraBackup 2.1.1 GA」。

這次的版本提供了 compact backup,備份的時候不要備份 secondary index (因為這可以再建出來),在很多 index 的表格會省下大量的空間 (以及備份的時間),不過還原的時候就得 rebuild,而非直接拿來用,算是讓操作者自己取捨...

在 PostgreSQL 上用 GPU 加速計算...

看到 PGStorm 這個 PostgreSQL 上的惡搞套件,可以把本來 CPU 要做的事情丟到 GPU 上加速...

不過例子很怪啊,不是用 R-tree index 解決的事情嗎?PostgreSQL 明明就有支援 R-tree index 啊?為什麼會要這樣設計,然後用 table scan?我再回去想想好了...

MySQL 5.7...

Oracle 的「MySQL :: MySQL 5.7 Reference Manual :: 1.4 What Is New in MySQL 5.7」列出 MySQL 5.7 預定會有的功能。由於還在發展階段,這頁還會繼續變動。

針對 ALTER TABLE 有不少改善,以下的條件下 ALTER TABLE 將不會產生 temporily table (不會卡住):

  • table 改名。
  • column 改名。
  • column 改 default value。
  • enum 或 set 在不修改原來值的情況下增加值。
  • partition 相關操作。
  • index 改名。
  • index 新增與刪除。(僅限 InnoDB)

幾個常見的操作變得更簡單了,pt-online-schema-change 的功能會慢慢被整合回 MySQL。

然後 InnoDB 要支援 spatial data types 了,不過 index 還沒支援... 不知道有沒有機會看到 :o

用 Percona XtraBackup 備份時用 compact 模式節省空間...

在「Feature preview: Compact backups in Percona XtraBackup」看到的,2.1 版會導入 compact backup 節省備份出來的空間 (目前是 2.0):

As you may know InnoDB PK (Primary Key) contains all data, and all secondary indexes are only subset of columns of Primary Key. So in theory we can store only PK, and re-build secondary indexes as we need. Well, now it is possible not only in theory.

secondary index 可以事後再建,所以有兩種表格會省下很多資源:

  • Index 很多的表格。
  • PK 欄位空間很大的表格 (像是用 VARCHAR(255) 當 PK)。

等出了再來研究看看對 Percona XtraDB Cluster (PXC) 重新同步可以加快多少...

Instagram 說明用 PostgreSQL 的五個優點...

先不管 Instagram 最近的負成長以及反駁,剛剛在 Instagram Engineering 上看到對 PostgreSQL 的稱讚:「Handling Growth with Postgres: 5 Tips From Instagram

FacebookMySQL 的領域裡的實力以及貢獻度可是數一數二,但 Instagram 在被 Facebook 買下後仍然繼續使用 PostgreSQL,總是有些原因存在... 雖然真正的原因不一定是技術,但這篇試著用技術解釋的內容還是可以看一看,了解 PostgreSQL 有哪些特點...

第一個是講 partial indexes,這與 MySQL community 常講的 partial index 是不同的東西。

MySQL 的 partial index 是指只 index 某個欄位的一部分,像是 VARCHAR(255) 裡面只 index 前面的 10 chars;而 PostgreSQL 的 partial indexes 則是指符合某個條件的 row 才 index。

第二個是 functional indexes,可以針對欄位計算後再 index。MySQL 的 partial index 在 PostgreSQL 裡可以用 functional indexes + substr() 達到相同的效果,而且還有其他 function 可以用,花樣更多。

兩個都是 MySQL 做不到 (或是做不好),但 PostgreSQL 做的不錯的。一般在 MySQL 要達到 PostgreSQL 的這兩個功能需要另外開一個欄位,在裡面儲存去正規化後的值,再對這個欄位 index。

第三個是講 defrag 的事情,這部份 MySQL 也可以用第三方的工具 Percona Toolkit 搞定。第四個講 PostgreSQL 的 Write-Ahead Log,有點像是 MySQL 的 binlog。最後一個講 Python 上的 psycopg2

看來看去就是 index 那塊最明顯。可以直接減少去正規化的欄位...

對 MySQL 的 VARCHAR 欄位使用 INDEX 時可以增加效率的方法...

MySQL 中,如果你有 VARCHAR(255) 這種欄位,不要對直接對這個欄位下 INDEX。因為 key 會以最大長度 255 chars 為固定大小,而非動態決定 (latin1 的時候 1 char 是 1 byte,utf8 是 3 bytes,utf8mb4 是 4 bytes),當資料有 1M row data 就直接吃掉 1MB/3MB/4MB 的空間。

解決方法是利用「index 可以指定只取前面 n chars」這個功能來做,至於 n 要取多少就是要估算了... 在「Optimal index size for variable text in MySQL」這篇把要怎麼做的過程寫得還蠻完整的。

同樣的道理也可以用在固定寬度的 BINARY(16) 系列上。