Karena Anda tidak mengontrol algoritme yang dipilih, tidak ada cara untuk mengetahuinya secara langsung. Namun, tanpa indeks, SELECT harus O(n) (pemindaian tabel harus memeriksa setiap record yang berarti akan diskalakan dengan ukuran tabel).
Dengan indeks, SELECT mungkin O(log(n)) (walaupun itu akan tergantung pada algoritma yang digunakan untuk pengindeksan dan properti data itu sendiri jika itu berlaku untuk tabel nyata apa pun). Untuk menentukan hasil Anda untuk tabel atau kueri apa pun, Anda harus menggunakan profil data dunia nyata untuk memastikannya.
INSERT tanpa indeks harus sangat cepat (mendekati O(1)) sementara UPDATE perlu menemukan catatan terlebih dahulu dan karenanya akan lebih lambat (sedikit) daripada SELECT yang membawa Anda ke sana.
INSERT dengan indeks mungkin akan kembali berada di rata-rata O(log(n^2)) ketika pohon indeks perlu diseimbangkan kembali, lebih dekat ke O(log(n)) jika tidak. Perlambatan yang sama akan terjadi dengan UPDATE jika memengaruhi baris yang diindeks, selain biaya SELECT.
Semua taruhan dibatalkan setelah Anda berbicara tentang GABUNG dalam campuran:Anda harus membuat profil dan menggunakan alat estimasi kueri basis data Anda untuk membacanya. Perhatikan juga bahwa jika kueri ini sangat penting bagi kinerja, Anda harus kembali profil dari waktu ke waktu karena algoritme yang digunakan oleh pengoptimal kueri Anda akan berubah seiring dengan perubahan beban data.
Hal lain yang perlu diingat... big-O tidak memberi tahu Anda tentang biaya tetap untuk setiap transaksi. Untuk tabel yang lebih kecil ini mungkin lebih tinggi dari biaya kerja yang sebenarnya. Sebagai contoh:biaya penyiapan, pembongkaran, dan komunikasi dari kueri lintas jaringan untuk satu baris pasti akan lebih besar daripada pencarian catatan yang diindeks dalam tabel kecil.
Karena itu, saya menemukan bahwa kemampuan untuk menggabungkan sekelompok kueri terkait dalam satu kumpulan dapat memiliki dampak yang jauh lebih besar pada kinerja daripada pengoptimalan apa pun yang saya lakukan pada basis data.
