タグ

トランザクションに関するchanpon0のブックマーク (7)

  • InnoDBのREPEATABLE READにおけるLocking Readについての注意点

    日は、MySQL Casual Advent Calendar 2013の20日目である。というわけでカジュアルに小ネタを紹介しよう。 MVCC - Multi Version Concurrency Controlご存知の通り、InnoDBはMVCCを実装している。そのため、分離レベルがREPEATABLE READの場合には、行にロックをかけることなく、一貫した読み取りが可能になっている。 もし、あるトランザクションT1開始後に、別のトランザクションT2によって同じ行が書き換えられてしまった場合には、T1はロールバックセグメントにある古いバージョンの値を読み取ることができるので、T1内で実行したSELECTは常にT1開始時点のデータを参照することができるのである。大事なのでもう一度言うが、REPEATABLE READにおける単純なSELECTでは行ロックは必要ない。 Lost Up

    InnoDBのREPEATABLE READにおけるLocking Readについての注意点
  • MySQL :: MySQL 8.0 リファレンスマニュアル :: 15.7.2.3 一貫性非ロック読み取り

    一貫性読み取りとは、InnoDB がマルチバージョンを使用して、ある時点でのデータベースのスナップショットをクエリーに提供することを意味します。 クエリーには、その時点よりも前にコミットされたトランザクションによる変更のみが表示され、その時点よりもあとのトランザクションまたはコミットされていないトランザクションによる変更は表示されません。 このルールの例外として、同じトランザクション内の以前のステートメントによる変更はクエリーに表示されます。 この例外によって、次のような異常が発生します。テーブル内の一部の行を更新すると、更新された行の最新バージョンが SELECT に表示されますが、いずれかの行の旧バージョンも表示される可能性があります。 その他のセッションで同じテーブルが同時に更新される場合、その異常は、データベースに存在しない状態でテーブルが表示される可能性があることを意味します。

    chanpon0
    chanpon0 2013/09/05
    トランザクション中は、同じselectデータを得る。別トランザクションでcommitされていても。for updateしましょう。
  • ke-tai.org > Blog Archive > MySQLとPostgreSQLのRepeatable Read時の挙動の違いについて

    MySQLとPostgreSQLのRepeatable Read時の挙動の違いについて Tweet 2010/7/2 金曜日 matsui Posted in サーバ | 1 Comment » モバイルとは全く関係ないですが、自分のメモ代わりに記事にしてみたいと思います。 たまたまテストしていて、MySQLとPostgreSQLのRepeatable Read時の挙動の違いを見つけました。 AさんとBさんという二人のユーザが同時に一つのレコードを更新している場合です。 user_tblのuser_typeというカラムを「0」→「1」にアップデートしています。 分離レベルはMySQL、PostgreSQLともにRepeatable Readです。 Aさん Bさん mysql> begin; Query OK, 0 rows affected (0.00 sec) トランザクション開始 my

  • 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> SELECT @@global.tx_isolation; もしくは mysql> SELECT @@tx_isolation;

  • tree-tips: MySQLのトランザクション分離レベル | MySQL

    トランザクション分離レベルの種類 ANSI/ISO SQLでは、以下のように定義されています。 ロストアップデートについては特に策定されていないと思いますが、一覧に加えておきます。 分離レベル 性能 ダーティーリード ファジーリード ファントムリード ロストアップデート read uncommitted 高 起きる。 起きる。 起きる。 起きる。 read committed | 起きない。 起きる。 起きる。 起きる。 repeatable read | 起きない。 起きない。 起きる。 起きる。 serializable 低 起きない。 起きない。 起きない。 起きない。 ただし、ANSI/ISO SQLはあくまで仕様であって、実装・動作は各データベース毎に異なります。 MySQLの場合は以下のようになります。 分離レベル 性能 ダーティーリード ファジーリード ファントムリード ロス

  • MySQL :: MySQL 8.0 リファレンスマニュアル :: 15.7.2.4 読取りのロック

    データのクエリーを実行してから、同じトランザクション内で関連データを挿入または更新する場合は、通常の SELECT ステートメントで十分な保護が提供されません。 ほかのトランザクションは、クエリーが実行されたばかりの同じ行を更新または削除できます。 InnoDB では、追加の安全性が提供される 2 つのタイプのロック読み取りがサポートされています。 SELECT ... FOR SHARE 読み取られる行に共有モードロックを設定します。 ほかのセッションもその行を読み取ることができますが、トランザクションがコミットするまで変更することはできません。 これらの行のいずれかがコミットされていない別のトランザクションによって変更された場合、クエリーはそのトランザクションが終了するまで待機してから、最新の値を使用します。 SELECT ... FOR SHARE は SELECT ... LOCK

    chanpon0
    chanpon0 2012/02/15
    こんなロックがあるのか。トランザクションじゃないと、Innodbじゃないと意味ないのかな。。
  • 1