¿El número de columnas afecta el rendimiento de la consulta?

Question

CASO 1: Tengo una tabla con 30 columnas y consulto usando 4 columnas en la cláusula where.

CASO 2: Tengo una tabla con 6 columnas y consulto usando 4 columnas en la cláusula where.

¿Cuál es la diferencia en el rendimiento en ambos casos?

Por ejemplo, he tabla

table A 
{ 
    b varchar(10), 
    c varchar(10), 
    d varchar(10), 
    e varchar(10), 
    f varchar(10), 
    g varchar(10), 
    h varchar(10) 

} 

SELECT b,c,d 
FROM A 
WHERE f='foo' 

create table B 
{ 
    b varchar(10), 
    c varchar(10), 
    d varchar(10), 
    e varchar(10), 
    f varchar(10) 

} 

SELECT b,c,d 
FROM B 
WHERE f='foo' 

Tanto A y en la Tabla B tiene misma estructura significa única diferencia en el número de la columna y la columna se utiliza en donde la condición es también mismo y columna en Select también es el mismo. La diferencia es que la tabla B solo tiene alguna columna no utilizada. Estas no se están utilizando en la condición de selección , en ese caso, ¿hay alguna diferencia en el rendimiento de ambas consultas?

Answer 1

El principal beneficio de devolver un menor número de columnas de una SELECT es que SQL podría ser capaz de evitar la lectura de la mesa/grupo, y en su lugar, si se puede recuperar todos los datos selected de un índice(ya sea como columnas indexadas y/o columnas incluidas en el caso de un índice de cobertura). Las columnas utilizadas en el predicado, es decir, f en su ejemplo, DEBE estar en las columnas indexadas del índice.

En el caso general, también hay una secundaria beneficio en la devolución de un menor número de columnas de una SELECT, ya que esto reducirá cualquier sobrecarga de E/S, especialmente si hay una red lenta entre el servidor de base de datos y la aplicación de consumir los datos, es decir, es una buena práctica devolver solo las columnas que realmente necesita y evitar el uso de SELECT *.

Editar: En respuesta al mensaje actualizado de la OP:

sin índices en todo, tanto las consultas harán recorridos de tablas. Dado que Table B tiene menos columnas que Table A, las filas por página (densidad) serán más altas en B y por lo tanto B serán marginalmente más rápidas ya que SQL necesitará obtener menos páginas.

Sin embargo, con índices según abajo

• índice en A(f) INCLUDE (b,c,d)
• índice en B(f) INCLUDE (b,c,d)

El rendimiento debe ser idéntico para las consultas (suponiendo mismos datos en ambas tablas), dado ese SQL golpeará los índices que ahora tienen anchos de columna y densidades de fila similares.

Editar

Algunos otros planes:

• índice en B(f) sin otras columnas de clave o INCLUDE, o con un conjunto incompleto de INCLUDE columnas (es decir,una o más de b, c or d faltan):

SQL Server es probable que tenga que hacer un Key or RIDLookup ya que incluso si se utiliza el índice, habrá una necesidad de "unirse" a volver a la mesa para recuperar los desaparecidos columnas en la cláusula de selección. (El tipo de búsqueda depende de si la tabla tiene un PK agrupado o no)

• Straight índice no agrupado en B(f,b,c,d)

Esto seguirá siendo muy performant, como el índice será utilizado y la mesa evitado, pero won't be quite as good as the covering index, porque la densidad del árbol de índice será menor debido a las columnas clave adicionales en el índice.

Answer 2

No habrá diferencia en el rendimiento en función de la posición de la columna. Ahora la construcción de la mesa es una historia diferente, por ej. número de filas, índices, número de columnas, etc.

El escenario del que está hablando en el que compara la posición de la columna en las dos tablas es como comparar manzanas con naranjas casi, porque hay muchas variables diferentes además de la posición de la columna.

Answer 3

Depende del ancho de la tabla (Bytes por fila), cuántas filas hay en la tabla y si hay índices en las columnas utilizadas por la consulta. Sin respuesta definitiva sin esa información. Sin embargo, cuantas más columnas haya en la tabla, es probable que sea más amplia. Pero el efecto de un índice adecuado es mucho más significativo que el efecto del tamaño de la tabla.

Answer 4

A menos que tenga una diferencia de conjunto de columnas muy amplia sin que se utilice ningún índice (por lo tanto, una exploración de tabla), verá poca diferencia en el rendimiento. Dicho esto, siempre es útil/benificial devolver la menor cantidad de columnas posible para satisfacer sus necesidades. La clave aquí es que se puede obtener un mayor beneficio devolviendo las columnas que necesita en lugar de una segunda búsqueda de base de datos para otras columnas.

• Obtenga lo que necesita
• evitar segunda consulta de base de datos en la misma mesa para mismas filas
• utilizar un índice en la columna Seleccionar (s) (cláusula WHERE limitador)
• restringir columnas si no lo hace los necesita para mejorar la eficiencia de la memoria del servidor de datos/paginación

Answer 5

¡Pruébelo y vea!

Habrá una diferencia de rendimiento, sin embargo, el 99% de las veces no lo notará; ¡por lo general, ni siquiera podrá detectarlo!

Ni siquiera puede garantizar que la tabla con menos columnas sea más rápida; si le molesta, pruébela y vea.

basura técnico: (desde la perspectiva de Microsoft SQL Server)

Con la suposición de que en todos los demás aspectos (índices, recuentos de filas, los datos contenidos en las 6 columnas comunes etc ...) el las tablas son idénticas, entonces la única diferencia real será que la tabla más grande se distribuye en más páginas en el disco/en la memoria.

El servidor SQL solo intenta leer los datos que absolutamente requiere, sin embargo, siempre cargará una página completa a la vez (8 KB). Incluso con la misma cantidad de datos exactos que se requieren como resultado de la consulta, si esos datos se extienden en más páginas, se requiere más IO.

Dicho esto, SQL Server es increíblemente eficiente con su acceso a los datos, por lo que es muy poco probable que vea un impacto notable en el rendimiento, excepto en circunstancias extremas.

Además, también es probable que su consulta se ejecute contra el índice en lugar de la tabla de todos modos, por lo que con índices exactamente del mismo tamaño, es probable que el cambio sea .