mysql周りのスクラップ

collationをどこに書くか
my.cnfに記載するとcreate tableなどでcharsetのみ記載したときにdefault_collation_for_utf8mb4の影響により、collationがutf8mb4_0900_ai_ciに上書きされてしまう
ref https://qiita.com/iwasakik/items/e5e3ce50ad26692269a7

また設定値default_collation_for_utf8mb4は、my.cnfでは設定できない
このことから各テーブルを作成する際に、charsetとcollationを設定するのが良いかもしれない

collationを初期設定するときに、utf8mb4_0900_bin以外を選択する理由があるのだろうか？

• 各文字は完全区別できる
• パフォーマンスは最速
  binが早い
  https://yakst.com/ja/posts/5431
  0900と0900なしverの比較
  https://qiita.com/hmatsu47/items/d66830c8a00c21f5edad

追記
0900は空白も文字として含む NO PAD属性である
https://speakerdeck.com/tmtms/utf8mb4-0900-bin?slide=9
そのため空白が入り得るデータの場合は、0900なしのほうがよいかも

online alter table
本番稼働に影響を及ぼすことなく、alter tableを行うことが可能
ただし、カラムのデータ型の変更は負荷 lockをshared(読み取り専用)にすることで、これを可能とする

不可視インデックス
indexを削除するときに使用
indexはdropは早いが、addは遅い
そのため、一旦indexをoff(invisible)にして、影響調査をしてから削除することで、切り戻しを防ぐ

loose-default-char-set
https://hirose31.hatenablog.jp/entry/20130313/1363169087

varcharは文字列分のメモリ数を確保する
そのため、varchar(255)として中に入っている文字が1byte文字が5文字だったりした場合、最初の1byteで文字数を指定して、残りでbyte数を確保する
https://qiita.com/yukiyoshimura/items/1ef74e0164faa60442f4

ID採番は推測されてよい場合は、DBの採番

メリット

• メモリ効率が良く、indexの検索も早いらしい
  デメリット
• 単一DBに依存するので、複数DBを扱ったりする場合は依存したり、GUIDとして使えない

そうでない場合はinsta, snowflakeのulidを使うと良さそう
https://zenn.dev/j5ik2o/articles/a085ab3e3d0f197f6559

mysql運用管理実践入門
mysqlはonline alter table(読み書きをブロックしないalter table)は型変更を許容していない
そのため、運用中に値を変更するならばシステムのメンテナンス期間が必要となるため、なるべくやりたくない作業
それに伴って、データ型はなるべく大きめのものを指定することを推奨している
データ型が大きいことによるパフォーマンス低下の懸念はそんなにない(むしろカラム数などのほうが、パフォーマンスに影響しやすい)

正規化のメリットを得るためにはNot Null制約であることを基準に考える