MySQL から Spanner への移行時に実施したパフォーマンスチューニング

こんにちは、いつも心に冪等性 sinmetal です。「Merpay & Mercoin Tech Openness Month 2026」の 3 日目の記事です。

本記事では、MySQL で動いていた「お客さまが所持するクーポン一覧取得」クエリを Spanner へ移行した際に直面したパフォーマンス問題と、その解決までの過程を紹介します。

DB ごとのアーキテクチャの差

MySQL と Spanner はどちらも SQL を利用できますが、アーキテクチャが大きく異なるので、テーブルやクエリの設計は異なります。移行する時は差異がある SQL を修正するだけでなく、各 DB のアーキテクチャまで意識して、実装を見直す必要があります。

MySQL のアーキテクチャ

MySQL は Primary Instance が Write を担当するので、Write をスケールさせたいなら、Primary Instance のマシンを強化します。

Read は Read Replica（読み取り用レプリカ）を増やすことでもスケールさせることができます。

Read Replica は独立しているので、OLAP（オンライン分析処理）のような特定のクエリを特定の Instance で実行することもできます。

Spanner のアーキテクチャ

Spanner はデータを分割して Split に保存します。Split はデータサイズや負荷で自動的に増減し、データの分散範囲も調整されます。Write に対してもスケールできますが、Read Replica が無いので特定のクエリを特定の Instance で処理するようなことはできません。Read Replica だけを増やすということもできないので、Read 性能だけを増やすこともできません。Write も Read もどちらも Auto Scale（自動スケーリング）して分散して処理するのが強みです。

メルカリのクーポン機能の移行

クーポン機能の中に自分が所持しているクーポンの一覧を取得する API があります。その中で実行されていたクエリのチューニングを行いました。

まずは MySQL の実装をそのまま移行したので、以下のようなクエリになっていました。

MySQL なら、それほど問題になるようなクエリではないかもしれませんが、Spanner の実行計画を見ると Residual Condition（Residual Condition はインメモリで処理する必要がある状態です。後述※1）が必要、Sort（ソート）が必要など非常に厳しい状態です。

SELECT

co.CouponOwnerID,

co.CouponID,

co.Expire,

co.CreatedAt

FROM

CouponOwners co

JOIN

Coupons c

ON

co.CouponID = c.CouponID

WHERE

co.UserID = @userID

AND c.IsActive = @isActive

AND co.Expire > @now

AND c.StartDate

+-----+------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

| ID | Query_Execution_Plan |

+-----+------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

| *0 | Distributed Union (distribution_table: CouponOwnersByUserIDUsedExpireCreatedAtDESC, execution_method: Row, preserve_subquery_order: true, split_ranges_aligned: false) |

| 1 | +- Serialize Result (execution_method: Row) |

| 2 | +- Sort (execution_method: Row) |

| *3 | +- Distributed Cross Apply (execution_method: Row) |

| 4 | +- [Input] Create Batch (execution_method: Batch) |

| 5 | | +- RowToDataBlock |

| 6 | | +- Local Distributed Union (execution_method: Row) |

| *7 | | +- Filter Scan (execution_method: Row, seekable_key_size: 3) |

| *8 | | +- Index Scan (Index: CouponOwnersByUserIDUsedExpireCreatedAtDESC, execution_method: Row, scan_method: Row) |

| 34 | +- [Map] Cross Apply (execution_method: Row) |

| 35 | +- [Input] KeyRangeAccumulator (execution_method: Row) |

| 36 | | +- DataBlockToRow |

| 37 | | +- Batch Scan (Batch: $v2, execution_method: Batch, scan_method: Batch) |

| 46 | +- [Map] Local Distributed Union (execution_method: Row) |

| *47 | +- Filter Scan (execution_method: Row, seekable_key_size: 0) |

| *48 | +- Table Scan (Table: Coupons, execution_method: Row, scan_method: Row) |

+-----+------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

Predicates(identified by ID):

0: Split Range: (($UserID = @userid) AND ($Used = @isused) AND ($Expire > @now))

3: Split Range: ($CouponID_1 = $CouponID)

7: Residual Condition: ($UserID = @userid)

8: Seek Condition: (IS_NOT_DISTINCT_FROM($UserID, @userid) AND ($Used = @isused)) AND ($Expire > @now)

47: Residual Condition: (($IsActive = @isactive) AND ($MarketPlace = @marketplace) AND ($StartDate

DB Schema

CREATE TABLE Coupons (

CouponID STRING(36) NOT NULL,

Type STRING(36) NOT NULL,

IsActive BOOL NOT NULL,

StartDate TIMESTAMP NOT NULL,

MarketPlace STRING(255) NOT NULL,

) PRIMARY KEY(CouponID);

CREATE INDEX CouponsByIsActiveStartDateTypeMarketPlaceID

ON Coupons(IsActive, StartDate, Type, MarketPlace);

CREATE TABLE CouponOwners (

CouponOwnerID STRING(36) NOT NULL,

Used STRING(10) NOT NULL,

UserID INT64,

CouponID STRING(36) NOT NULL,

Expire TIMESTAMP NOT NULL,

CreatedAt TIMESTAMP NOT NULL OPTIONS (

allow_commit_timestamp = true

),

UpdatedAt TIMESTAMP NOT NULL OPTIONS (

allow_commit_timestamp = true

),

) PRIMARY KEY(CouponOwnerID);

CREATE INDEX CouponOwnersByUserIDUsedExpireCreatedAtDESC

ON CouponOwners(UserID, Used, Expire, CreatedAt DESC)

STORING (CouponID);

実行計画には現れない問題もありました。

HotSpot です。

Coupons Table はクーポンの情報が書かれているマスタテーブルなのですが、件数はそれほど多くありません。

Spanner は Read Replica が無いため、小さな Table や特定の Row への高頻度の読み取りが MySQL と比べると不得意です。対象の Row が存在する Split に負荷が集中してしまうからです。

特に負荷が集中するものとしてメルカリのすべてのお客さまに配信する 超メルカリ市土日限定クーポン がありました。

自分が所持しているクーポンの一覧を取得すると Coupons Table の該当の Row が JOIN のために参照されます。

すべてのお客さまが持っていて、しかも、超メルカリ市という大きなキャンペーンの中で、特定の土日にだけ使えて、クーポン付与のタイミングでプッシュ通知も行われることもあり、高い確率で HotRow になります。

Note: HotRow とは？

アクセスが集中していてそれ以上分割不能な Row のことを指します。

HotRow が発生しているかは Hot Spot Statistics を見ると分かります。

開発環境でチェックする場合は、負荷テストを行い、Hot Split Statistics をチェックします。

https://docs.cloud.google.com/spanner/docs/introspection/hot-split-statistics?hl=en#hot_row

パフォーマンスチューニング

これらの問題を解決するためにアーキテクチャを見直しました。

やったことは大きく分けて 3 つです。

• Coupons Table の JOIN をやめて、アプリ側に処理を寄せた

• ORDER BY を削除した

• NULL を許可している Column の Filter 条件を調整して Residual Condition が発生しないようにした

Coupons Table の JOIN をやめて、Coupons Table はアプリケーション側で参照するようにし、更に一定期間メモリ上にキャッシュするようにしました。

Valkey や Redis に保存することも検討しましたが、アクティブな状態のクーポンの数は数十程度であること、変更はほぼないことで、メモリ上に持ってしまって良いだろうと判断しました。

今後、他にもキャッシュしたいものが増えれば、専用のインフラを用意して、実装し直すかもしれません。

キャッシュを入れたことで、HotRow が発生しづらくなり、クエリも CouponOwners Table 単体で処理できるようになり、JOIN も不要になりました。

次に ORDER BY co.CreatedAt DESC を無くしました。

Filter 条件として Expire > @now があるので、CreatedAt の Sort があると単一の Index を Seek Condition で読むだけという処理にはできません。

Expire を Residual Condition で Filter Scan か、CreatedAt を Sortするかを選択することになります。

1 人のお客さまが持っているクーポンの数は多くても 10 程度なので、Sort してしまっても良いかなとは思いましたが、呼び出し回数が非常に多い API なので、アプリケーション側に処理を寄せています。代わりにアプリケーション側の負担が増えているので、どちらがよいかは悩ましいところです。今後の状況によっては Sort を Spanner 側に戻すこともあるかもしれません。

もう一工夫している点として、UserID の Filter 条件 (co.UserID IS NULL AND @userID IS NULL) を追加しています。

これは CouponOwners.UserID は NOT NULL 制約がないため、@userID に NULL が入る可能性を Spanner が考慮して、Filter Scan として Residual Condition: ($UserID = @userid) を追加してしまうのを抑制するためです。(元の実行計画の*7)(後述※2)

結果としてクエリの実行計画は非常にシンプルなものにできました。

SELECT

co.CouponOwnerID,

co.CouponID,

co.Expire,

co.CreatedAt

FROM

CouponOwners co

WHERE

(co.UserID = @userID) OR (co.UserID IS NULL AND @userID IS NULL)

AND co.Expire > @now

AND co.Used = @isUsed

+----+-----------------------------------------------------------------------------------------------------------------------------------------+

| ID | Query_Execution_Plan |

+----+-----------------------------------------------------------------------------------------------------------------------------------------+

| *0 | Distributed Union (distribution_table: CouponOwnersByUserIDUsedExpireCreatedAtDESC, execution_method: Row, split_ranges_aligned: false) |

| 1 | +- Local Distributed Union (execution_method: Row) |

| 2 | +- Serialize Result (execution_method: Row) |

| 3 | +- Filter Scan (execution_method: Row, seekable_key_size: 3) |

| *4 | +- Index Scan (Index: CouponOwnersByUserIDUsedExpireCreatedAtDESC, execution_method: Row, scan_method: Row) |

+----+-----------------------------------------------------------------------------------------------------------------------------------------+

Predicates(identified by ID):

0: Split Range: (($UserID = @userid) OR (ISNULL($UserID) AND ($Used = @isused) AND ($Expire > @now) AND ISNULL(@userid)))

4: Seek Condition: (($UserID = @userid) OR (ISNULL($UserID) AND ($Used = @isused) AND ($Expire > @now) AND ISNULL(@userid)))

まとめ

元のクエリと比較すると非常にシンプルになり、高速かつ負荷の少ないものとなりました。SQLを利用できるデータベースは増えていますが、インターフェースとして SQL が利用できても、内部のアーキテクチャはそれぞれ異なります。

Spanner は予算さえあれば気軽にノードを増やせるため、レイテンシや CPU 使用率に不満があれば、ノードを追加することで解決することも可能です。

しかし、コスト効率は良くないですし、ホットスポットのようにノードを増やしても解決できない問題もあります。

• 統計テーブルを定期的に確認し、パフォーマンスの状態をモニタリングすること。

• 新しいクエリの作成や既存のクエリの修正を行う場合は実行計画を確認すること。

• アクセスパターンに対して Spanner がどのような挙動を示す必要があるかを、Spanner の立場になって考えること。

これらを日常的に行うことで、より良い Spanner ライフを送ることができます。

次の記事は komatu さんの「決済プラットフォームと経理を繋ぐ MoneyFlow」です。引き続きお楽しみください。

※1 FilterScan オペレータの Seek Condition と Residual Condition

Seek Condition はテーブルやインデックスのスキャン範囲の開始点と終了点が特定できている状態の時に使用されます。開始点から終了点まで読み込むだけなので、高速に動作します。

Residual Condition はテーブルやインデックスを読み込む際に開始点と終了点が特定できず、データを実際に読んでフィルタリングする必要がある場合に利用されます。Seek Condition と比べると CPU を多く消費し、スキャンするデータ量に応じてレイテンシも増加します。

Seek Condition と Residual Condition については Cloud Spanner Unofficial Hacks を読むとよいでしょう。

※2 IS NOT DISTINCT FROM

Spanner には IS NOT DISTINCT FROM が存在しないため、co.UserID IS NULL AND @userID IS NULL と記述しているわけですが、2026 年 5 月 25 日に再度試したところ、IS NOT DISTINCT FROM で動作していました。まだドキュメントには反映されていないので、記事の中では使用していませんが、近々リリースノートが出るのでしょう。