Popular posts
-
はじめに — なぜロック挙動を「実測」するのか
MySQL の InnoDB ロック挙動は「なんとなく知っている」エンジニアは多いが、実際に
performance_schema.data_locksで確認したことのある人は少ない。ドキュメントを読むと「REPEATABLE READ では Gap Lock が取得される」と書いてある。しかし：
- どの LOCK_MODE でどのレコードにロックが設定されるか
- READ UNCOMMITTED と READ COMMITTED で Gap Lock 挙動は実際に違うのか
- Gap Lock デッドロックはどんな SQL で発生するか
これらを曖昧なまま使い続けると、本番でのロック待ちタイムアウトやデッドロックの原因解析ができない。本記事では MySQL 8.0.45（devbox 環境）を使い、すべての仮説を
performance_schemaで実証した結果を記録する。
環境・テストテーブル設計
MySQL バージョン: 8.0.45（devbox mysql80@latest） innodb_autoinc_lock_mode: 1（consecutive） デフォルト分離レベル: REPEATABLE-READテストテーブル
CREATE TABLE products ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(100), category_id INT, INDEX idx_category (category_id) ); -- テストデータ（id: 10, 20, 30, 40, 50） INSERT INTO products VALUES (10, 'A', 10), (20, 'B', 10), (30, 'C', 20), (40, 'D', 30), (50, 'E', 30);ロック確認クエリ
SELECT l.OBJECT_NAME, l.INDEX_NAME, l.LOCK_TYPE, l.LOCK_MODE, l.LOCK_DATA, t.TRX_ID, t.TRX_STATE FROM performance_schema.data_locks l JOIN information_schema.INNODB_TRX t ON l.ENGINE_TRANSACTION_ID = t.TRX_ID ORDER BY l.ENGINE_TRANSACTION_ID, l.LOCK_TYPE DESC, l.LOCK_DATA;
ロック種類と LOCK_MODE 対応表
performance_schema.data_locksのLOCK_MODEカラムで識別できるロック種類： -
MySQL 8.4 vs PostgreSQL 17 パフォーマンス比較 (2025年版)
TL;DR
PostgreSQLが急速に進化し、MySQLとの性能差が拡大中。 OLTP性能でもPostgreSQLがMySQLに追いつき、信頼性・拡張性では大きくリード。
1. 実測ベンチマーク
検証環境
項目 値 ホストOS Ubuntu 24.04 LTS (WSL2) カーネル 6.6.87.2-microsoft-standard-WSL2 CPU AMD (8コア制限、Docker) メモリ 16GB (Docker制限) ストレージ tmpfs (インメモリ) Docker Engine 28.2.2 データベースバージョン
DB イメージ バージョン MySQL mysql:8.48.4.8 PostgreSQL postgres:1717.1 ベンチマークツール
項目 値 ツール sysbench 1.1.0 イメージ perconalab/sysbenchLuaJIT 2.1.0-beta3 テストスクリプト /usr/share/sysbench/oltp_read_write.luaテストパラメータ
--threads=4 # 並列スレッド数 --tables=4 # テーブル数 --table-size=10000 # 各テーブルの行数 --time=30 # 実行時間（秒）
2. ベンチマーク結果（生データ）
MySQL 8.4.8 結果
sysbench 1.1.0 (using bundled LuaJIT 2.1.0-beta3) Running the test with following options: Number of threads: 4 SQL statistics: queries performed: read: 438,914 write: 125,404 other: 62,702 total: 627,020 transactions: 31,351 (1,044.92 per sec.) queries: 627,020 (20,898.46 per sec.) ignored errors: 0 (0.00 per sec.) reconnects: 0 (0.00 per sec.) Throughput: events/s (eps): 1,044.9229 time elapsed: 30.0032s total number of events: 31,351 Latency (ms): min: 2.68 avg: 3.83 max: 14.56 95th percentile: 4.49 sum: 119,956.08 Threads fairness: events (avg/stddev): 7,837.7500/13.10 execution time (avg/stddev): 29.9890/0.00PostgreSQL 17.1 結果
sysbench 1.1.0 (using bundled LuaJIT 2.1.0-beta3) Running the test with following options: Number of threads: 4 SQL statistics: queries performed: read: 591,836 write: 169,088 other: 84,550 total: 845,474 transactions: 42,271 (1,408.94 per sec.) queries: 845,474 (28,180.66 per sec.) ignored errors: 3 (0.10 per sec.) reconnects: 0 (0.00 per sec.) Throughput: events/s (eps): 1,408.9432 time elapsed: 30.0019s total number of events: 42,271 Latency (ms): min: 2.22 avg: 2.84 max: 7.86 95th percentile: 3.55 sum: 119,953.49 Threads fairness: events (avg/stddev): 10,567.7500/7.69 execution time (avg/stddev): 29.9884/0.00
3. 結果分析
サマリー比較
指標 MySQL 8.4 PostgreSQL 17 差分 勝者 TPS 1,044.92 1,408.94 +34.8% 🐘 PG QPS 20,898.46 28,180.66 +34.8% 🐘 PG Read queries 438,914 591,836 +34.8% 🐘 PG Write queries 125,404 169,088 +34.8% 🐘 PG Latency (avg) 3.83ms 2.84ms -25.8% 🐘 PG Latency (min) 2.68ms 2.22ms -17.2% 🐘 PG Latency (max) 14.56ms 7.86ms -46.0% 🐘 PG Latency (95th) 4.49ms 3.55ms -20.9% 🐘 PG Thread fairness (stddev) 13.10 7.69 -41.3% 🐘 PG 詳細分析
スループット
- PostgreSQLは30秒間で 42,271トランザクション を処理
- MySQLは同条件で 31,351トランザクション を処理
- 差: 10,920トランザクション (PostgreSQLが34.8%多い)
レイテンシ分布
- PostgreSQLの最大レイテンシは 7.86ms
- MySQLの最大レイテンシは 14.56ms
- PostgreSQLはテイル（外れ値）が 46%小さい = より安定
スレッド公平性
- PostgreSQLの標準偏差: 7.69 (より均一な負荷分散)
- MySQLの標準偏差: 13.10 (負荷のばらつきが大きい)
4. 外部ベンチマーク結果
BinaryIgor氏のベンチマーク (2026年1月)
環境:
-
2025年の振り返り
仕事・キャリア編
転職したぞ!
2025年、いきなり大きな変化からスタートした。転職である。
新しい職場に飛び込んで、最初の仕事が「え、これエンジニアの仕事か!?」みたいな感じのタスクで、正直ちょっと戸惑った。でもやってみたら意外と楽しかったんだよね。エンジニアって技術だけじゃなくて、いろんなことやるもんなんだなって。こういう働き方もありだなと思えたのは良かった。視野が広がった感じがする。
技術書読んだ(最初は)
転職したタイミングで「よし、これを機に勉強しよう!」と思って、技術書を何冊か買った。新しい環境に慣れるためにも、知識をアップデートするためにも、いい機会だと思ったんだよね。
特に印象に残ってるのはGitHub Actionsの本。CI/CDとか普段使ってはいたけど、ちゃんと体系的に学んだことなかったから、結構知らないこととか細かいテクニックとかあって、読んでよかったなって思った。実務でも活かせる知識が増えた。
あと、ネットワーク系の本も読み始めた。「なぜインターネットはつながるのか」みたいなタイトルのやつ。基礎的なことだけど、改めて学び直すのも大事だよなって。
…ただ、最近は全然読めてない。積読が増える一方である。忙しいとか疲れてるとか、いろいろ理由はあるけど、まあ要するにサボってる。来年はもうちょっと読書時間確保したいな。
企業イベントにも行ってみた
どっかの企業がやってるイベントに1回だけ参加してみた。
ただこれがちょっと失敗で、転職者向けのイベントだったんだよね。俺もう転職したばっかりだし、またすぐ転職する気もないし、正直場違いだった。「誰でもOK」みたいなこと書いてあったから行ったんだけど、行ってみたら「あ、これ転職考えてる人向けだわ…」ってなった。まあでも雰囲気は知れたから良しとする。
仕事はやっぱり完璧じゃない
頑張ってはいるんだけど、やっぱやらかすときもあるんだよな。これがまた悲しい。
詳細は書かないけど(書けないけど)、「あ、やっちまった…」ってなる瞬間が何回かあった。**おれはぽんこつだ。**これは事実。でもまあ、失敗から学ぶこともあるし、次に活かせればいいかなって前向きに考えるようにしてる。ポジティブシンキング大事。
AI、マジですごい
転職してから、AIを触りまくるようになった。というか、仕事でもプライベートでもAI使いまくってる。
AIをいかに活用するかが、まじで今後に関わってくるんだろうなって本気で思ってる。技術的な問題解決はもちろん、アイデア出しとか、コードレビューとか、ドキュメント作成とか、とにかくいろんなところで使える。
この振り返り文章を書いてる間も、裏でClaudeにコード書いてもらってるし。もうAI無しの生活は考えられないレベル。来年はもっとAI活用の幅を広げていきたいな。
プライベート編
VRChat最高
VRChatがマジで楽しい。
一人でフラフラするのも楽しいけど、やっぱり人と一緒にやるのがいいんだよね。ワールド巡ったり、イベント参加したり、ただ話してるだけでも楽しい。VR空間だとなんかテンション上がるし、現実では会えない人とも気軽に交流できるのがいい。
来年もVRChat続けると思う。というか、もうライフスタイルの一部になってる気がする。
リアル友達とは会ってない…
今年を振り返ってみたら、リアル友達と誰とも会ってない気がする。
コロナも落ち着いたし、会おうと思えば会えたんだろうけど、なんかタイミング合わなかったり、お互い忙しかったり。VRChatで新しいつながりができた分、リアルの付き合いが薄くなってるのかもしれない。これはちょっと反省点かな。
あと、狂気山脈のリアル脱出ゲームに行く予定だったんだけど、完全に忘れてて行かなかった。申し訳ない。スケジュール管理ちゃんとしないとダメだな。
音楽は好きだけど、ライブは…
かみつばきとか、好きなアーティストへの熱が**ちょっと冷めてきたのかな?**って感じる。
音楽自体は変わらず好きで、普段から聴いてる。でも、**ライブに行くモチベーションが下がってきた。**現地はもう体力的にきついし(歳を感じる…)、配信も見なくなっちゃった。集中して見るのが難しいというか、他のことしながらじゃないと無理みたいな。
でも**音楽は好き。**これは変わらない。ただ楽しみ方が変わってきたのかもしれない。ライブに行かなくても、音楽は楽しめるしね。
周りに良いことがあった
自分のことじゃないんだけど、周りに良いことがいくつかあって、それが嬉しかった。
詳細は書かないけど、友達とか知り合いとかに良いことがあると、自分のことのように嬉しくなるよね。**良き。**本当に良き。こういう喜びを感じられるのって、人とのつながりがあるからだなって思う。
購入物・ガジェット編
Kindle買いすぎ問題
**Kindle買いすぎ。**これはマジで反省しないといけない。
セールとか見ると、「あ、これ安い!」ってついポチってしまう。シリーズものとか、「便利そう」って思ったら全巻まとめ買いしちゃう。読む時間がないのに買っちゃう。積読が増える。このループ。
来年は控えたい。(控えられるかは不明)
でもKindleって便利なんだよな…セールの誘惑に負けないようにしないと。
無線マウス最高
Amazonで無線マウスを買った。これがマジで買ってよかった。
**充電から解放されるのさいこー!**有線マウスって、ケーブルが邪魔だったり、充電気にしないといけなかったり、地味にストレスだったんだよね。無線にしたら快適すぎて、もう戻れない。
買ったのはこれ:
デスク周りがスッキリして、作業効率も上がった気がする。まあ気がするだけかもしれないけど。
年末に新PC購入
そして年末の大きな買い物が、新しいPC!
さいこー!=
スペックアップして、快適すぎる。重い処理もサクサク動くし、マルチタスクも余裕。前のPCも悪くなかったけど、新しいのはやっぱり違うね。これでまた数年は戦える。
年末に自分へのご褒美として買ったけど、めちゃくちゃ満足してる。来年はこのPCでいろいろ作りたいな。
総評
2025年は、転職という大きな変化があった1年。
仕事では新しい環境に挑戦して、AI活用が一気に加速した。失敗もあったけど、学ぶことも多かった。プライベートではVRChatという新しい楽しみを見つけて、人とのつながりの形が変わってきた。
リアルの友達とあまり会えなかったのは反省点だけど、新しい形のコミュニケーションも悪くないなって思える年だった。
音楽への向き合い方が変わったり、ガジェット買いまくったり、いろいろあったけど、総じて良い年だったんじゃないかな。
来年もこの調子で、新しいことにチャレンジしつつ、楽しんでいきたい。
2026年も頑張るぞ!
-
PHP8.5がくるらしい
TL;DR
これを読みなさい
https://stitcher.io/blog/new-in-php-85
パイプ演算子
$input = ' Some kind of string. '; $output = strtolower( str_replace(['.', '/', '…'], '', str_replace(' ', '-', trim($input) ) ) );↓
$output = $input |> trim(...) |> (fn (string $string) => str_replace(' ', '-', $string)) |> (fn (string $string) => str_replace(['.', '/', '…'], '', $string)) |> strtolower(...);おしゃれ ただ結果記述長くなる場合がありそうだし、phpの->methodみたいに呼出すのをヘルパーとかでやるのはどうなんだろ 好みが分かれそう
Clone with
final class Book { public function __construct( public string $title, public string $description, ) {} public function withTitle(string $title): self { return clone($this, [ 'title' => $title, ]); } }🙄
new selfとくらべてなにがいんだろう
-
【嘘】docker compose で ファイルとしてマウントする方法
結果から
けつに :ro つけるだけ
services: backend: image: awesome/backend volumes: - .env.local:.env:ro# # #
-
docker compose で ファイルとしてマウントする方法
結果から
けつに :ro つけるだけ
services: backend: image: awesome/backend volumes: - .env.local:.env:ro# # #