タグ

innodbに関するfagaiのブックマーク (5)

  • VOYAGE GROUP エンジニアブログ : MySQL InnoDBのinsertとlockの話

    2015年03月08日17:06 カテゴリ MySQL InnoDBのinsertとlockの話 こんにちは。ECナビでアプリケーションエンジニアをやっている駒崎です。 今回はMySQLのInnoDBエンジンにおけるINSERTとロックの挙動について書きたいと思います。 はじめに アプリケーションでレコードの重複チェックをしてからINSERTをする。テーブルにはUNIQUE制約をかけてデータ不整合が起きないようにしている。という仕様はよくあるケースだと思います。 こういったケースでINSERTしたときにどのような仕組みが働いて重複データを防いでいるのだろう?アプリケーションで重複チェックをしてはいるけどMySQLではどんな挙動をしているんだろう?というのが気になったので調べました。 調べること INSERTした場合のロックの挙動 FOR UPDATE文で排他ロックをかけた場合のロックの挙動

  • MySQL/MariaDBとTransactdのInnoDBロック制御詳細 その1 - BizStationブログ

    今回から数回にわたり、TransactdのオペレーションとInnoDBにおけるロックについて解説します。 ロックについてはあまり良くわからなくてもとりあえずそれなりに動くアプリケーションは作れてしまいます。ですが、マルチユーザー環境でミッションクリティカルなアプリケーションを書くには、ロックの理解が不可欠です。ロックをうまく使って、矛盾や間違いのない読み書きをしつつ同時実行性も高いアプリケーションにしましょう。 その1では、Transactdを実装する上でMySQLのソースやドキュメントから得た知見を基に、InnoDBのロックの種類と分離レベルに応じてそれをどのように使うかをまとめてみます。 Index MySQLのトランザクション関連用語 MySQLのREPEATABLE-READ InnoDBのロック 行ロック (row-level locking) GAPロック GAPロック単体 ネ

    MySQL/MariaDBとTransactdのInnoDBロック制御詳細 その1 - BizStationブログ
  • MySQLのメモリ使用量に関するトラブルシューティングTips | Yakst

    MySQLが確保する各種メモリに関するパラメータの概要から、それらがどのように割り当てられるのかを知るための様々な手法まで、Perconaのサポートエンジニアが詳しく解説する。 January 24, 2014 By Nilnandan Joshi 「MySQLサーバのメモリ使用量」に関連するトピックスを書いたブログ記事は既にたくさんあるにも関わらず、MySQLのメモリ関連の問題のトラブルシューティングで混乱しなかった人はいないだろう。Perconaサポートのエンジニアとして、高負荷のサーバに関することや、メモリ使用量高騰でOOM killerが発動してMySQLサーバが停止したこと、あるいは「MySQLがどうしてこんなにメモリをうのか分からない。どうやったら何にメモリが使われてるか分かるんだ?助けてくれ!」と言った問題を数多く見ている。 MySQLのメモリ使用量をチェックする方法はたく

    MySQLのメモリ使用量に関するトラブルシューティングTips | Yakst
  • MySQLの行ロックのふしぎ挙動で夜も安心して眠れない | 三鷹台でひきこもるプログラマの日記

    MySQLのびみょーな行ロックに悩まされたのでメモ代わりに。 全部MySQL5.5でInnoDB使っている時のお話デス。 こんなテーブルが有るとしますよ。 create table table001 ( id int primary key, name text ); そしてこんなデータが入っています。 A> select * from table001; +----+-----------------+ | id | name | +----+-----------------+ | 1 | 水瀬伊織 | | 2 | 伊織さま | | 3 | いおりん | | 4 | デコちゃん | +----+-----------------+ まあ、データの中身は気にしない方向で。 そんなアイマス好きのAさん。 伊織さまを「デコちゃん」呼ばわりしている id=4 が許せないので書き換えてやろうと決

  • MySQL InnoDBの行ロック - There's an echo in my head

    ロックがわからない。MySQL InnoDBの行レベルロックを読んだけど、イマイチわからない。というわけで、社内の勉強会で知ったことをまとめてみる。 FOR UPDATEかLOCK IN SHARE MODEによって、そのトランザクション中に走る別画面でのクエリの処理のタイミングが異なる。 FOR UPDATEによるロック まずは画面Aで接続が行われ、トランザクションが開始され、SELECT文が発行されたとする。 [画面A] BEGIN; // トランザクションA開始 SELECT * FROM users WHERE id = 1 FOR UPDATE; COMMIT; // トランザクションA終了 そしてトランザクションAの開始後〜終了前に画面B〜Dがクエリを発行したとする。 ちなみにトランザクションを開始しておかないとFOR UPDATEを書いても画面Aでのロックが始まらないので要注

    MySQL InnoDBの行ロック - There's an echo in my head
  • 1