actualización:
Lee este artículo en mi blog para la estrategia de indexación eficiente para su búsqueda usando las columnas calculadas:
La idea principal es que sólo calcula redondeada length y startDate para usted rangos y luego buscamos para ellos el uso de condiciones de igualdad (que son buenos para B-Tree índices)
En MySQL y en SQL Server 2008 puede usar los índices SPATIAL (R-Tree).
Son especialmente buenos para las condiciones como "seleccionar todos los registros con un punto determinado dentro del rango del registro", que es solo tu caso.
almacenar los start_date y end_date como el principio y el final de un LineString (convirtiéndolos a UNIX marcas de tiempo de otro valor numérico), índice con un índice de SPATIAL y la búsqueda de todos estos LineString s cuyo cuadro de límite mínimo (MBR) contiene el valor de fecha en cuestión, usando MBRContains.
Ver esta entrada en mi blog acerca de cómo hacer esto en MySQL:
y una visión general del rendimiento breve para SQL Server:
Se puede aplicar la misma solución para buscar un valor IP dado en rangos de red almacenados en la base de datos.
Esta tarea, junto con su consulta, es otro ejemplo frecuente de dicha condición.
Normal B-Tree los índices no son buenos si los rangos se pueden superponer.
Si no pueden (y lo sabes), puede utilizar la solución brillante propuesto por @AlexKuznetsov
También tenga en cuenta que este rendimiento de las consultas depende totalmente de su distribución de datos.
Si usted tiene un montón de registros en B y pocos registros en A, usted podría construir un índice en B.dates y dejar que el TS/CIS en A marcha.
Esta consulta siempre leerá todas las filas desde A y usará Index Seek en B.dates en un bucle anidado.
Si sus datos se distribuyen de otra forma, yo. mi. usted tiene un montón de filas en A pero pocos en B, y los rangos son generalmente cortos, entonces se podría rediseñar sus mesas un poco:
A
start_date interval_length
, crear un índice compuesto en A (interval_length, start_date)
y utilizar esta consulta :
SELECT *
FROM (
SELECT DISTINCT interval_length
FROM a
) ai
CROSS JOIN
b
JOIN a
ON a.interval_length = ai.interval_length
AND a.start_date BETWEEN b.date - ai.interval_length AND b.date
"Una exploración de tabla y exploración de índice son lo mismo"? No lo creo, a menos que te refieras cuando el índice tiene todas las columnas en la tabla. Dudo mucho que sus tablas solo tengan las columnas mencionadas en ellas. – ongle
Sí, son lo mismo. Un análisis de índice recupera cada fila de una tabla, mientras que una búsqueda no lo hace. Un escaneo de tabla (o escaneo de índice) donde no hay otro índice agrupado en la tabla le da el peor desempeño. – Jon
Un análisis de índice recupera cada "fila" del índice, no de la tabla. Una exploración de índice es mejor que una exploración de tabla simplemente porque un índice normalmente tiene menos columnas en ella que la tabla, lo que da como resultado más "filas" por lectura. Pero estamos de acuerdo en que los escaneos son malos y deben evitarse. – ongle