確認すること

メンテナンス時間をどれくらい取れるかで戦略が決まる。基本的にはメンテナンス時間を十分に取れたほうが良い。またリスクをどれだけ許容できるかもビジネスによるので要確認しておくべき。

基本的には一度切り替えてしまうとロールバックすることは簡単ではない。覚悟を決めて突き進む必要がある

最初に諦めること

MyISAMを使いたい
- 8でも動くけど諦めろ、もう未来はない
- InnoDBのほうがDisk サイズを消費する、countが遅い、などの課題はあるので簡単ではないが…
InnoDB memcached Pluginとか使ってるんだよね
- 諦めろ、未来はない
- これを機にアーキテクチャを見直しましょう
PKが無いtableがあるんだよね
- すべてのtableにまずPKを付けるんだ
- このあと、DMSを使ったりとかなにをするにしても死ぬ
- そもそもデータモデルとして死んでるのでPKはつけよう
クエリキャッシュを使いたい
- 諦めましょう。そんなものは無い
- @mita2さんありがと！

Oracle公式 : MySQL 5.7からMySQL 8.0へのバージョンアップ - MySQLを継続してお使いいただくために
リリースノートを見ましょう
- 公式が必要なドキュメントは用意してくれています
AWSの資料もオススメです
- MySQL DB エンジンのアップグレード
- 5.6 → 5.7 などの注意点もあって便利
とみたさんがパラメータ差分わかるやつ作ってくれてる
サイボウズの資料も良い
- MySQL 8.0 への移行が完了しました～さようなら全ての MySQL 5.7～
- 特に具体的な事象に対する紹介があってよい
- 外部キー制約のALTERの話とか
MySQL 8.0はマイナーバージョンで機能などに違いがあるので、利用するバージョンをよく確認する必要がある
- MySQL 8.0 の新機能
  - MySQL 8.0 で追加された機能、MySQL 8.0 で非推奨となった機能、MySQL 8.0 で削除された機能はそれぞれ読みましょう
  - 合わせて変更点も確認しましょう
- @taka_yuki_04さん、あざます！上の資料をみれば概ね基本的な対応は書いてある。あとはテストしましょう。

文字セットの違い
- 8はutf8mb4
- 照合順序とかも要注意
- 照合順序、ORDER BYしても気づかないことあるので注意
- MySQL 8.0 でも utf8mb4_general_ci を使い続けたい僕らは
- MySQLはカラム単位で変えれるので
パフォーマンスはKVSのような使い方をしていると特に下がる
Aurora 2 → Aurora 3は20 ~ 30%程性能劣化することも珍しくない
クソデカテーブルの count(*) も遅くなっているのも影響を受けやすい
- MySQL 8.0 で SELECT COUNT(*) が失速する
パラメータの差異は見逃しがち
- 旧環境でチューニングしていた内容を反映することを忘れるなど
- 例えば open_cache_table とか range_optimizer_max_mem_size とか
- どちらも5.7のときからあるパラメータだが、バージョンアップ時に新しいconfingを利用することで変更を忘れてパフォーマンスに影響を与えることがある
予約語とかSQLモードの違いとかによるエラーは開発環境で見つけれるはず
- テストを書きましょう
- GROUP BYや予約語は地道に直すしか無いです

時間があったら書く