RDBMSのデフォルト文字セットがutf8の状態で,はじめから,同じ手順でテーブルを作り直す。文字コードをutf8mb4に変換。挿入済みのデータに変化はない。4byteの文字「」を3byteの文字として登録されたので,情報はすでに欠落しているので,あたりまえ。TABLE文だけで文字コードを指定したときは,カラムのデフォルト文字コードの変更も必要だったが,今回はそのままが挿入できた。TOがそれぞれのカラムの文字コードも変更してくれるので対応忘れなどに陥りにくいですね(ここでは文字コードだけを指定しましたが,後述のCollationも文字コードに合わせて変更するようにしましょう)。文字コードやCollationは変更できるとはいえ,運用開始,データの投入の前から,扱うデータの性質をきちんと分析し,適切な設定をしておくのがよいのは明らかです。Collation――照合順MariaDBでは,文字セットのほかに,Collation(照合順序)の指定ができます。Collationとは,データの突き合わせのしかたです。appleもAppleも選択されます),というルールのことです。日本語だと「は」と「ハ」,「ぱ」と「ば」「は」,「あ」と「ぁ」,「サーバ」と「サーバー」などを区別しないで検索したいときがありますよね。TABLE時のカラム指定時)で,カスケードダウンします。問い合わせ時も同様,次のようにSELECT文を発行するときに,COLLATE句を用いて指定することもできます。2;ここでは,全体に関わるサーバレベルのデフォルトに注目してみましょう。COLLATIONで確認できます。|......(省略)......Collationのカラムを見ると,文字コードに加えて,ubf8mb4_「なにがし」のような記述があることが確認できます。Conventions)。ここに記述があるように,Collationは「なにがし」で照合(同一視)する文字の違いを表しています。generalはMySQL/MariaDB独自の基準で,unicodeはUnicode4.0に基づくということです。unicodeの後ろに(520などのように)番号があるのはunicodeのバージョン(ここでは,520=Unicode5.2.0。Consortiumを参照)です。だいたい末尾に_ciがついていますね。Insensitive”の意味で,大文字小文字を区別しないということです。binはバイナリの意味で,文字コードが違えば違う文字と判定します。筆者の環境で確認した限りでは,アクセント記号(アルファベットだと文字の上や下についている点とかニョロとか,日本語なら濁点半濁点でしょうか)や長音のゆらぎなど,ciやbin以外のCollationは対応していないようです。Collationsに記述があります。それぞれが何をどう扱われるのかや,どのような文字が含まれている/いないのかなど,すべてを仕様から読み解くのはたいへんですね。対象の文字がどのように扱われるかは,実際にシステムにデータを入れて検索して確認するのが確実です。本書の以下の部分に誤りがありました。ここに訂正するとともに,ご迷惑をおかけしたことを深くお詫び申し上げます。第1特集第1章「バックエンド高速化の全体像」ページ下部,箇条書き部分の各種ソフトウェアについて名称に誤りがありました。