MySQL (InnoDB) における行のサイズと速度の関係について - kazuhoのメモ置き場

集約演算を行うケースでは、行のサイズを小さく保つことはとても重要。アクセス頻度が低いコラムは別テーブルに追い出すとかしたほうがいいくらい。 一方、集約演算を行わないケース (単一行の insert, update 等を含む) の場合は、(クライアントとの通信のための) システムコールがオーバーヘッドになるので、小さなテーブルにたくさんアクセスをするよりも、長い行を持つテーブルに１回アクセスするほうが良い。 たとえば手元の環境での insert on duplicate key update の速度は、 行のサイズ 必要時間 0KB 1 3KB 4 6KB 7 9KB 13 12KB 13 とかそんな感じ (環境やクエリによる変わるので自分で測定してね。9KB の速度低下はページサイズの1/2を超えたからかな)。つまり、行のサイズが1KB程度だと、通信のオーバーヘッドが大きいからあまり問題に

[kazuhooku]

追記した。あと9KBで速度が遅くなってるのは、ベンチマークで使ってるクエリのワークセットが一次キャッシュに収まらなくなるからかも

[kamipo]

行のサイズが1KB程度だと、通信のオーバーヘッドが大きいからあまり問題にならない。

[webmarksjp]

db

[denken]

JOINすべし派の文献とすべからず派の文献があってどっちが正しいのか分からなかったんだけど、結局場合によるらしい

[Kiske]

JOINは使った方がいいケースと悪いケースがあると思うので要検証

[cybo]

多数の SQL クエリを投げるのは、一般的に間違った戦略。それよりは MySQL 内で join させたほうが良い。

[trashsuite]

『多数の SQL クエリを投げるのは、一般的に間違った戦略。それよりは MySQL 内で join させたほうが良い』 ノードを跨いだパーティションが構成出来ればなぁ…まぁ、それはそれでオーバーヘッドが発生するわけだけども

[se-mi]

行のサイズを小さく保つ

[publichtml]

"1. できるだけ少数の SQL クエリでアクセス可能にする 2. 高速にアクセスできるようテーブル分割をする"

[rsky]

「集約演算を行うケースでは、行のサイズを小さく保つことはとても重要」

[azon]

MyISAM 以外つかったことないのでそろそろ本格的に勉強せないと取り残されそう

[hiro_y]

InnoDBの行。「できるだけ少数の SQL クエリでアクセス可能に」「高速にアクセスできるようテーブル分割」の順序。「多数の SQL クエリを投げるのは、一般的に間違った戦略。それよりは MySQL 内で join させたほうが良い。」

[sankaseki]

[!GTD::資料(いつか読む)] MySQL (InnoDB) における行のサイズと速度の関係について - id:kazuhookuのメモ置き場