En la versión Enterprise de SQL Server, hay una característica muy útil en sistemas donde existen recorridos de tabla (si, los temidos table scans ;). El hermano mayor de SQL Server posee la característica de permitir que varias tareas compartan recorridos de tabla completos.Si el plan de ejecución de una instrucción T-SQL requiere un recorrido de las páginas de datos de una tabla y el motor de base de datos detecta que la tabla ya se recorre en otro plan de ejecución, se combina el segundo recorrido con el primero, en la ubicación actual del segundo. De esta forma, se lee cada página una vez y pasa las filas de cada página a ambos planes de ejecución. Esto continúa hasta que se llega al final de la tabla.

Esto repercute directamente en una mejora drástica del uso de los dispositivos E/S puesto que en lugar de que dos o mas hilos lean cada uno las mismas páginas, se leen solo una vez y se comparten por el resto, lo que evita en la medida de lo posible la contención en el brazo del disco físico y la competición por espacio en buffer.

Según lo que acabo de comentar, si el hilo B ya ha recorrido las páginas 504-528 y entra a recorrer el hilo A, la misma tabla, se unirá por donde se encuentra B leyendo, para reutilizar las lecturas, compartiéndolas ambas…pero cuando finalicen de leer la página 576, el proceso A volverá al principio para leer la información de las páginas 504-528, puesto que este proceso no las había leído.

Esto es un ejemplo mas, que demuestra por qué a menos de usar order by, no se puede garantizar NUNCA el orden de los resultados devueltos por una consulta.

Enrique Catalá