テーブルCHARSETがutf8mb4に設定され、COLLATIONがutf8mb4_unicode_520_ciに設定されるのはなぜですか
最近、新しい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を実行しています。
私の質問は次のとおりです。
- なんでこんなことが起こっているの？
- 可能であれば、どうすればこれを防ぐことができますか？
utf8mb4が原因で、WPサイトをサポートしていない古いMySQLサーバーにサイトを移行するときに問題が発生しました。 - ポイント2はお勧めですか？
utf8mb4よりも文字セットutf8、およびutf8mb4_unicode_520_ciよりも照合utf8_unicode_ciを使用する利点はありますか？
過去には_utf8_しかありませんでした。 将来、_ 現在、_utf8mb4_がデフォルトの文字セットになります。utf8mb4_がデフォルトの文字セットです。
以前は、__general_ci_がデフォルトの照合でした。 __unicode_ci_（Unicode 4.0）が優れていて、__unicode_520_ci_（Unicode 5.20）が優れていました。将来（MySQL 8.0）、デフォルトは__0900_ci_ai_（Unicode 9.0）になります。
一方、この道はMySQLの過去の過ちによって生じたpot穴でいっぱいです。そしてWPデザイナーは大きな穴に気付かない大きなタンクで運転しています。
MySQL 5.6は、WP過度に長いVARCHAR(255)および_utf8mb4_を使用する可能性5.7.17を使用することで、これを十分に過ぎました（8.0への将来の移行はでこぼこになりません）。
つまり、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_が実用的であればどこでも。その文字セットは絵文字とすべての中国語を提供します（utf8はそうではありません）。その照合は利用可能な最高のものですが、それがどこに重要であるかに気付くのは難しいかもしれません。
注：照合名の最初の部分は、それが機能する唯一の文字セットです。つまり、_utf8_unicode_ci_は_utf8mb4_では機能しません。