LIKE '%…%' のように前方にワイルドカードが付く部分一致は B-tree インデックスが効かないため、対象テーブル全体のスキャンになる。属性を縦持ちする EAV 構成では行数が素直に膨らむので、テナントや利用者の規模が大きいほど直接効いてくる。

対処

全文検索エンジンの導入に飛ぶ前に、検索の起点を候補集合に変える。すでに絞り込みの意味を持つ関連テーブル（重複グループのメンバー、対象期間の明細など）を起点に join し、部分一致の評価対象をその集合内へ限定する。検索結果の意味とテナント条件を変えずにスキャン範囲だけを縮められる。

最後に実データ規模で実行計画を確認する。行数見積もりが小さいテスト環境では差が出ない。

判断の勘所

• 検索の頻度を見る。入力確定時のみ走る低頻度の管理画面なら、検索エンジンを増やすほどではない。運用対象が増えることのコストが上回る。
• ただし「O(n) のクエリを避ける」方針を持つプロジェクトでは方針に抵触し得るので、後回しにするなら性能確認タスクとして切る。放置と判断保留を区別する。
• 同種の検索が複数箇所にあるとき、片方だけ候補集合を起点にしていることがある。実装差を確認してから「対応不要」と言う。