MySQLのスロークエリを調査して、APIのレスポンスタイムを5分から20秒に改善した話 - freee Developers Hub

こんにちは。freee請求書エンジニアのshunです。 24卒未経験でfreeeに入社し、freee請求書プロダクトの開発を行っています。 この記事では、先日行ったAPIのスロークエリの改善について紹介します。 APIのエンドポイントで発生していた約5分のスロークエリを、原因調査からMySQLオプティマイザの挙動の読み解きまで行い、20秒まで短縮しました。 「SQL単体では正しそうなのに実行計画が壊れる」「オプティマイザが期待と違うインデックスを選んでしまう」というのは、地味ですがよく遭遇するテーマだと思います。最近はMCP経由でAIエージェントがAPIを叩くようにもなってきており、APIのパフォーマンスはこれまで以上に重要になっています。 なお、以降で登場するテーブル名・カラム名・SQLに出てくる日付や事業所IDなどの値は、記事のわかりやすさを優先して例示用の汎用的なものに置き換えていま

[yamadadadada2]

5分もかかるクエリ投げててよく無事だったな

[hdampty7]

この手の話って基本的にチューニング以前に再現環境を用意できるかどうかが勝負みたいなところあるよね。４千万件入っててオプティマイザの動きまで再現できる環境って結構大変。クエリだけならレプリカでいけるけど

[taruhachi]

レスポンスが5分になる前に対策打つやろ、、、。逆にどんだけリソースに余裕があるんだ、、、。

[jukuringo]

リスク高そうなところはヒント活用したほうが無難だと思うけどなぁ。条件に修正入ったり、カーディナリティが変わるといくらでも問題になるし。

[ilya]

2026-07-14

[tkdtkd77]

“EXPLAIN ANALYZE”

[kenzy_n]

検証と改善

[sylow]

このDB設計じゃchildrenのcompany_id条件のある無しで意味が違ってくるのだから分析どうこう以前の話では？

[komutan1]

ポスグレのExplain結果だと思ってたらMySQL8からこれ出せるのね。読みやすい。

[nguyen-oi]

MySQLあるあるすぎる。ORDER BY LIMITでオプティマイザが狂ってPKフルスキャンするやつ