Protože neovládáte vybraný algoritmus, neexistuje způsob, jak to zjistit přímo. Bez indexů by však SELECT měl být O(n) (skenování tabulky musí prověřit každý záznam, což znamená, že se přizpůsobí velikosti tabulky).
U indexu je SELECT pravděpodobně O(log(n)) (ačkoli by to záviselo na algoritmu použitém pro indexování a vlastnostech samotných dat, pokud to platí pro jakoukoli skutečnou tabulku). Chcete-li určit své výsledky pro jakoukoli tabulku nebo dotaz, musíte se pro jistotu uchýlit k profilování dat z reálného světa.
INSERT bez indexů by měl být velmi rychlý (blízko O(1)), zatímco UPDATE musí nejprve najít záznamy, a proto bude pomalejší (o něco málo) než SELECT, který vás tam dostane.
INSERT s indexy bude pravděpodobně opět v kulise O(log(n^2)), když bude třeba znovu vyvážit strom indexu, jinak blíže k O(log(n)). Ke stejnému zpomalení dojde s UPDATE, pokud ovlivní indexované řádky, navíc k nákladům SELECT.
Všechny sázky jsou vypnuté, jakmile mluvíte o JOIN v mixu:budete se muset profilovat a používat nástroje pro odhad dotazů v databázi, abyste si to mohli přečíst. Upozorňujeme také, že pokud je tento dotaz kritický pro výkon, měli byste jej znovu čas od času, protože algoritmy používané vaším optimalizátorem dotazů se mění se změnou zatížení dat.
Další věc, kterou je třeba mít na paměti... big-O vám neříká fixní náklady na každou transakci. U menších stolů jsou tyto pravděpodobně vyšší než skutečné náklady na práci. Jako příklad:náklady na nastavení, odstranění a komunikaci v případě dotazu napříč sítí pro jeden řádek budou jistě vyšší než jen vyhledávání indexovaného záznamu v malé tabulce.
Z tohoto důvodu jsem zjistil, že možnost seskupovat skupinu souvisejících dotazů do jedné dávky může mít mnohem větší dopad na výkon než jakákoli optimalizace, kterou jsem provedl pro samotnou databázi.