MySQL5.7からMySQL8.0へのアップグレード

# 概要
Aurora2(MySQL5.7系)がサポート停止したため、Aurora3へアップグレードを行ったのでまとめます。
MySQLとAuroraそれぞれの注意点と課題を記載します。

**公式DOC**
- [MySQL 8.0 での変更](https://dev.mysql.com/doc/refman/8.0/ja/upgrading-from-previous-series.html)
- [MySQL 8.0 の新機能](https://dev.mysql.com/doc/refman/8.0/ja/mysql-nutshell.html)

# MySQL5.7=>8.0へアップグレード

## 参考
- [MySQL5.6->MySQL8.0へのバージョンアップで対応したこと4つ](https://qiita.com/shibuchaaaan/items/26976503bf0d4a707ae7)
- [note の Aurora MySQL を v2 から v3 へアップグレードしました](https://note.com/tic40/n/n99d9a423ed80)
- [range の最適化](https://dev.mysql.com/doc/refman/8.0/ja/range-optimization.html)
## GROUP BY使用時にORDER BYが必須になった。
MySQL5.7では`GROUP BY`使用時に暗黙のソートが行われていましたが、MySQL8.0では行われなくなりました。
公式より引用
>互換性のない変更: MySQL 8.0.13 では、GROUP BY 句の非推奨の ASC 修飾子または DESC 修飾子は削除されています。 以前に GROUP BY ソートに依存していたクエリーでは、以前の MySQL バージョンとは異なる結果が生成される場合があります。 特定のソート順序を生成するには、ORDER BY 句を指定します

### 対応
検索結果の順序が動作に影響がある場合、`ORDER BY`で指定する。

## IN句がフルスキャンを起こすケースがある
IN句に入った値が、メモリ許容量を超えると`range`が使えずフルスキャンになってしまいます。

### パラメータ
メモリ許容量は`range_optimizer_max_mem_size`に定義してあり、デフォルト値は8,388,608byteです。

### 消費メモリの計算
IN句に渡す要素１つあたり約230byteを消費します。
IN句がひとつのクエリに複数ある場合、積算でメモリを消費します。
下記の例であれば`M * N * 230byte`が消費メモリです。
```
SELECT COUNT(*) FROM t
WHERE a IN (1,2, ..., M) AND b IN (1,2, ..., N);
```

### 対応
消費メモリの計算を元に`range_optimizer_max_mem_size`を適切な値に変更します。
IN句で膨大なメモリを消費するケースでは分割も検討します。
230byteはあくまで概算なので、実際のデータ数と比較して検証環境でテストを行うのが良いです。

## 複数の名称があった関数の統一
複数の名称で使用可能だった関数が、ネームスペースの一貫性を高めるため統一されました(`X`と`ST_X`など)

### 統一された関数の一覧(公式より)
>- これらの関数は、MBR 名を優先して削除されます: Contains(), Disjoint(), Equals(), Intersects(), Overlaps(), Within()。
>- これらの関数は、ST_名を優先して削除されます: Area(), AsBinary(), AsText(), AsWKB(), AsWKT(), Buffer(), Centroid(), ConvexHull(), Crosses(), Dimension(), Distance(), EndPoint(), Envelope(), ExteriorRing(), GeomCollFromText(), GeomCollFromWKB(), GeomFromText(), GeomFromWKB(), GeometryCollectionFromText(), GeometryCollectionFromWKB(), GeometryFromText(), GeometryFromWKB(), GeometryN(), GeometryType(), InteriorRingN(), IsClosed(), IsEmpty(), IsSimple(), LineFromText(), LineFromWKB(), LineStringFromText(), LineStringFromWKB(), MLineFromText(), MLineFromWKB(), MPointFromText(), MPointFromWKB(), MPolyFromText(), MPolyFromWKB(), MultiLineStringFromText(), MultiLineStringFromWKB(), MultiPointFromText(), MultiPointFromWKB(), MultiPolygonFromText(), MultiPolygonFromWKB(), NumGeometries(), NumInteriorRings(), NumPoints(), PointFromText(), PointFromWKB(), PointN(), PolyFromText(), PolyFromWKB(), PolygonFromText(), PolygonFromWKB(), SRID(), StartPoint(), Touches(), X(), Y()。
>- GLength() は、ST_Length() を優先して削除されます。

### 対応
該当する関数を統一後の名称に変更する。

# Aurora2=>Aurora3へのアップグレード
RDSのブルーグリーンデプロイメント(B/Gデプロイメント)機能を利用する前提での記載となります。

## 参考
[[AWS]Amazon Aurora Blue/Green Deployments を試したら幾つかハマった、がしかし最高の機能だと実感した](https://zenn.dev/third_tech/articles/9fc8c056d1757d)
## レプリカ元のバイナリログを有効化する必要がある。
バイナリログが無効になっている場合、B/Gデプロイメントを作成できません。
レプリカ元clusterのパラメータグループの`binlog_format`をROWやMIXEDなど有効な値に変更する必要があります。
パラメータ変更は再起動後に適用されます。

## 最小インスタンスサイズの確認
Aurora3の最小インスタンスサイズを満たしていない場合、サイズアップする必要があります。B/Gデプロイメントは、レプリカ元のクラスターのインスタンスサイズを引き継ぐためです。
サイズアップはダウンタイムが発生するため、注意が必要です。

2024/2月現在、東京リージョンの最小インスタンスサイズは以下となります。
- Aurora2 => `db.t3.small`
- Aurora3 => `db.t3.medium`

# まとめ
n番煎じですが、関数名の統一がピックアップされた記事は無かったので備忘録としてまとめさせていただきました。