はじめに この記事は、MySQL Casual Advent Calendar 2013 7日目の記事です。 〜 Casual に記事を書けばええんやでヽ(´ー｀)ノ 〜 私がMySQLで えっ？！ っと思った下記エントリーの挙動が何故そうなってしまうのかを書きたいと思います。 InnoDBで行ロック/テーブルロックになる条件 MyISAM はテーブルロック、InnoDB は行ロックが掛かるというのは有名な話じゃないかと。 ただ、最近知ったのですが、InnoDB だとしても必ずしも行ロックになるわけではなく、テーブルロックになる場合もあるようですね。 ... InnoDB であってもユニーク制約 or インデックスが張られているカラムで検索した場合以外はテーブルロックになってしまうようです。これは注意しないと思わぬところでテーブルロックになってしまって大変なことになりそう！ http://
InnoDBのアーキテクチャおさらい クエリは、物理レイヤーの特性を意識して書かなければいけないものの、基本的にはロジック（論理）を記述するレイヤーである。前回まで解説したオプティマイザは、論理と物理の中間に位置する（または両者をつなぐ)レイヤーであると言える。つまり、オプティマイザにとっての至上命題は、如何に効率良く下位のレイヤーを使うというものであると言える。一方、下位のレイヤーであるストレージエンジンはまさに実装（物理）の領域である。ユーザーが必要とするクエリに対していかに素早く応答するかが、物理レイヤーたるInnoDBのチューニングにおける最終目標となる。 物理レイヤーのチューニングをするには、そのアーキテクチャを知ることが何よりも重要だ。アーキテクチャこそが物理レイヤーそのものだと言っても過言ではないからだ。以下では、チューニングを行う上で必須となる、基本的な構成部品について説明
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
