テーブルCHARSETをutf8mb4に設定し、COLLATIONをutf8mb4_unicode_520_ciに設定する理由

Question

新しいWordPressプロジェクトを開始すると、テーブルの照合順序が自動的にutf8_unicode_ci（私はPhpMyAdminから新しいDBを作成するときに選択したものです） ）からutf8mb4_unicode_520_ciに変更します。

また、一般設定のPhpMyAdminでは、サーバー接続の照合順序がutf8mb4_unicode_520_ciにデフォルト設定されています。

私はUbuntu 17.04でMySQL Server 5.7.17とPhpMyAdmin 4.6.6を実行しています。

私の質問は、以下の通りである：

1. をなぜこの出来事はありますか？
2. 可能であれば、どうすればいいですか？ utf8mb4のため、WPサイトをサポートしていない古いMySQLサーバーに移行する際に問題が発生しました。
3. ポイント2がおすすめですか？ utf8よりもcharset utf8mb4を使用してutf8_unicode_ciよりもcollat​​ion utf8mb4_unicode_520_ciを使用することに利点はありますか？

Answer 1

以前は、utf8しかありませんでした。将来はutf8mb4がデフォルトの文字セットになります。

以前は、_general_ciがデフォルトの照合でした。 _unicode_ci（Unicode 4.0）が良く、次に_unicode_520_ci（Unicode 5.20）でした。将来（MySQL 8.0）、デフォルトは_0900_ci_ai（Unicode 9.0）になります。

一方、道路には、MySQLの過去の間違いによって生成された穴がいっぱいです。そしてWPのデザイナーは、穴に気づかない大きなタンクで運転しています。

MySQL 5.6は、長すぎる長さのWPインデックスと一緒にインデックスに767の制限があり、utf8mb4を使用する可能性があるため、多くのWPユーザーを飲み込んだ大きな穴でした。あなたは5.7.17を持っていることでそれを遥かに過ぎています。

つまり、5.7.7以降の新しく作成されたデータベース/テーブル/カラムは767の問題を経験すべきではありませんが、古いバージョン（5.5.3+）から移行されたものは、特に何かがutf8mb4に変更された場合には、問題が発生する可能性があります。

どうすればよいですか？私はおそらくすべてのオプションを綴って宇宙を使い果たすでしょう。ですから、あるべきデータの履歴、アップグレードパス（もしあれば）、現在の設定、テーブルのROW_FORMAT、列のCHARACTER SETとCOLLATION、SHOW VARIABLES LIKE 'char%';

の出力を提供しますか？実用的であれば、5.7.7+については、utf8mb4とutf8mb4_unicode_520_ciです。その文字セットは、Emojiとすべての中国語を提供します（utf8はありません）。その照合が最も有効ですが、重要な箇所に気づくのは難しいかもしれません。

注：照合名の最初の部分は、それが動作する唯一の文字セットです。つまりutf8_unicode_ciはutf8mb4で動作しません。