web-dev-qa-db-ja.com

照合順序のみを変更するためにCONVERT TO CHARACTER SETを使用していますか？

これに対する答えは明らかなイエスだと思いますが、確認を見つけるのに苦労しています。文字セットに関連するすべての質問は、照合順序だけでなく、文字セットの変更に関するもののようです。

だから私はutf8mb4_unicode_ciに変換したいutf8mb4_general_ciにテーブルがあります。タスクを完了するために次のクエリを安全に実行できますか？

ALTER TABLE mytable CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci

Information_schemaのテーブル照合がutf8mb4_general_ciに設定されているすべてのテーブルでそれを実行します。このタスクを開始する前に知っておくべきことはありますか？テーブルの列にも同じ文字セットが設定されていることを再確認する必要がありますか？照合順序を変更するだけでも後で文字セットの問題が発生する可能性があるという警告を受けましたが、それがどれほど真実であるかはわかりません...

これらのデータベースには、変換するlatin1-tablesとutf8-tablesもあります。しかし、私は一度に1つの課題に取り組むようにしようと思います。列の種類を変更したくないので、そのコマンドを使用するよりも複雑な方法で行う必要があると思います。

（私は私たちが持っている多くのデータベースのテーブル間の文字セットの矛盾を修正しようとしています）

ですから、すでにutf8mb4であるこれらのテーブルの照合を統合することから始めて、そこから徐々に続けていきたいと思います。

サーバーのバージョン：5.7.16-10-log Percona Server（GPL）、リリース '10'、リビジョン 'a0c7d0d'

mysqlmysql-5.7perconacollationcharacter-set
2
user1015149

文字セット変換を管理するためのいくつかのオプションがあります。ご存じのとおり、alter tableオプションがあり、ステートメントで文字セット句または照合句またはその両方を使用できます。

その他のオプションには、データベース全体の文字セットと照合順序の変更が含まれます（まだ実行したくないと思います）。

または、無料でオープンソースのツール Percona Toolkit が開発者に非常に人気があります。pt-online-schema-changeは、主キーを持つテーブルの移行を管理するのに役立ちます。

Perconaから独立したコンサルタントであるDavid Berubeが、コミュニティブログで、文字セットと照合順序を変更するときに発生する可能性があるいくつかの問題について、詳細なブログ投稿を書きました。これは https://www.percona.com/community-blog/2018/06/12/character-sets-migrating-utf8mb4-pt_online_schema_change/ で読むことができます

潜在的な落とし穴には、データベースバージョンの互換性、アプリケーションの「期待」、キーの長さの管理（長さが変わる可能性があります）、および誤検知が発生する可能性があるという事実、つまり、latin1であると示す列はそうではない可能性があります。

今回はPercona Webサイトに多数のブログ投稿と無料のWebセミナーがあります。MySQL文字セットに関する問題のトラブルシューティング https://www.percona.com/resources/webinars/troubleshooting-issues-mysql-character -sets

これらのいくつかがあなたのシナリオに取り組むための最良の方法を見つけるのに役立つことを願っています。

-開示：私はPerconaで働いています

2
percona-lorraine

only the COLLATIONを変更しているので、

_ALTER TABLE t MODIFY col1 VARCHAR(...) COLLATION utf8mb4_unicode_520_ci ...,
                     col2 VARCHAR(...) COLLATION utf8mb4_unicode_520_ci ...,
                     ...;
_

残念ながら、「...」を正確に取得する簡単な方法はありません。サイズ、NULL/_NOT NULL_などを繰り返す必要があります。

代わりに、あなたが提案したように、

_ALTER TABLE t CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_520_ci;
_

最高かもしれません。潜在的な問題：

  • _utf8mb4_unicode_520_ci_（Unicode標準バージョン5.20に基づく）は、_utf8mb4_unicode_ci_（Unicode 4.0に基づく）よりも優れているとお勧めします。
  • _CONVERT TO_は、utf8mb4以外のすべての列も変更します。たとえば、country_code CHAR(2) CHARACTER SET asciiのような列がある場合、これは良くありません。あなたが持っているものがASCIIであるとき、utf8mb4の複雑さとサイズを使わないでください。 （これは小さな問題です。）
  • テーブルはある程度ロックされ、テキスト列を含むインデックスは必ず再構築されます。
  • 照合順序が異なる2つのテーブルを結合すると（1つのALTERと次の照合の間など）、インデックスが無視され、クエリが遅くなる場合があります。
  • 5.7には、utf8mb4で5.5および5.6を悩ましていた「767」の問題はありません。あなたが以前にその問題について何らかの問題を抱えていたなら、今がそれを片付ける時です。
  • はい_pt-osc_（または_gh-ost_）は、大きなテーブルではおそらく良いアイデアです。 （小さいテーブルは問題にならないほど速く変換されます。）
  • マルチマスター/ Galera /グループの複製-これらには、他の問題や技術が存在する可能性があります。

それらのコメントを除いて、私は問題を予測しません。

1
Rick James