WordPress利用のMySQL / MariaDBで注意すること

WP4.2からUTF8からUTF8m4に文字コードが変更

WP4.2からUTF8からUTF8m4に文字コードが変更されましたが、それに関係する内容をまとめます。

まず、MariaDB/MySQL 5.5から、標準のデータベースは、MyISAMからInnoDBに変更となりました。WordPressでは、初期インストール時に標準のデータベースで生成しますので、特別な指定をしない限り標準では下記のようになります。

  1. RHEL/CentOS 6のMySQL5.1にWordPressをインストールするとMyISAM
  2. RHEL/CentOS 7のMariaDB5.5にWordPressをインストールするとInnoDB

また、WordPress4.2から、可能な限りMariaDB/MySQL 5.5から対応の文字コード「utf8m4」を採用します。つまり、

  1. RHEL/CentOS 6にWordPressを入れると、データベースがMyISAMで文字コードがutf8
  2. RHEL/CentOS 7にWordPressを入れると、データベースがInnoDBで文字コードがutf8m4

ところが、utf8(最大3バイト)からutf8m4(最大4バイト)とデータ量が増えたことが起因となって、InnoDBの下記の2つで問題になることがあるようです。

  1. InnoDBのkeyは最大で767byte (utf8のvarchar*255では765bytesなのでセーフ、utf8m4のvarchar*255では1020bytesとなりアウト)
  2. InnoDBでは1行最大8KBまでで、VARCHARとかTEXTとかの可変フィールドは先頭の768 bytesを保存 (MyISAMにはなくInnoDB特有の制約)

実は標準のInnoDBでは、互換性を保つためか古いInnoDBのフォーマット「Antelop」が使われており、これを新しいフォーマット「Barracuda」にすることによって、これらが改善できます。

  1. Barracudaのinnodb_file_per_table 機能によって、keyの最大長を3072byteまで引き上げ可能
  2. Barracudaにすることよって、可変長カラムの全てを外部のオーバーフローページに格納し、クラスタインデックスレコードにそのページへのポインタ(20byte)のみ格納

my.cnfに下記の追加設定を行って、2回くらいデーモンを再起動するとOKのようで、この状態が整ってから、WordPressを新規インストールするようにすればBarracudaでデータが作られます。過去に「Antelop」で作られてしまったDBは、alter tableで各テーブル1つ1つROW_FORMAT=DYNAMICで「Barracuda」に変換すればOKです。また、これらの作業は、非常に危険な作業ですので作業前には必ずmysqldumpなどでバックアップしておいたほうが良いです。


[mysqld]
innodb_file_per_table
innodb_file_format = Barracuda
innodb_file_format_max = Barracuda
innodb_large_prefix

ちなみに、RHEL/CentOS 6で構築したWordPress 4.7のデータをmysqldumpして、RHEL/CentOS 7へ移行するとMyISAM utf8のままMariaDB/MySQL 5.5に移行されます。WordPressは自動的にUTF8からUTF8m4に文字コード変換しないようです(おそらく、自動変換はWordPress4.2よりも下のバージョンからアップグレードするときの1回だけ? 今後のバージョンではわかりませんが)。

また、MariaDB/MySQL 5.5でも昔のように、MyISAMでWordPressを動かしたい方は、下記をmy.cnfに追加設定を行えば、デフォルトデータベースを切り替えることができます。


[mysqld]
default-storage-engine = MyISAM