読んでて気付いたんだけど、確かに UTF8MB3 が廃止される未来はあるんだよな、という感じだった。
MySQL v5.6/5.7 から v8.0 にアップグレードした環境と、生え抜きで v8.0 の環境が混在していて、特に charset や collation は「デフォルトで動くしきにしなくていいでしょ」で放置されがちなので、このあたりの負債を一気に返す必要はあるな〜、となっていた。
自分で作る時
自分でイチから作る時は utf8mb4_bin を明示的に指定しているんだけど、アプリケーション開発に噛んでいない時とか、他のプロダクト作っているチームでは専業インフラの人がいなくて見過ごされがちで、一度まとめないといけないんだけど、という状態になりつつある。
流石に latin1 なトコはないけど、雑に utf8 指定しているのが殆どだし、なんなら collaltion あたりも指定していないトコが殆どで、 utf8_general_ci あたりがはびこってるんじゃないか？ という気がする。
管理系の検索でたまに「思った検索結果にならない！」と言われることがあるので、もうちょっと考慮するようになってほしいな、と思いながら戒めとして書いておく。
変更するとき
ダウンタイムを考慮しなければ ALTER で一気に更新できるんだっけか。
ALTER TABLE ${TABLE_NAME} DEFAULT CHARACTER SET utf8mb4_bin;
ALTER は御存知の通りメモリに対象コピーを作成してそちらで高速にガッと処理してから、操作対象と入れ替えて何もなかったフリをする、みたいな動作なので、最低限のメモリリソースとして対象テーブルが全部乗るくらいのメモリが必要 (足りないとスワップする) なはず、という理解なので、めちゃくちゃに負債化すると辛くなるかもしれない。
その他
UTF8MB3 が廃止される未来と直接的には関係ないけど、移行過渡期なんかで文字コードが入り乱れていると以下のような問題が出てくるはず。
テーブル間でcollationが異なるときに起こる問題について紹介したいと思います。その場合、JOINのときに結合キーでインデックスが効かないためクエリが遅くなる可能性があります。
まあまあこういう事は起きないようにするために設計を最初にやるんだよ、という話なんだけど、気づかないこともあるのでしゃーなし。
