『Software Design 2022年9月号』を読んだ

息子氏の本めくりブームのため、表紙がボロボロになってしまいました。

特集1 MySQL アプリ開発者の必修5科目

TEXT 型
- インデックスを付けたい場合は、先頭の文字数を指定して作成する必要がある
ENUM型
- リストから選択された1つの値を持つ
- 文字列型より少ないバイト数でデータを格納できる
- ORDER BY する場合にはインデックスが使用される
  - CHAR に CAST したり工夫が必要
JSON 型
- 検索とか更新もできる
- TEXT 型のカラムに JSON そのまま突っ込んだりするよりは、こちらを使った方が良さそう
他に適切な型があるかもしれないのに、そもそも存在を知らないと選択肢にすら出てこない
- 必要になったとき「この型の方が良いのでは？」と思えるようにしたい

作成されていない場合の挙動
- めちゃくちゃ効率悪い！
- 「とりあえずキーっぽいのに付けておく」運用をしていたことがあり、そういうものだと思っていた
- 違った
クラスタインデックス
- MySQL が自動で作成するインデックス
- これを使った検索が一番高速
セカンダリインデックス
- 自分で作ったインデックス
- クラスタインデックスの検索よりはちょっと遅い
ベストプラクティス
- プライマリキーを定義しよう
- プライマリキーの列サイズはなるべく小さくしよう
- プライマリキーの更新はできればやめよう
Invisible Column
- 指定したカラムを SELECT や INSERT、UPDATE の処理から見えなくする
- アプリケーションから認識されなくなる
インデックスが利用されるケース、されないケース
- 設定したつもりでも、使われない場合がある = 全文検索になってしまう
- EXPLAIN で確認する
インデックスを利用しないようにするオプションがある
- インデックス使用時、未使用時を比較したいときに使う

MySQL では、トランザクションの開始宣言をしないとオートコミットになる
- 勝手にコミットされる
- 基本オートコミットされているので、あまり意識したことがなかった
特に理由がなければ BEGIN ではなく、START TRANSACTION を使う
- オプションが使えるため
暗黙的なコミット
- コミットしていなくても、コミットされるときがある
- インデックスの追加など
セーブポイント
- 便利そう

レプリケーションのタイプ
- 非同期、準同期、グループ
バイナリログ
- 3種類ある
- ログの容量とか、使うクエリによってはデータ不整合の起きる可能性があったりとか、それぞれメリットデメリットがあるので適宜選択する
レプリケーションエラーが発生しやすい要因
- レプリカ側のデータを変更した
- バイナリログが自動ローテションしていて、同期前に消えてしまったとか
- 同期遅延
  - トランザクションは小さくする
  - レプリカのスペックは、元と同じぐらいにする