Eftersom du inte kontrollerar den valda algoritmen finns det inget sätt att veta direkt. Men utan index bör en SELECT vara O(n) (en tabellskanning måste inspektera varje post vilket betyder att den kommer att skalas med tabellens storlek).
Med ett index är en SELECT förmodligen O(log(n)) (även om det skulle bero på algoritmen som används för indexering och egenskaperna hos själva data om det stämmer för någon riktig tabell). För att avgöra dina resultat för någon tabell eller fråga måste du ta till profilering av verkliga data för att vara säker.
INSERT utan index bör vara mycket snabb (nära O(1)) medan UPDATE måste hitta posterna först och kommer därför att gå långsammare (något) än SELECT som tar dig dit.
INSERT med index kommer troligtvis återigen att vara i bollplanet för O(log(n^2)) när indexträdet behöver balanseras om, annars närmare O(log(n)). Samma avmattning kommer att inträffa med en UPPDATERING om den påverkar indexerade rader, utöver SELECT-kostnaderna.
Alla spel är avstängda när du pratar om JOIN i mixen:du måste profilera och använda dina databasers frågeuppskattningsverktyg för att få en läsning om det. Observera också att om den här frågan är prestandakritisk bör du re profil från tid till annan eftersom algoritmerna som används av din frågeoptimerare kommer att ändras när databelastningen ändras.
En annan sak att tänka på... big-O berättar inte om fasta kostnader för varje transaktion. För mindre bord är dessa troligen högre än de faktiska arbetskostnaderna. Som ett exempel:installations-, rivnings- och kommunikationskostnaderna för en förfrågan över nätverk för en enskild rad kommer säkert att vara mer än uppslagningen av en indexerad post i en liten tabell.
På grund av detta upptäckte jag att att kunna bunta ihop en grupp relaterade frågor i en batch kan ha mycket större inverkan på prestandan än någon optimering jag gjorde av databasen.