Tu estilo es muy poco común.
La mayoría de la gente probablemente escribiría WHERE began_at < NOW() AND finished_at > NOW()
Sin embargo. Recomendaría poner un índice en ambos campos.
Una clave combinada no le será útil porque solo aceleraría el buscador para combinaciones de fechas específicas.
Bueno, esto no es del todo cierto porque si usa betree, una clave combinada lo ayudará, pero no tan bien como si las indexara por separado. Las claves combinadas son muy buenas si busca combinaciones de campos con el operador de igualdad (=). Los índices de un solo campo funcionan mejor en solicitudes ragen.
Puedes googlear un poco para "búsqueda de rango multidimensional".
La razón es que todos los campos coincidentes en un campo se pueden encontrar básicamente en tiempo de registro (n) en btrees. Por lo tanto, su tiempo de ejecución general será O (k * registro (n)) que es O (registro (n)).
Las consultas de rango multidimensional tienen un tiempo de ejecución de O(sqrt(n)) que es mayor. Sin embargo, también hay implementaciones mejores que también alcanzan un tiempo de ejecución logarítmico alto. Sin embargo, no están completamente implementadas en mysql, por lo que será peor o terrible dependiendo de la versión.
Así que permítanme resumir:
-
Comparaciones de igualdad en campos individuales:índice hash (tiempo de ejecución O(1))
-
Búsqueda de rango en campos individuales:índice btree en campos individuales ( O(log(n)) )
-
Búsqueda de igualdad en varios campos:clave hash combinada (tiempo de ejecución O(1))
esos casos son una cosa clara...
- Búsqueda de rango en múltiples campos:índices btree separados ( O(log(n)) )
aquí es donde no está tan claro. con las versiones actuales, es claramente mejor indexar por separado debido a las razones mencionadas anteriormente. Con una implementación perfecta para ese caso de uso, podría lograr un mejor rendimiento con claves combinadas, pero no se conoce ningún sistema que lo admita. mysql admite índices sueltos (que necesita para eso) desde la versión 5.0, pero solo muy limitado y el optimizador de consultas solo los utiliza en casos raros afaik. no sé acerca de las versiones más nuevas como 5.3 o algo así.
sin embargo, con la implementación de mysql, las claves combinadas de índices sueltos en los campos en los que realiza solicitudes de rango o la clasificación en diferentes direcciones se vuelven cada vez más relevantes.
