Tengo datos de 98w filas. Cuando quiero ordenar mis datos con pub_time, encuentro algo interesante.Dos sql para la fecha de marca de tiempo ordenada
Aquí es el SQL:
select *
from t_p_blog_article_info t
order by t.pub_time desc
Costó 19s.
select *
from t_p_blog_article_info t
where t.pub_time > to_date('1900-01-01 01:00:00', 'yyyy-mm-dd hh24:mi:ss ')
order by t.pub_time desc
Cuesta 0.2s.
Quiero saber, ¿por qué?
Probablemente tenga un índice sobre pub_time en su mesa.
Por lo tanto, la segunda consulta puede hacer uso de este índice para devolver solo los registros con fechas no nulas después de la fecha especificada, mientras que la primera consulta tiene que consultar toda la tabla.
Sí, tengo índice en pub_time, pero ¿por qué la primera consulta no usa el índice? – sarowlwp
Aunque, propiamente hablando, ambas consultas terminan teniendo que consultar toda la tabla, ya que ambas tienen 'SELECT *' y * presumably * ambas devuelven todas las filas. (Al menos, dudo que OP haga esta pregunta si la segunda consulta devuelve muchas menos filas).) – ruakh
@sarowlwp: Los índices no incluyen valores nulos, por lo que si 'pub_time' es anulable (incluso si en realidad nunca es nulo), el índice no será suficiente para una consulta cuya cláusula WHERE no excluya los registros donde es nulo. – ruakh
Hay una variedad de posibilidades. Podría estar filtrando un gran número de filas con fechas inválidas/nulas en pub_time, pero dudo que omita advertir/mencionar un número significativo de estas.
Las tres cosas que se pegan en mi mente son:
- Usted tiene un índice o un índice compuesto que implica pub_time, y la restricción en su cláusula where está provocando el uso de una ruta de acceso diferente
- No tenía estadísticas disponibles para el optimizador cuando ejecutó su primera consulta. Al ejecutar la segunda consulta, se seleccionó una mejor ruta de acceso gracias al almacenamiento en memoria caché de información que se realizó al ejecutar la primera consulta. Esto puede verificarse ejecutando la primera consulta unas cuantas veces más y viendo si hay una mejora significativa en el rendimiento.
- Al igual que en el primer punto, el optimizador podría simplemente seleccionar una mejor ruta de acceso basándose únicamente en las implicaciones de la cláusula where. Tal vez dar la indicación de que los valores nulos/inválidos no tendrán que ser manejados es suficiente: su sistema podría estar evitando uno o más escaneos de tablas completas para eliminar las nulidades/null pub_times.
Identificar las razones de este tipo de cosas se está convirtiendo rápidamente en una aventura empírica. Es difícil para mí decir más sin conocer su plataforma &. A partir de la etiqueta, entiendo que estás usando Oracle, en cuyo caso deberías poder usar alguna forma de herramienta de "explicación de consulta" o "explicar plan" para tener una mejor idea de lo que está sucediendo. Para obtener más información sobre el optimizador de Oracle ver http://docs.oracle.com/cd/B10500_01/server.920/a96533/optimops.htm (Esto es para Oracle 9i v9.2, pero tiene una explicación decente de los conceptos independientes de la versión)
¿Hay un índice en la columna 'pub_time'? – Ollie
Solo una conjetura, pero ¿podría t.pub_time alguna vez ser NULL? – markblandford
aparentemente su cláusula Where filtra muchos registros, ¿por qué? 'null' values, o simplemente entradas con valores de tiempo defectuosos antes del 01.01.1900 – ntziolis