Zenn
Closed4

Aurora3系アプデでなにが変わったか記事のログ

MySQL
aurora
もりたもりた

これはなに

記事を書くログ。思考ダダ漏れ

何を書くか？

もりたもりた

記事を読んでいく

All about社の記事

  • リンク
  • 変更点まとめというよりはどんな手順でアップデートに対応したか？　のログだな
  • 直面した不具合のログがよい
    • NO_AUTO_CREATE_USERというSQLモードが使えなくなっており、そこにLaravel5.5が追従できてなかったためLaravelのパッチも当てなきゃいけなくなってる
      • これ古いLaravelだと一手間あってめんどいね
      • けど5.5使ってるところは他のつらみもたまってそうで大変そう
    • データソート時のメモリー不足
      • これ、たぶん以前のおれならピンときてない
        • なんかメモリが足りなくなることについてあまり実感がなかったんだよな
        • けどインデックスだとかサブクエリだとかいろんなところでメモリが使われて、わりとこうメモリ使いすぎるなよと注意書きされているのを繰り返し見て、まずいんだなとわかってきた。
        • あとソートはDBが苦手な分野だし
      • データとってきてからメモリ上でソートとある
        • けど、これまでもメモリのデータ見てそれをソートしてからみたいなことしてたのでは？
      • 参考1
      • 参考2
      • クラスタインデックスでソートが発生しないようにして対応とある
        • クラスタってあれだっけポインタだけではなくデータも持ってるやつだっけ
        • データページの並びとインデックスの並びがおなじやつ
        • まとめてとるときとかに便利？　何が嬉しいんだろう
        • までもソートしなくてよいというのは分かる、最初からその順番でデータがある訳だから
  • あと移行するときに引き継がれない設定とかについても書いてある
    • たしかにそれも気にしなきゃだなあ
  • 感想
    • いい記事だった

MySQL8.0のソートの話

  • リンク
  • 基本的には技評の記事と同じ
    • ソートでインデックスが使われるための条件とか
    • selectで使われる値も選択しないとソートされないよ
      • ここ普通にやりそう。orderbyのときは＊禁止にしたいところだね

MySQL8.0のソートの話, ぎひょうの解説

  • リンク
  • orderbyは高コストだからインデックス貼るといいよ
    • explainしてUsing filesortとなってなければインデックスを使えている。なってたら、頑張ってソートしてる
    • その頑張ったソートのやりかたを今回説明。
      • MySQL5.6からふたつのやり方にふえたらしい。ほーん。最適化の仕方は8.0からとか関係なくて、あーそうかソートされるタイミングが変わったんだよな。メモリがどうとかの。。
  • 5.5以前の手法
    • ソートしたい値とrow idのペアをメモリにばーっと積み込んで並び替える
    • メモリに乗らなかったらテンポラリのファイルをつくる。んでマージソートする
    • マージソートとは
      • なるほどマージソートの最後の結合のところやんのね
      • ふたつの配列の最小を比較して、小さいやつ順に新しい配列を作って行く
      • おけおけ
  • 5.6以降の手法
    • ソートに使う項目ではなく、SELECTで指定したカラムたちとソート用項目でソートする
    • row idを使ってデータを取ってくる手間がいらないので、行読み取りが一回で済む
    • ただしSELECTしてる項目が多いとメモリにたくさん乗せることになるので注意が必要
  • どちらの手法が選ばれるか？
    • max_length_for_sort_dataシステム変数
    • ここの値を小さくすると、5.5方式になる。どこまでメモリに載せるのかの閾値になっている
      • じゃあバッファーサイズ変えるよりはこの値変える方がいいような気はするなあ
      • てかこう、一定の目安が割合としてありそう。バッファーサイズの何分の一をここで指定する、みたいな目安がありそう
    • MySQL8.0.20で廃止！！！　なんやねん
      • 常に新しい方式が採用されているっぽい
      • なるほどこれが今回からの変更ってことか
  • 5.6以降では、インデックスの効かないソートでもリミットがあるとソートされることがある
    • LIMIT指定されたカラムタプルがソートバッファにおさまるかを実行前に計算する
    • 収まるならソートバッファを優先して使い、メモリ上で完結する
      • LIMIT指定してもソート前のやつは全件扱うのでは？　それは乗らないことない？
    • 最適化されたかはoptimizer_traceのfile_summaryでわかるらしい
      • とは
      • ああそういうinfomation schemaがあるのか
  • まとめ
    • とはいえインデックスでやんのが速い
    • 次点でここのやつ

where句狙いのキー、order by句狙いのキー

サイボウズのMySQL8.0移行記録

  • https://blog.cybozu.io/entry/2021/05/24/175000
  • MySQL8.0.20までのリリースノートを見てやってるらしい
    • たぶん Aurora3系で今使われるのはAurora3.04であり、MySQL8.0.28相当なので、そこまで見た方がいい気がするな
  • 変更点
    • 文字コードとして utf8mb4 を使っている場合の照合順序のデフォルト値が utf8mb4_general_ci から utf8mb4_0900_ai_ci に変更されました。
    • SQL_CALC_FOUND_ROWS と FOUND_ROWS() が deprecated に
      • フーン
      • これLaravelで使ってたりする？
      • 重たくなるかもしれんなあ
    • Connector/J のメタデータ取得処理の性能低下
      • Connector/J とは
        • JavaのMySQLドライバ
        • 8.0.21からは性能がマシになってるらしく、今回は関係なさそう
    • ロック競合の状態を解析に利用するsys.innodb_lock_waitsに関する不具合
    • 外部キー制約をもつテーブルの DDL 操作によるメタデータロックの発生
      • あこれyoku0825さんが言ってたやつか
      • 外部キー貼ってるテーブルに対してalterするとロックとるんだよな
        • alterがブロックされるならいいけど、alterが先に占有しちゃってユーザー影響あると怖い
        • yokuさんの記事読む感じなさそうだな
        • 実行したクエリがどんなロックを取っているのか確認する方法ってあんのかな？
          • ああなるほど、トランザクション内でperformance schema見ればいいのか
    • トランザクション分離レベルを設定する変数名の変更
      • 接続時にトランザクション分離レベルを指定しているケースでなんか困ったとのこと
      • 普段トランザクション分離レベルの指定とかしないけど、どういう動機でするんだろう
        • ゲームとかだとやんのかな、なんかユーザー数多いとか厳密なトランザクション管理が求められるやつあるよね
    • UNION 句と FOR UPDATE を使う場合に括弧が追加で必要
      • ほーん
      • SQLの書き方
    • Implicit Account Creation の廃止
      • はい
      • Grantでユーザが作られるやつらし
    • information_schema のカラム名が大文字固定に
      • そんなんあったんか。これまではどっちでも良かったらしい
    • EXPLAIN ステートメントの EXTENDED キーワードの廃止
      • デフォルトになったらしい。ありがたい
    • GROUP BY a ASC の廃止
      • へーそんな仕様が
      • これからはGROUP BYとORDER BYは分けて書く
  • 感想
    • 詳しい！　えらい！

SmartBankのAurora MySQL8.0移行記録

  • リンク
  • Auroraの記事だ
  • 三つの問題
    • collation
      • 文字コードの順序のやつ
    • 暗黙の昇順ソート
      • GROUP BYでソートさせるやつ
    • クエリによるCPU負荷
      • SELECT COUNT(*)で重くなるらしい
      • 件数出す定数みたいなやつが廃止になった後にこれはきついね
      • これどういう仕組みで重くなってる？　ちょっと背景がわからんな
  • tmp table 溢れ
  • 良かった点
    • セミジョインで高速化したクエリがあったはず
      • ほー
    • AUTO_INCREMENT周りの悩みが減った！
      • 良かったね
    • window関数が使えて感動！！！
      • せやな
    • migrationがちょっと安全になった！
      • 既存テーブルへのデフォルト値つきカラム追加が安全になった
      • 5.7以前ではテーブル全体が書き換わるため書き込みがブロックされてた
    • 共通テーブル式（CTE）が使えるぅ〜
  • 感想
    • count(*)とか知らんかったなあ
    • これyokuさんのブログざっと読んだ方がいいかもしれんね
  • count(*)周りの議論

MySQL8.0の変更点 - MySQL公式

Aurora MySQL バージョン 2 と Aurora MySQL バージョン 3 の比較 - AWS公式

MySQL8.0コミュニティエディションからの機能 - AWS公式

もりたもりた

分類

気持ち

  • 膨大だ
    • これを分類するのは結構大変
  • あり得そうなものとしては、
    • 追加機能、改善（使いこなしていい気持ちになるもの）
      • CTEとかWindow関数とか関数インデックスとかJSON関数とか
      • AUTO_INCREMENT
    • 不具合やパフォーマンス問題を引き起こすもの（回避したいもの）
      • collation問題
      • count(*)でメモリに乗らなくなると重いまま（本来は古いのが弾かれるはずだがそうならない）
      • 外部キーを設定したテーブルの親にALTERするとロックされてしまう
      • データソート時のメモリー不足
      • 使えなくなったもの
        • GROUP BY a ASCみたいなやつ
        • SQL_CALC_FOUND_ROWS と FOUND_ROWS() が deprecated に
        • NO_AUTO_CREATE_USERというSQLモード
このスクラップは1ヶ月前にクローズされました