MySQL アトミックオペレーション

昨日の
「RDBでレコードロックしなくともうまく排他制御できる場合がある」
の記事に補足します。

「レコードロック排他制御の必要はなくなる」
と書きましたが、
念のため補足しますと、
「MySQLのMyISAM形式のテーブルでの話し」
ということです。
------------------------------------------------------

私が、いろいろやって来た経験で、
自分で発見したつもりでいましたが、
検索をすると
MySQLの最新日本語マニュアルの

1.8.5.3. トランザクションとアトミックオペレーション

に似たような話(そしてさらに詳しい話)があります。

---------------------------------------------------

MySQLの最新日本語マニュアルは、
内容が難しく、しかも翻訳なので、
私には意味がとりにくいのですが
多分昨日の記事の方法が正しいという意味が
書いてあると思います。

------------------------------------------------------
MySQLの最新日本語マニュアルの
「アトミックな更新」という意味について
説明がなく、なかなか理解ができないのですが、、、

プログラミングの技術としては、

アトミック = アトム(原子) + ミック(のような)

ということで、
マルチタスク環境でも、
原子のようにこれ以上分解されないひとつのかたまりとして
処理される単位の更新処理という意味と推測しています。
---------------------------------------------------

MySQLには、「InnoDBトランザクション・ストレージ・エンジン」という物もあり
これは、高機能(トランザクション、つまり、ROLLBACK をサポート)だけども遅いそうです。

MySQLでは、非トランザクション・ストレージ・エンジン（MyISAM など）を
使うことが一般的です。

「MyISAM テーブルは事実上、常に AUTOCOMMIT=1モードで動作する」そうです。
これは、「INSERT, UPDATE, DELETE は、常にその場で処理が完了(COMMIT)される」
という意味です。

---------------------------------------------------
でも、注意が必要なことがあります。
私が主張する方法(昨日の記事)は、適用範囲があり
万能ではないということです。

私の過去の経験では、ROLLBACKが必要なようなことは幸い無かったのです。

多分、
- ROLLBACKを使わなくともよいように、整合性の取れた美しいテーブル設計であった。
- ROLLBACKが始めからないMyISAMを使っている。
- LOCK TABLES を極力回避できるようにシンプルさを維持する工夫をしてきた。
などが、原因と思います。

でも逆の見方をすると、
ただ単に、簡単なアプリしか組んでいないという
意味かもしれません。

---------------------------------------------------

では、これにて失礼します。