MySQLの行ロックを図解 - QiitaDeleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
MySQLのEXPLAINを徹底解説!!
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ
MySQLでランダムにN件取得する方法のパフォーマンス比較 - しんふぉにゃん
こちらと同じような比較を自分でもやってみました。 私はMySQLに関してあまり深い知識を持っていないため、検証の方法や設定値の問題などがあるかもしれませんが、ざっくりとした傾向は分かるかと思います。 まず、今回使用しているテスト用環境のバージョン等です。 OS Fedora Core 7 MySQL 5.0.45 PHP 5.2.6 # やや古い・・・。 また、テストで使用するテーブルは以下のような簡単なものです。 ┌────┬───────┬───┐ │ 名前 │ 型 │サイズ│ ├────┼───────┼───┤ │ｉｄ │ｉｎｔ │ │主キー ├────┼───────┼───┤ │ｎａｍｅ│ｖａｒｃｈａｒ│ ６４│ └────┴───────┴───┘ まず今回テストした6つの方法を簡単に説明します。 (1) RAND()列を追加してソート 以下のようなSQL
MySQL InnoDBにおけるロック競合の解析手順 - SH2の日記
データベースの運用で避けられないのが、ロック競合によって起こるシステムトラブルへの対応です。「2時までに終わるはずのバッチ処理が朝になっても終わっていない」とか「負荷が高いわけでもないのにシステムが無応答になっている」といったトラブルが発生したとき、DBエンジニアはそれがロック競合によるものなのかどうかを切り分けて、適切に対処しなければなりません。 これまでInnoDBはロック競合に対してほとんど打つ手がなかったのですが、最近ようやく対処方法がでてきました。今日はその手順を確認していきたいと思います。 前提 今回ご紹介する手順は、MySQLの以下のバージョンを対象にしています。 MySQL 5.1＋InnoDB Plugin 1.0 MySQL 5.4 いきなりハードルを上げてしまって申し訳ありませんが、バージョン5.0以下や素の5.1では使えませんのでご注意ください。以降の実行例はすべて
MySQL InnoDBのネクストキーロック おさらい - SH2の日記
MySQLのInnoDBストレージエンジンは行ロックをサポートしています。しかしOracleと同じ感覚でアプリケーションを作っていると、思わぬところでデッドロックに出くわすことがあります。これはInnoDBのロック範囲がOracleよりも微妙に広いためです。 実際の例で確認してみましょう。 mysql> select * from t; +----+------+ | c1 | c2 | +----+------+ | 10 | a | | 15 | a | | 20 | a | | 25 | a | | 30 | a | | 35 | a | | 40 | a | | 45 | a | | 50 | a | +----+------+c1列は主キーになっています。1つめのセッションで以下のSQLを実行します。 mysql> set tx_isolation = 'repeatable-r
MySQLがおかしい！あなたならどうしますか？ – MySQL Casual Advent Calendar 2011 - As a Futurist...
しわっす！DBA 兼オペレーションエンジニア兼タスクマネージャやってる riywo です。何のネタを書こうかなぁと考えたのですが、正直ネタを仕込む時間もなかったので僕がいつもやってることをさらっと紹介するということで勘弁して下さい＞＜ MySQL がおかしい！ 03:14 hidek: なんかエラー出まくってるんだけど！ 03:14 zigorou: MySQL と通信してるとこっぽい 03:15 riywo: 見ます こんなやりとりは皆さん日常茶飯事ですよね？ね？ね？こんな時に、DB に責任を持つものとして真っ先に対応するのが僕らの仕事です。でも、じゃあ具体的にこのあと何をしましょう？既にサービスはエラーだらけで一刻を争う状態です。 (対応開始) まずはエラーメッセージ 今回の様な場合はアプリのエラーログにどばっと MySQL に関するエラーが出ているでしょう。まずはそれを見ることが始ま
MySQL :: MySQL 5.1 リファレンスマニュアル :: 13.5.10.3 InnoDB と TRANSACTION ISOLATION LEVEL
Section Navigation [Toggle] 13.5.10 InnoDB トランザクション モデルとロック13.5.10.1 InnoDB ロック モード 13.5.10.2 InnoDB と AUTOCOMMIT 13.5.10.3 InnoDB と TRANSACTION ISOLATION LEVEL 13.5.10.4 一貫非ロック読み取り 13.5.10.5 SELECT ... FOR UPDATE と SELECT ... LOCK IN SHARE MODE ロック読み取り 13.5.10.6 ネクスト キー ロック:バグの問題を防ぐ 13.5.10.7 InnoDB 内での一貫した読み取りの例 13.5.10.8 InnoDB 内で各種 SQL ステートメントによって設定されるロック 13.5.10.9 暗黙的なトランザクション コミットとロールバッ
MySQL :: MySQL 5.1 リファレンスマニュアル (オンラインヘルプ) :: 9.8.1 InnoDB ロックモード
共有 (S) ロックはトランザクションが行を読むことを許容します。 排他 (X) ロックはトランザクションが行を更新、削除することを許容します。 トランザクション T1 が行 r に対する共有 (S) ロックを保持している場合、別のトランザクション T2 からの行 r に対するロック要求は次のように処理されます。 もしトランザクション T1 が排他 (X) ロックを行 r 上で保持していたら、そのときは r 上のロックに対する独特なトランザクション T2 からのリクエストは直ちに認められません。代わりに、トランザクション T2 はトランザクション T1 が行 r 上でそのロックをリリースするのを待たなければいけません。 さらに、InnoDB はレコードロックの共存とテーブル全体のロックを許容する 複数粒度ロック をサポートします。複数粒度レベルでのロックを実用的にするために、インテンション
DBサーバーの負荷分散
MySQLアクセスを負荷分散する ユーザーからのアクセス数が非常に多いWebサイトにおいて、MySQLのSLAVEサーバーを複数台並べて負荷分散させるということがよく行われています。ただ、Webアクセスの負荷分散は一般的なテーマなのでいろいろなところで語られているのに対し、DBアクセスの負荷分散というテーマは一般的でないのかあまり語られていないように感じます。 DBアクセスを負荷分散するにあたって一番荒っぽい方法は、Webサーバー上のプログラムの中でどのSLAVEサーバーに接続するかをランダムで決める方法です。ランダムと言っても長時間アクセスしているとほぼ接続先が均等化されるので、一見この方法でも問題ないように見えます。しかしこの方法だと、接続しに行こうとしたSLAVEサーバーが高負荷もしくはサービス停止中であっても構わず接続しに行ってしまうという問題があります。 このような問題を解決する
はじめての MySQL で100万件のデータを管理する時に行ったチューニングまとめ
MySQL の勉強をせずにフレームワーク等で SQL を書かずに Web サイトを構築していました。データ数も2万件程度でしたので、そこまで困ることはありませんでしたが、今回100万弱の商品データを扱う機会ができたので、MySQL のチューニングや発行する SQL について見直す機会がありました。 この記事では MySQL を高速化するのに行った対策など勉強したものを自分用にメモしておきました。 条件式で比較するカラムにインデックスを使用して高速化 商品コードで存在しない商品を見つけて、商品をDBに登録するという処理を行っている場合、4万件超えたころから処理に2秒以上かかるようになってきます。12万件超えた頃には10秒程度かかるようになってしまいましたが、商品コードのフィールドに対してカラムインデックスを貼ることで0.2秒に短縮することができました。 MySQL のリファレンスにも以下のよ
phpMyAdminのsetup.phpの脆弱性を突くサイバー攻撃を確認 - Snufkinski Memo
ちょっとセキュリティ関連が続きますが、これはちょっとヤバイので公開メモ。 MySQLの管理インタフェースとしてphpMyAdminを利用されている方は多いと思いますが、 ここ数日、Apache の access_log に以下のような怪しげな痕跡があったので気になって調べてみました。 パターン１ GET //phpmyadmin/config/config.inc.php?p=phpinfo(); GET //pma/config/config.inc.php?p=phpinfo(); GET //admin/config/config.inc.php?p=phpinfo(); GET //dbadmin/config/config.inc.php?p=phpinfo(); GET //mysql/config/config.inc.php?p=phpinfo(); GET //php-m
基礎から理解するデータベースのしくみ（5）：ITpro
SQL文を実行する際のパフォーマンスに大きな影響を及ぼすものとして，もう一つ，インデックスがあります。インデックスについては，どう定義すべきかというデータベース設計上の問題と，インデックスを有効に使うためのSQL文をどう書くべきかというコーディング上の問題があります。 ここではテーブル設計上の問題を主に取り上げます。SQL文のコーディングについては囲み記事「SQL文を最速にする11のポイント」を参照してください。 インデックスは，テーブルの検索速度を向上させるためのものです。それぞれのSQL文に対して最適なインデックスを定義するのが理想的ですが，実際にはある程度限られたインデックスで，必要なパフォーマンス要件を満たすようにインデックスを定義する必要があります。加えて，どんなSQL文が実際に発行されるのかがあらかじめわかっていない場合は，適当な想定に基づいてインデックスを定義しておかなくては
MySQL :: MySQL 5.6 リファレンスマニュアル :: 14.2.3 InnoDB のロックモード
ロック読み取り (SELECT ... FOR UPDATE および SELECT ... LOCK IN SHARE MODE)
mysqlコマンドをより便利に安全にするための小粒なTIPS集｜サイバーエージェント 公式エンジニアブログ
初めまして。2010年の3月に入社した oinume です。新年1月からウィルス性胃腸炎に罹りながらもなんとかこのエントリーを書いています。今回は、mysqlコマンドに関する自分が今まで学んだ＆教えてもらった細かい実践的なTIPSを紹介します。小粒ですが何かの役に立てば幸いです。 edit (¥e)コマンド mysqlプロンプトにいながら任意のエディタでSQLが編集できちゃいます。具体的には、mysqlコマンドでプロンプト待ちの状態で mysql> edit のように edit または ¥e と入力すると、環境変数EDITORで設定してあるエディタが立ち上がりSQLが編集可能になります。編集が終わったらエディタを終了して ; とやればSQLが実行されます。viなどターミナルで動くエディタに慣れている人は長いSQLを編集する時に重宝する機能でしょう。この技は前職の同僚に教えてもらって、以降便
【レポート】PHPデベロッパがおかしがちな10のMySQL間違い | エンタープライズ | マイコミジャーナル
SitePoint: New Articles, Fresh Thinking for Web Developers and Designers PHPを使ってWebサイトやWebアプリケーションを構築する場合はデータベースも併用することが多い。そしてその場合に採用されることが多いデータベースのひとつにMySQLがある。PHPはすぐに利用できるようになるプログラミング言語といわれているが、MySQLやSQLはそうではない。堅牢で信頼できるデータベースを設計し、それを扱うSQLクエリを作成するにはそれなりの学習時間と経験が必要だ。 こうした話題がSitePointにおいてTop 10 MySQL Mistakes Made By PHP Developersとして掲載されている。PHPデベロッパが犯しがちな10のMySQLミステイクという内容になっている。どういった間違いをしてしまうか簡単に
mysqlのint(11)の11
MySQL Manual | 6.2.1 数値型 MySQL には、INT(4) のように、型の基本キーワードに続いて整数値の表示幅をかっこ内に指定できるオプションがあります。このオプションの表示幅の指定は、カラムに指定された幅より小さい幅を持つ値で表示の左側を埋める目的で使用されますが、そのカラムに格納できる値の範囲が制限されたり、そのカラムに指定された幅を超える幅を持つ値の桁数が制限されたりすることはありません。オプションの拡張属性 ZEROFILL と組み合せて使用した場合、デフォルトのスペースに代わってゼロが埋め込まれます。けっこう勘違いしている人がいそうなのですが、mysqlの型でint(?)とか、?に数字を入れますが、この数字は上記の通りZEROFILLをした際にスペースに代わってゼロが埋め込まれる際の幅なのです。自分は勘違いというかあまりよくわかっていませんでした…。 つまり
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Site Under Maintenance
大規模ソーシャルゲーム開発から学んだPHP＆MySQL実践テクニック
Good night, Posterous
MySQL Statement-based-replicationでの安全な関数 - まい・はうす