Jouw stijl is erg ongebruikelijk.
De meeste mensen zouden waarschijnlijk WHERE began_at < NOW() AND finished_at > NOW() schrijven
Echter. Ik zou aanraden om op beide velden een index te plaatsen.
Een gecombineerde sleutel zal u niet van pas komen, omdat u de zoeker alleen maar sneller zou maken voor specifieke datumcombinaties.
Nou, dit is niet helemaal waar, want als je betree gebruikt, zal een gecombineerde sleutel je helpen, maar niet zo goed als wanneer je ze apart indexeert. Gecombineerde sleutels zijn erg goed als je combinaties van velden zoekt met een gelijkheid (=) operator. Indexen met één veld presteren beter in ragen-verzoeken.
Je kunt een beetje googlen voor "multidimensionaal zoeken op bereik".
De reden is dat alle overeenkomende velden in één veld in principe te vinden zijn in log(n) time in btrees.Dus uw algehele runtime zal O(k*log(n)) zijn, wat O(log(n)) is).
Multidimensionale bereikquery's hebben een runtime van O(sqrt(n)) die hoger is. Er zijn echter ook betere implementaties die ook logaritmische runtime bereiken. Ze zijn echter niet volledig geïmplementeerd in mysql, dus het zal slechter of verschrikkelijker zijn, afhankelijk van de versie.
Dus laat me samenvatten:
-
Gelijkheidsvergelijkingen op afzonderlijke velden:hash-index (runtime O(1))
-
Bereik zoeken op enkele velden:btree index op enkele velden ( O(log(n)) )
-
Gelijkheid zoeken op meerdere velden:gecombineerde hash-sleutel (runtime O(1))
die gevallen zijn duidelijk...
- Bereik zoeken op meerdere velden:aparte btree-indexen ( O(log(n)) )
hier is het niet zo duidelijk. met de huidige versies is het duidelijk beter om afzonderlijk te indexeren vanwege de hierboven genoemde redenen. Met een perfecte implementatie voor dat gebruik zou je betere prestaties kunnen bereiken met gecombineerde sleutels, maar er is geen systeem dat dit ondersteunt. mysql ondersteunt losse indexen (die die je daarvoor nodig hebt) sinds versie 5.0, maar slechts zeer beperkt en de query-optimizer gebruikt ze alleen in zeldzame gevallen afaik. weet niets van nieuwere versies zoals 5.3 of zoiets.
echter met mysql die losse indexen implementeert, worden gecombineerde sleutels op velden waar u bereikverzoeken doet of in verschillende richtingen sorteert, steeds relevanter.