Váš styl je velmi neobvyklý.
Většina lidí by pravděpodobně napsala WHERE began_at < NOW() AND finished_at > NOW()
Nicméně. Doporučil bych umístit index na obě pole.
Kombinovaný klíč vám nebude k ničemu, protože byste tím pouze urychlili hledání konkrétních kombinací dat.
Není to tak úplně pravda, protože pokud používáte betree, kombinovaný klíč vám pomůže, ale není tak dobrý, jako když je indexujete samostatně. Kombinované klíče jsou velmi dobré, pokud hledáte kombinace polí s operátorem rovnosti (=). Jednopolové indexy fungují lépe v ragen požadavcích.
Můžete si trochu vygooglovat pro „hledání vícerozměrného rozsahu“.
Důvodem je, že všechna odpovídající pole v jednom poli lze v zásadě nalézt v log(n) time v btrees. Takže vaše celkové runtime bude O(k*log(n)), což je O(log(n)).
Dotazy na vícerozměrný rozsah mají dobu běhu O(sqrt(n)), která je vyšší. Existují však také lepší implementace, které také dosahují logaritmického běhu. Nejsou však plně implementovány v mysql, takže to bude horší nebo hrozné v závislosti na verzi.
Dovolte mi to tedy shrnout:
-
Porovnání rovnosti na jednotlivých polích:hash index (runtime O(1))
-
Hledání rozsahu na jednotlivých polích:index btree na jednotlivých polích ( O(log(n)) )
-
Vyhledávání rovnosti ve více polích:kombinovaný hash klíč (runtime O(1))
ty případy jsou jasná věc...
- Rozsahové vyhledávání ve více polích:samostatné indexy bstromu ( O(log(n)) )
tady to není tak jasné. se současnými verzemi je zjevně lepší indexovat samostatně z důvodů uvedených výše. S perfektní implementací pro tento případ použití byste mohli dosáhnout lepšího výkonu s kombinovanými klíči, ale žádný systém neví, který to podporuje. mysql podporuje volné indexy (které potřebujete) od verze 5.0, ale jen velmi omezeně a optimalizátor dotazů je používá pouze ve vzácných případech afaik. nevím o novějších verzích, jako je 5.3 nebo tak něco.
nicméně s implementací volných indexů pomocí mysql jsou kombinované klíče na polích, kde provádíte požadavky na rozsah nebo řazení v různých směrech, stále relevantnější.