こんにちは。タイムリープ株式会社でエンジニアをやっております id:moznion です。 タイムリープには有史以来、データベースmigration機構が無いままに運用されているサーバーサイドアプリケーションがあり、エンジニアが気を付けてDDLを手で発行するという運用が為されていました。もちろんここには、 実際のデータベースを見に行かないと正しいテーブル構成がわからない スナップショット的なテーブル定義が記されたsqlファイルがrepository内にあったものの、それを実際に使っているわけではないので正しさが保証されない そのため、ローカル・CI用のデータベースを構築するのも一苦労 (というか正しさがわからない) 考えたDDLをマニュアルでDBに適用しなければならなかったので実に危険 誤りやオペミスが入り混む危険性がある そもそもデプロイ時にDDLの発行自体を忘れるという危険性もある そ
こんにちは。freee請求書エンジニアのshunです。 24卒未経験でfreeeに入社し、freee請求書プロダクトの開発を行っています。 この記事では、先日行ったAPIのスロークエリの改善について紹介します。 APIのエンドポイントで発生していた約5分のスロークエリを、原因調査からMySQLオプティマイザの挙動の読み解きまで行い、20秒まで短縮しました。 「SQL単体では正しそうなのに実行計画が壊れる」「オプティマイザが期待と違うインデックスを選んでしまう」というのは、地味ですがよく遭遇するテーマだと思います。最近はMCP経由でAIエージェントがAPIを叩くようにもなってきており、APIのパフォーマンスはこれまで以上に重要になっています。 なお、以降で登場するテーブル名・カラム名・SQLに出てくる日付や事業所IDなどの値は、記事のわかりやすさを優先して例示用の汎用的なものに置き換えていま
こんにちは！ 承認チームでGoエンジニアとしてインターンをしているunagamです。 最近は夏の旅行先として色々な場所を調べるのにハマっています。 今回はあまり馴染みのないSQLのLATERAL句で大幅にAPIを高速化できたので、その学びを共有したいと思います。 概要 APIのボトルネックだったSQLを、LATERAL を使って 94.7ms → 0.236ms（99.75%削減） まで短縮できた。 ただし LATERAL は無条件に速くなるわけではない。外側の行数に比例してコストが増えるという性質があり、条件次第では逆に遅くなる恐れがある。 それでも、リスクを理解した上で適用すれば、LATERAL は強力な改善策になり得る。 経緯 Datadogを用いて承認サーバーのAPIを監視していた際、一週間の合計処理時間が1.6日と他と比べて圧倒的に処理時間を消費しているAPIを見つけました。 処
RDBで木構造の深さを制限したいときの設計パターン はじめに RDBで親子関係を持つデータを扱うとき、隣接リストモデルはシンプルで扱いやすい選択肢です。 ただし、隣接リスト単体の一般的な制約だけでは「深さを最大2階層まで」といった制限を実現しにくいです。この記事では、深さ制限が必要になったときに取り得る設計パターンを3つ整理します。 対象読者は次のとおりです。 隣接リストモデルで木構造を管理しているが、深さを制限したくなった DB制約とアプリケーション制御のどちらで対応すべきか迷っている 設計パターンのトレードオフを把握しておきたい 隣接リストモデルの基本 課題やカテゴリなど、再帰的な親子関係を持つデータの設計として、隣接リストモデルがよく使われます。 CREATE TABLE tasks ( id BIGINT PRIMARY KEY, parent_id BIGINT NULL REF
株式会社ブレインパッドプロダクトユニットでRtoaster GenAIの開発をしている依田です。 今回は「LATERAL句を使うと、複雑なサブクエリがシンプルに書ける」という話を、実行可能なサンプルSQLつきでお伝えします。 はじめに データ分析でよく出てくるクエリのパターンに、「各グループの最新レコードを1件取得したい」「各カテゴリの上位N件だけ取り出したい」というものがあります。 こういった処理を書こうとすると、ウィンドウ関数や相関サブクエリを使った複雑なSQLになりがちです。LATERAL句を使うと、FROM句の左側の行ごとにサブクエリを実行できます。そのため、意図がはっきりした読みやすいSQLを書けます。 この記事で学べること LATERAL句の仕組みと使いどころ LATERAL未使用 vs LATERAL使用でどれだけ可読性が変わるか CROSS JOIN LATERAL と L
The design of SQL and relational database systems makes it easy to accidentally introduce serious concurrency bugs. Below is a textbook money-transfer procedure in TSQL; Alice wants to send ten dollars to Bob, and to keep Alice from overdrafting her account, we first check that she has enough money. The code looks completely reasonable, but it has several critical bugs. Can you spot them? DECLARE
May 12, 2026 Quick disclaimer: I do data work on a program-integrity team. Examples below use generic transaction tables and made-up scenarios. Nothing here comes from anything I’ve actually worked on or seen. Views are mine, not my employer’s. Fraud detection in transaction data is mostly SQL. Not machine learning, not graph databases, not whatever Gartner is hyping this year. SQL, run against th
プラットフォームチームの菅原です。 最近、pistachioという宣言的スキーマ管理ツールを作成し[1]、本番環境のDBマイグレーションに導入したので紹介させてください。 pistachioについて 「宣言的スキーマ管理」はTerraformのように「あるべきスキーマの状態」を記述し、差分を埋めるDDLを実行することでDBマイグレーションを行う方法です。 同様のツールとしてはatlasやsqldef、拙作ですがRidgepole、最近のものだとpgschemaなどがあります。 pistachioはPostgreSQL専用の宣言的スキーマ管理ツールで、SQLでスキーマを記述して管理します。 pistachioのワークフロー まずdumpコマンドで既存のスキーマをファイルに出力します。 $ pist dump > schema.sql $ cat schema.sql -- Dump of s
Introducing ggsql, a grammar of graphics for SQL that lets you describe visualizations directly inside SQL queries Read more... Today, we are super excited to announce the alpha-release of ggsql . As the name suggests, ggsql is an implementation of the grammar of graphics based on SQL syntax, bringing rich, structured visualization support to SQL. It is ready for use in Quarto, Jupyter notebooks,
Hi, I’m Nikita Volkov - architect, consultant, and the author of hasql, one of the two main PostgreSQL drivers in Haskell used in major production projects like PostgREST and IHP. After 25 years in IT and more late-night schema-drift fires than I care to count, I open-sourced something I wish had existed a decade ago: pGenie. Following is the story of how I went from shipping a popular ORM in 2012
こんにちは！株式会社 MeDiCU で学生インターンをしている村山です。普段は、MeDiCU の管理するデータベース OneICU を使った臨床疫学研究や医療 AI 研究に関わっています。 はじめに SQL で時系列データを扱っていると、「2つの区間が重なっているか」を判定したい場面が頻繁に出てきます。 あるイベントが発生していた時間帯と 別のイベントが発生していた時間帯 が重なっているかどうかを調べたい、といったケースです。一見すると単純な問題ですが、実際に SQL で書こうとすると、案外直感的には書きにくいのではないでしょうか。 我々がやっているような ICU の時系列データを扱う研究でも、この「区間の重なり判定」は非常に重要になります。 例） この 1時間のあいだ、人工呼吸器はついていたか この 1時間のあいだ、noradrenaline はどれくらい投与されたか ICU のデータに
インデックスを張るだけでは足りない。数億件の名刺データを扱うSansanのSQLパフォーマンス改善 2026年2月16日 Sansan株式会社 技術本部 Sansan Engineering Unit Product Enhancementグループ 清水 裕紀 大学卒業後、SIerにてCRMパッケージの導入に従事。2014年にSansan株式会社へ入社し、ビジネスデータベース「Sansan」の開発を担当。バックエンドの開発を主に担当し、近年はアーキテクトとして各種案件をリード。直近はデータベース領域をインフラと連携しながら推進し、プロダクトの品質向上と継続的な改善に取り組む。 ソフトウェアエンジニアにとって、SQLは身近な存在です。しかし、同時に「真に使いこなす」ことが難しい技術の一つでもあります。RDBMSの内部構造や実行計画を深く理解しなければ、大規模システムで発生する深刻なパフォーマ
はじめに こんにちは。開発部の國友です。 普段はデータベース管理者の業務を担当しています。 アプリケーションのパフォーマンス改善に取り組む際、「クエリが遅い」と感じたらまず行うべきことがあります。それは、RDBMSがそのクエリをどう実行しているか、その実行計画を確認することです。 皆さんは実行計画の確認方法、そして読み方を理解されていますか？ よく見るテーマではありますが、基礎だからこそ具体的な事例を通じて改めて実行計画を再確認しましょう。 実行計画とは 実行計画とはRDBMSがユーザーから受け取った SQL クエリを最も効率よく処理するために立てる、具体的な手順書です。 ゴールは一つ ユーザーが書く SQL は目的を示しています。例えば、"SELECT * FROM employees WHERE emp_no > 400000"は、「従業員番号が 400000 より大きいユーザーを全部
はじめに 前提 EXPLAIN（実行計画)とは EXPLAINを使ってみる EXPLAIN の主なフィールドを見てみよーー インデックスありと無しのEXPLAINを比較してみた ▼ インデックス無しで検索した場合の EXPLAIN ▼ インデックスありで検索した場合の EXPLAIN カバリングインデックス実践編 カバリングインデックスとは ▼ idによるクラスター化インデックス ▼ nameによる非クラスタ化インデックス ▼ ルックアップが必要となる事例 ▼ 複合インデックスを検討してみる まとめ 参考 最後に はじめに 本記事はiimon Advent Calendar 2025 11日目の記事となります。 こんにちは、ｉｉｍｏｎエンジニアのmariです！最近、業務の中で 既存の SQL を見直す機会 が増えてきました。 その中で、 「これ、もっとパフォーマンス良くできるんじゃないかな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
