Instagram複数アカウント対応のindex設計――account scopeと検索コスト

単一アカウント前提のテーブルへaccount scopeを追加するとき、既存行、unique制約、query indexをどう移行するか。

コードから観測できること

1. ig accounts migrationの次にaccount indexesが追加され、データモデル変更とquery性能対策が別migrationとして残る。
2. account helperとaccounts authz testがあり、DB schemaだけでなくAPI権限で別accountを参照できないことも検証対象になる。
3. indexは読取を速くする一方、書込・storageを増やす。実データ件数とquery planを記録せず『高速化した』と断定しない。

再現・追加測定の手順

1. 旧schemaに複数account相当データを作る
2. migration後のaccount割当を確認する
3. 代表queryへEXPLAINを実行する
4. 別account IDのauthz要求と書込負荷を測る

この資料だけでは証明できないこと

1. 小規模fixtureではindex効果を測れない。
2. D1の実行環境とローカルSQLiteの性能値を同一視しない。

このページは新しいcommit、実測ログ、API仕様変更が得られた時点で更新します。古い観測条件と現在仕様を混同しないため、固定commitへのリンクを残します。