MySQLロックについて〜基礎編〜 を開催しました！ - ANDPAD Tech Blog
こんにちは！エンジニアの福間（fkm_y）です。 先日、弊社でデータベースの技術顧問をして頂いてる三谷（mita2）さんに開発部向けのMySQLロックのデータベース勉強会を実施したのでそのレポートをお伝えします。 開催背景 弊社では三谷さんによるデータベース勉強会を定期的に開催しています。以前にもロックに関するMySQL勉強会を開催していたのですが、1年半経過しており参加していない開発メンバーのほうが多くなっていたことやプロダクトの成長によりデッドロックなどのロックに起因する問題が目立ち始めていたことから増強版のMySQLロックのデータベース勉強会を開催することになりました。 概要 データベースのロックについて ロックタイムアウトについて デッドロックについて まとめ データベースのロックについて なぜデータベースにロック機構があるのかから知ることが重要です。性能と安全性を両立するためにあ
MySQLでカラム追加などのalter table中にクエリがブロックされるかなどについてのメモ - だいたいよくわからないブログ
これは何 MySQLのカラム追加などのDDL, alter table時にそれぞれの操作がどれくらい危険なのか、負荷は？といった情報の見方を毎回忘れるのでメモしたもの まとめ 表を見なくても ALTER TABLE の末尾に ALGORITHM=INPLACE,LOCK=NONE; をつけてしまえば、動作を決められる（不可能な場合はエラーになる）ので、それで実験してみるとよい 公式document に詳細に記載があるのでそれを見ると良い。 ただし必ずしもその表通りになるわけではないため表の下に記載されている注意書きをよく読む必要がある。 例えば varcharのサイズ変更 = Extending VARCHAR column size は表内では INPLACE=yes と記載されているが length を 255 から 256 に拡張する場合は ALGORITHM=COPY しか利用でき
makopi23のブログ 「外部キー Night」に参加しました
2015/2/13(金) 「外部キー Night」に参加してきました。 connpass http://connpass.com/event/11463/ 場所は千駄ヶ谷（代々木）のピクシブ株式会社さんです。 参加者は60人くらいでしょうか。 ・・・この勉強会のタイトル！そしてピンポイントなテーマｗ 惹きつけられずにはいられない！ そんな私も、SQLアンチパターン読書会で4章「キーレスエントリ」の紹介を担当したということもあり、外部キーには少し思い入れがある一人なのです。 外部キーNightのお供に、書籍「SQLアンチパターン」の４章、「キーレスエントリー」をお一つ、いかがですか～ / SQLアンチパターン読書会 「キーレスエントリー」 に参加しました http://t.co/Z116mYUDyI #sqlap #fk_night — makopi23 (@makopi23) 2015,
MySQLのロックについて - SH2の日記
JPOUG> SET EVENTS 20140907 | Japan Oracle User Group (JPOUG)に参加して発表をしてきました。IIJさまのセミナルームは窓からの眺めがすばらしいですね。JPOUGの運営メンバのみなさま、会場を提供してくださったIIJのみなさま、当日お越しいただいたみなさま、どうもありがとうございました。 私のセッションでは「MySQLのロックについて」と題してネクストキーロックなどの説明をしました。プレゼンテーション資料と、調査のために作成したツールを公開します。 プレゼンテーション資料 (PDF) Lock Inspector 1.0 プレゼンテーション資料からリンクしているウェブサイトの一覧です。 MySQL Lists: mysql: Re: InnoDB's inner workings + checkpoints 過去記事の訂正 @kami
スマートロックの天敵「マンションのオートロック」も鍵なしでスマホから開けられるようにしてみた
家の鍵ってマジで失くしませんか？ 私事ですが、僕はよくモノを失くす人間で、パスモなんて月1で失くすし、前職でも社員証とか社用携帯とか失くしまくって始末書めっちゃ書いたのがいい思い出です。 どうりで1回も昇給しなかったわけだ。 この前順調に今年に入って2回目の鍵の紛失をした僕は、ついに鍵にMAMORIOという忘れ物防止タグをつけました。 MAMORIO S マモリオ エス Black&Black 世界最軽・最小・最薄クラスの紛失防止タグ/Bluetooth/ 逆に今までなんでつけなかったかというと「鍵とあたってカチカチする」からで、というかそもそもなんでそんなに鍵を失くすのかというと、 カバンに鍵をいれると毎回出し入れがめんどくさいから鍵はポケットに入れる ポケットに入れると他のスマホとかの出し入れの際に引っかかってよく落ちる コートとかをハンガーにかけるクセがなくて、雑にポイと置いてしまう
トランザクションについて(SELECT FOR UPDATE） | ケーワン・エンタープライズStaffブログ
今回は、SELECT FOR UPDATE時のトランザクションの挙動を確認したいと思います(｀･ω･´)ゞﾋﾞｼｯ!! その前に前回のトランザクションを読んでない人は読んでからの方が理解しやすいと思われます(； ･`д･´) こちらになります。 ・トランザクションについて ・ランザクションについて(その２） ■下準備 同じMySQLサーバーに別々のコンソールからログインして２つ開きます。 （以下、コンソールA、コンソールBとします。） データベースにはMySQLのデフォルトで作られているtestを利用して、 テーブルはuserというテーブルを作って利用します。； テーブル定義は次のものを利用しています。 CREATE TABLE `user` ( `id` int(11) NOT NULL AUTO_INCREMENT, `mail_address` varchar(255) DEFAUL
MySQLでSELECT FOR UPDATEと行ロックの挙動を検証してみた - Continue(s)
どうも、今日も今日とて野毛で飲みながらブログを書いている@0kawaraです。 今日は、普段あまり意識してこなかったMySQLのInnoDBでのロックの振る舞いについて色々実験してみました。（もちろん、きっかは自分がドツボにはまったから） ちゃんと理解するためには「共有・排他的ロックとは」って話や、「行ロックってつまりインデックスレコードロックだよね」などの話とか理解する必要があるんですが、それは github.com をちゃんと一読してもらえれば十分かと思います。 （というか、これが問題なく読めて理解できる人はこの記事読む必要ない….） 以下は上のドキュメント含め関連する記事などを読んで自分でInnoDBの行ロック周りについて、というかSELECT FOR UPDATEについて理解を深めるために手元で実験したことのまとめです。 技術的にちゃんとした理解を深めたい人は最後にまとめた参考サイ
楽観的ロックと悲観的ロックについて。 Kaname's hackday
楽観的ロック、悲観的ロック。 更新時のロック手法として使われているもの。 悲観的ロックの場合。 悲観的ロックは「一つのリソースを同時に更新することが頻繁にありうる場合」に利用する。 具体的には、更新のための参照をした時点でロックをかける（SELECT FOR UPDATEとか） ロック中は別処理では更新できないため、整合性が保たれる。 ただし、処理件数が多いと、その分ロックの時間も増えるため注意も必要。 楽観的ロックの場合。 楽観的ロックは「一つのリソースを同時に更新することはほとんどない場合」に利用する。 具体的には、レコードに更新日時などを持たせておき、 １．参照時に更新日時もを取得 ２．更新時の条件句に更新日時を指定し、処理中に更新がないことを確認して更新実施。 悲観的ロックよりも簡単にロックができるが、名前のとおり安全性は悲観的のほうが高い。 楽観的とか悲観的とかなんか嫌だな。つっ
ALTER TABLEを上手に使いこなそう。
テーブル定義を変更したい。インデックスが壊れてしまったので再作成したい。そんな場合はALTER TABLEを使う。ALTER TABLEはテーブル定義を変更するお馴染みのコマンドであるが、その挙動は意外と知られていない。（エキスパートとおぼしき方々からも度々質問を受ける。）そんなわけで、今日はALTER TABLEについて解説しようと思う。 まず結論から言うと、なんとMySQLのALTER TABLEはテーブルのデータを全てコピーし直すのである。なんて無駄なことを！？と思うかも知れないが、テーブル定義（スキーマ）の変更を動的に行うには、ストレージエンジンによるサポートが必要であり、動的なスキーマ変更をサポートしているストレージエンジンはまだ少ないのである。（動的スキーマ変更をサポートしているのはMySQL Clusterぐらいだ。しかも追加だけ。）デフォルトで利用出来るMyISAMはInn
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
データの同時更新を防ぐための排他制御