surrealql-performance

SurrealQL のパフォーマンス

SurrealDB のクエリを高速化するテクニック：データの局所性を高めるレコード ID とキーの構成、適切なインデックスの選択と検証、読み取りのたびに再計算するのではなく、計算フィールドやビューを使って値を事前計算する方法について説明します。

最新の安定版 SurrealDB リリースを対象とします。バージョンによって構文が異なる項目（レコード範囲、COMPUTED フィールド、FULLTEXT インデックスのオプション）は、https://surrealdb.com/docs で確認し、surreal validate で例を検証してください。バージョンの検出については、surrealql スキルを参照してください。

このスキルを使用する場面

• クエリが遅い、または想定より多くのレコードをスキャンしている
• 効率的なルックアップや範囲スキャンに対応できるレコード ID を設計する
• 標準、UNIQUE、全文検索の SEARCH、ベクトルインデックスのいずれを使うか選択する
• インデックスが実際に使われているか確認する（EXPLAIN）
• 派生値を保存するか、読み取り時に計算するかを判断する

トピック一覧

トピック	リファレンス
局所性と範囲スキャンを考慮したレコード ID とキーの構成	references/keys.md
インデックスの種類、複合インデックスの順序、使用状況の検証、再構築コスト	references/indexing.md
計算フィールド、事前計算ビュー、イベントで維持する値	references/computed-fields.md

主なルール

• アクセスパターンに合わせて ID を設計します。 レコード ID はソートされた順序で保存されます。選択性が高く、範囲検索に適した要素を先頭に置くと（例：weather:['London', d'2025-02-13T05:00Z']）、関連レコードがまとまり、範囲クエリでテーブル全体をスキャンせずに済みます。references/keys.md を参照してください。
• ID に対する WHERE 条件より、レコード範囲を優先します。 SELECT * FROM person:1..1000 はキーの順序を直接利用しますが、全件スキャン後に WHERE で絞り込む方法では利用できません。
• フィルタリング、ソート、結合に使うフィールドにのみインデックスを設定します。 インデックスを追加するたびに書き込みコストが増加します。複合インデックスのフィールドは、選択性の高い順に並べ、クエリのフィルタリングやソートの順序に合わせてください。references/indexing.md を参照してください。
• 思い込まずに検証します。 クエリが想定どおりのインデックスを使用していることを確認してから、最適化済みと判断するために、EXPLAIN（または EXPLAIN FULL）を実行してください。
• コストの高い、読み取り頻度の高い値は事前計算します。 クエリのたびに集計値を再計算するのではなく、計算フィールド、DEFINE TABLE ... AS SELECT ビュー、または DEFINE EVENT を使って派生データを維持してください。references/computed-fields.md を参照してください。
• バインドパラメーターを使用します。 パラメーター化されたクエリは安全性が高く、エンジンによるクエリプランの再利用も可能になります。