【入門編】ロック競合と性能への影響 – PostgreSQL

こんにちは！データベースの世界へようこそ。

現場でバリバリとデータベースを触っていると、たまに「なんだか最近、サイトの動作が重いな……」なんて悩みにぶつかることがありますよね。原因を調べてみると、実は「ロック」が犯人だった、なんてことは日常茶飯事です。

今日は、初心者の方が意外と見落としがちな「ロック競合」について、難しい専門用語は抜きにして、私たちの身近な出来事に例えてお話ししますね。

—

データベースの「ロック」をイメージするときは、「大人気の行列ができるカフェのトイレ」を想像してみてください。

トイレが一つしかないとき、誰かが入っている間、次の人はドアの前で待たなければいけませんよね。データベースの世界でもこれと同じことが起きています。

あるデータ（行）を誰かが書き換えている間、PostgreSQLは「今書き換えてるから、ちょっと待っててね！」と他の人（クエリ）に鍵をかけるんです。これが「ロック」の正体です。

—

ここからが少し面白いところです。ロックには「粒度（りゅうど）」という考え方があります。簡単に言うと、「どれくらいの範囲を占領するか」です。

さっきのトイレの例です。「この一行だけ書き換えるから、この行だけ鍵をかけるね！」という状態。
これなら、別の行を使いたい人は待たされることなく、別のトイレ（行）を使えますよね。これが「粒度が細かい」状態です。効率がいいので、基本的にはPostgreSQLもこれを目指して頑張ります。

一方で、もっと豪快なロックもあります。「このテーブル全体をメンテナンスするから、全員入っちゃダメ！」という、建物全体の入り口に鍵をかけるようなもの。
これだと、たとえ空いている個室があっても、誰一人として入れません。これが「粒度が荒い」状態です。

—

「ロック」自体は、データがぐちゃぐちゃにならないように守るための大切な仕組みです。でも、これが多すぎたり、範囲が広すぎたりすると、困ったことが起きます。

「渋滞」の発生： みんなが同じデータにアクセスしようとすると、行列がどんどん長くなります。
「待ちぼうけ」による遅延： クエリの実行時間は、実際に計算している時間よりも、「前の人のロックが解除されるのを待っている時間」の方が長くなることがよくあります。

初心者のうちは、「クエリが遅い＝計算が複雑だからだ」と思いがちですが、実は「どこかで誰かが鍵を握りしめたまま離さないから、みんなが止まっているだけ」というケースが本当に多いんです。

—

データベースと上手に付き合うために、まずはこれだけ意識してみてください。

「短時間で終わらせる」: 鍵をかける時間は短いほどいいです。重い処理は先に準備をしておいて、実際にデータを書き換える瞬間だけロックをかけるようにしましょう。
「必要な分だけロックする」: 「念のためテーブル全体をロックしちゃおう」と考えるのはNG。できるだけ「この行だけ」という狭い範囲を狙うのがプロの技です。
「トランザクションを短く」: 「トランザクション（一連の作業）」の中に、データベースに関係ない重い計算や、外部への通信を混ぜないこと。作業が終わるまで鍵はかかりっぱなしになりますからね！

—

データベースのロックは、いわば「譲り合いのルール」です。

性能が悪いと感じたときは、ぜひ「いま、誰かがトイレのドアを閉めっぱなしにしていないかな？」と想像してみてください。その視点を持つだけで、あなたの書くクエリはぐっと洗練されたものになりますよ。

また次回も、データベースの面白い裏側についてお話ししますね。それでは、また！