選択したアルゴリズムを制御しないため、直接知る方法はありません。ただし、インデックスがない場合、SELECTはO（n）である必要があります（テーブルスキャンではすべてのレコードを検査する必要があるため、テーブルのサイズに合わせてスケーリングされます）。
インデックスの場合、SELECTはおそらくO（log（n））です（ただし、実際のテーブルに当てはまる場合は、インデックス作成に使用されるアルゴリズムとデータ自体のプロパティによって異なります）。テーブルやクエリの結果を判断するには、実際のデータのプロファイリングに頼る必要があります。
インデックスなしのINSERTは非常に高速（O（1）に近い）である必要がありますが、UPDATEは最初にレコードを見つける必要があるため、そこに到達するSELECTよりも（わずかに）遅くなります。
インデックスを使用したINSERTは、インデックスツリーのバランスを取り直す必要がある場合は、おそらく再びO（log（n ^ 2））の球場にあり、そうでない場合はO（log（n））に近くなります。 SELECTコストに加えて、インデックス付きの行に影響する場合、UPDATEでも同じ速度低下が発生します。
ミックスでJOINについて話していると、すべての賭けは無効になります。データベースクエリ推定ツールをプロファイリングして使用し、それを読み取る必要があります。また、このクエリがパフォーマンスに不可欠な場合は、再する必要があることにも注意してください。 クエリオプティマイザで使用されるアルゴリズムは、データの負荷が変化すると変化するため、プロファイルは随時変更されます。
覚えておくべきもう一つのこと...big-Oは各トランザクションの固定費について教えてくれません。小さいテーブルの場合、これらはおそらく実際の作業コストよりも高くなります。例：単一行のクロスネットワーククエリのセットアップ、破棄、および通信のコストは、小さなテーブルでのインデックス付きレコードのルックアップよりも確実に高くなります。
このため、関連するクエリのグループを1つのバッチにバンドルできると、データベースに適切に行った最適化よりもパフォーマンスに大きな影響を与える可能性があることがわかりました。