Opravdu záleží, měl jsem situace, kdy jsem vylepšil některé dotazy pomocí poddotazů.
Faktory, které jsem si vědom, jsou:
- jestli poddotaz používá k porovnání pole z vnějšího dotazu nebo ne (korelované nebo ne)
- pokud je vztah mezi vnějším dotazem a dílčím dotazem pokryt indexy
- Pokud na spojeních nejsou žádné použitelné indexy a poddotaz není korelovaný a vrací malý výsledek, může být rychlejší jej použít
- Také jsem se dostal do situací, kdy jsem převedl dotaz, který používá order by, na dotaz, který jej nepoužívá, a pak jsem ho převedl na jednoduchý poddotaz a řazení, které zlepšuje výkon v mysql
Každopádně je vždy dobré testovat různé varianty (s SQL_NO_CACHE prosím) a přeměna korelovaných dotazů na spojení je dobrá praxe.
Dokonce bych zašel tak daleko, abych to označil za velmi užitečnou praxi.
Je možné, že pokud jsou korelované dotazy první, které vás napadnou, neuvažujete primárně z hlediska množinových operací, ale především z hlediska procedurálních operací a při práci s relačními databázemi je velmi užitečné množinu plně převzít pohled na datový model a jeho transformace.
EDIT:Procedurální vs. relační
Myšlení z hlediska množinových operací vs. procedurální se v některých výrazech množinové algebry scvrkává na ekvivalenci, například výběr na sjednocení je ekvivalentní sjednocení výběrů. Mezi těmito dvěma není žádný rozdíl.
Ale když porovnáte tyto dva postupy, jako je použití výběrových kritérií na každý prvek svazu s vytvořením svazu a poté aplikováním výběru, jsou tyto dva výrazně odlišné postupy, které mohou mají velmi odlišné vlastnosti (například využití CPU, I/O, paměti).
Myšlenka relačních databází spočívá v tom, že se nesnažíte popsat, jak získat výsledek (postup), ale pouze to, co chcete, a že systém správy databází rozhodne o nejlepší cestě (postupu) ke splnění vašeho požadavku. Proto se SQL nazývá jazyk 4. generace (4GL) .
Jedním z triků, které vám v tom pomohou, je připomenout si, že n-tice nemají žádné vlastní pořadí (prvky množiny jsou neuspořádané). Dalším je zjištění, že relační algebra je poměrně komplexní a umožňuje překlad požadavků (požadavků) přímo do SQL (pokud je sémantika váš model dobře reprezentuje problémový prostor, nebo jinými slovy, pokud je význam spojený s názvem vašich tabulek a vztahů správně, nebo jinými slovy, pokud je vaše databáze dobře navržena).
Nemusíte tedy přemýšlet jak, ale jen co.
Ve vašem případě to byla jen preference před korelovanými dotazy, takže se může stát, že vám neříkám nic nového, ale vy jste to zdůraznili, proto ten komentář.
Myslím, že pokud jste byli zcela spokojeni se všemi pravidly, která převádějí dotazy z jednoho formuláře do druhého (pravidel jako je distributivnost), že byste neupřednostňovali korelované poddotazy (že byste viděli všechny formy jako rovnocenné).
(Poznámka:výše pojednává o teoretickém pozadí důležitém pro návrh databáze; prakticky se výše uvedené koncepty odchylují - ne všechny ekvivalentní přepisy dotazu se nutně provádějí tak rychle, seskupené primární klíče způsobují, že tabulky dědí pořadí na disku atd... odchylky jsou pouze odchylky; skutečnost, že ne všechny ekvivalentní dotazy se provádějí tak rychle, je nedokonalostí skutečného DBMS a ne konceptů za ním)