it-swarm-es.tech

¿Cuál es más rápido/mejor? SELECCIONAR * o SELECCIONAR columna1, columna2, columna3, etc.

He escuchado que SELECT * es generalmente una mala práctica de usar al escribir comandos SQL porque es más eficiente para SELECT las columnas que necesita específicamente.

Si necesito SELECT cada columna en una tabla, ¿debo usar

SELECT * FROM TABLE

o

SELECT column1, colum2, column3, etc. FROM TABLE

¿Importa realmente la eficiencia en este caso? Pensaría que SELECT * sería más óptimo internamente si realmente necesita todos los datos, pero lo digo sin una comprensión real de la base de datos.

Tengo curiosidad por saber cuál es la mejor práctica en este caso.

ACTUALIZACIÓN: Probablemente debería especificar que la única situación en la que realmente quiero para hacer un SELECT * es cuando selecciono datos de una tabla en la que sé que siempre será necesario recuperar todas las columnas , incluso cuando se agregan nuevas columnas.

Sin embargo, dadas las respuestas que he visto, esto todavía parece ser una mala idea y SELECT * nunca debería usarse por razones técnicas más que nunca he pensado.

152
Dan Herbert

Una razón por la que es mejor seleccionar columnas específicas es que aumenta la probabilidad de que SQL Server pueda acceder a los datos desde índices en lugar de consultar los datos de la tabla.

Aquí hay una publicación que escribí al respecto: La verdadera razón por la que las consultas de selección son una mala cobertura del índice

También es menos frágil cambiar, ya que cualquier código que consuma los datos obtendrá la misma estructura de datos, independientemente de los cambios que realice en el esquema de la tabla en el futuro.

157
Jon Galloway

Dado que su especificación indica que usted está seleccionando todas las columnas, hay poca diferencia en este momento . Tenga en cuenta, sin embargo, que los esquemas de base de datos cambian. Si usaSELECT *obtendrá nuevas columnas agregadas a la tabla, aunque con toda probabilidad, su código no está preparado para usar o presentar esos nuevos datos. Esto significa que está exponiendo su sistema a cambios inesperados de rendimiento y funcionalidad.

Puede estar dispuesto a descartar esto como un costo menor, pero tenga en cuenta que las columnas que no necesita aún deben ser:

  1. Leer de la base de datos
  2. Enviado a través de la red
  3. Marshalled en su proceso
  4. (para tecnologías de tipo ADO) Guardado en una tabla de datos en memoria
  5. Ignorado y desechado/recogida de basura

El artículo # 1 tiene muchos costos ocultos, incluida la eliminación de un posible índice de cobertura, lo que ocasiona cargas de páginas de datos (y el bloqueo de la caché del servidor), incurriendo en bloqueos de fila/página/tabla que de otra manera podrían evitarse.

Compare esto con el ahorro potencial de especificar las columnas versus un*y los únicos ahorros potenciales son:

  1. El programador no necesita volver a visitar el SQL para agregar columnas
  2. El transporte de red del SQL es más pequeño/más rápido.
  3. Tiempo de consulta/validación de SQL Server
  4. Caché del plan de consultas de SQL Server

Para el artículo 1, la realidad es que va a agregar/cambiar el código para usar cualquier columna nueva que pueda agregar de todos modos, por lo que es un lavado.

Para el artículo 2, la diferencia rara vez es suficiente para empujarlo a un tamaño de paquete o número de paquetes de red diferente. Si llega al punto donde el tiempo de transmisión de la sentencia SQL es el problema predominante, es probable que primero deba reducir la tasa de las sentencias.

Para el artículo 3, NO hay ahorros ya que la expansión del*tiene que suceder de todos modos, lo que significa consultar el esquema de la tabla de todos modos. De manera realista, el listado de las columnas incurrirá en el mismo costo porque tienen que validarse contra el esquema. En otras palabras, esto es un lavado completo.

Para el artículo 4, cuando especifica columnas específicas, su caché de planes de consulta podría aumentar pero solo si está tratando con diferentes conjuntos de columnas (que no es lo que ha especificado). En este caso, usted quiere entradas de caché diferentes porque quiere diferentes planes según sea necesario.

Entonces, todo esto se reduce, debido a la forma en que especificó la pregunta, a la resiliencia del problema ante eventuales modificaciones de esquema. Si está quemando este esquema en ROM (sucede), entonces un*es perfectamente aceptable.

Sin embargo, mi guía general es que solo debe seleccionar las columnas que necesita, lo que significa que a veces parecerá que las está pidiendo todas, pero la evolución de los DBA y el esquema indican que podrían aparecer algunas columnas nuevas Eso podría afectar mucho la consulta.

Mi consejo es que debes SIEMPRE SELECCIONAR columnas específicas . Recuerde que se vuelve bueno en lo que hace una y otra vez, así que adquiera el hábito de hacerlo bien.

Si se está preguntando por qué un esquema podría cambiar sin cambiar el código, piense en términos de registro de auditoría, fechas de vigencia/vencimiento y otras cosas similares que los DBA agregan para problemas de cumplimiento de forma sistémica. Otra fuente de cambios indirectos son las desnormalizaciones para el rendimiento en otras partes del sistema o campos definidos por el usuario.

57
IDisposable

Solo debes seleccionar las columnas que necesites. Incluso si necesita todas las columnas, es mejor enumerar los nombres de las columnas para que el servidor SQL no tenga que consultar las columnas de la tabla del sistema.

Además, su aplicación podría fallar si alguien agrega columnas a la tabla. Su programa obtendrá columnas que no esperaba y puede que no sepa cómo procesarlas.

Aparte de esto, si la tabla tiene una columna binaria, la consulta será mucho más lenta y utilizará más recursos de red.

33
Giorgi

Hay cuatro grandes razones por las que select * es algo malo:

  1. La razón práctica más importante es que obliga al usuario a saber mágicamente el orden en que se devolverán las columnas. Es mejor ser explícito, lo que también lo protege contra el cambio de la mesa, lo que se adapta perfectamente a ...

  2. Si el nombre de una columna que está utilizando cambia, es mejor detectarlo temprano (en el punto de la llamada a SQL) en lugar de cuando está intentando usar la columna que ya no existe (o que se cambió su nombre, etc.) )

  3. La lista de los nombres de las columnas hace que su código sea mucho más autodocumentado y, por lo tanto, probablemente más legible.

  4. Si está transfiriendo a través de una red (o incluso si no lo está), las columnas que no necesita son solo residuos.

30
pkh

Por lo general, especificar la lista de columnas es generalmente la mejor opción porque su aplicación no se verá afectada si alguien agrega/inserta una columna en la tabla.

9
ilitirit

Especificar nombres de columnas es definitivamente más rápido, para el servidor. Pero si

  1. el rendimiento no es un gran problema (por ejemplo, esta es una base de datos de contenido de sitios web con cientos, quizás miles, pero no millones, de filas en cada tabla); Y
  2. su trabajo consiste en crear muchas aplicaciones pequeñas y similares (por ejemplo, sitios web administrados por contenido de cara al público) utilizando un marco común, en lugar de crear una aplicación única compleja; Y
  3. la flexibilidad es importante (mucha personalización del esquema db para cada sitio);

entonces será mejor que te quedes con SELECT *. En nuestro marco, el uso intensivo de SELECT * nos permite introducir un nuevo campo de contenido administrado de sitio web en una tabla, brindándole todos los beneficios del CMS (control de versiones, flujo de trabajo/aprobaciones, etc.), mientras que solo toca el código en una Un par de puntos, en lugar de un par de docenas de puntos.

Sé que los gurús de DB me van a odiar por esto, adelante, voten hacia abajo, pero en mi mundo, el tiempo de desarrollador es escaso y los ciclos de CPU son abundantes, por lo que ajusté en consecuencia lo que conservo y lo que desperdicio.

6
Herb Caudill

SELECT * es una mala práctica, incluso si la consulta no se envía a través de una red.

  1. La selección de más datos de los que necesita hace que la consulta sea menos eficiente: el servidor tiene que leer y transferir datos adicionales, por lo que toma tiempo y crea una carga innecesaria en el sistema (no solo la red, como han mencionado otros, sino también el disco, la CPU, etc.). ). Además, el servidor no puede optimizar la consulta tan bien como podría (por ejemplo, usar el índice de cobertura para la consulta).
  2. Después de algún tiempo, su estructura de tabla puede cambiar, por lo que SELECT * devolverá un conjunto diferente de columnas. Por lo tanto, su aplicación podría obtener un conjunto de datos de estructura inesperada y dividirse en algún lugar hacia abajo. La indicación explícita de las columnas garantiza que obtendrá un conjunto de datos de una estructura conocida u obtenga un error evidente en el nivel de la base de datos (como 'columna no encontrada').

Por supuesto, todo esto no importa mucho para un sistema pequeño y simple.

6
VladV

En cuanto al rendimiento, SELECT con columnas específicas puede ser más rápido (sin necesidad de leer todos los datos). Si su consulta realmente usa TODAS las columnas, se prefiere SELECT con parámetros explícitos. Cualquier diferencia de velocidad será básicamente imperceptible y casi constante. Un día, su esquema cambiará, y este es un buen seguro para evitar problemas debido a esto.

4
Yann Ramin

Muchas buenas razones respondidas aquí hasta ahora, aquí hay otra que no se ha mencionado.

Nombrar explícitamente las columnas lo ayudará con el mantenimiento en el futuro. En algún momento va a realizar cambios o solucionar problemas y se encontrará preguntando "¿dónde diablos está esa columna utilizada?".

Si tiene los nombres listados explícitamente, entonces encontrar todas las referencias a esa columna (a través de todos sus procedimientos almacenados, vistas, etc.) es simple. Simplemente descargue un script CREATE para su esquema de base de datos y busque texto a través de él.

4
Chris Wuestefeld

Realmente debería seleccionar solo los campos que necesita, y solo el número requerido, es decir,.

SELECT Field1, Field2 FROM SomeTable WHERE --(constraints)

Fuera de la base de datos, las consultas dinámicas corren el riesgo de ataques de inyección y datos mal formados. Por lo general, se soluciona utilizando procedimientos almacenados o consultas parametrizadas. Además (aunque en realidad no es mucho problema) el servidor tiene que generar un plan de ejecución cada vez que se ejecuta una consulta dinámica.

4
Matthew Abbott

El problema con "seleccionar *" es la posibilidad de traer datos que realmente no necesita. Durante la consulta de la base de datos real, las columnas seleccionadas no se agregan realmente al cálculo. Lo que realmente es "pesado" es el transporte de datos a su cliente, y cualquier columna que realmente no necesite es simplemente perder el ancho de banda de la red y aumentar el tiempo que está esperando que regrese su consulta.

Incluso si utiliza todas las columnas traídas de un "seleccionar * ...", eso es solo por ahora. Si en el futuro cambia el diseño de la tabla/vista y agrega más columnas, comenzará a incluirlas en sus selecciones aunque no las necesite.

Otro punto en el que una declaración "seleccionar *" es incorrecta es en la creación de la vista. Si crea una vista con "seleccionar *" y luego agrega columnas a su tabla, la definición de la vista y los datos devueltos no coincidirán, y tendrá que volver a compilar sus vistas para que funcionen nuevamente.

Sé que escribir un "select *" es tentador, porque realmente no me gusta especificar manualmente todos los campos de mis consultas, pero cuando su sistema comience a evolucionar, verá que vale la pena dedicar este tiempo adicional./esfuerzo en especificar los campos en lugar de gastar mucho más tiempo y esfuerzo para eliminar errores en sus vistas u optimizar su aplicación.

3
Alexandre Brasil

Mientras que listar columnas de forma explícita es bueno para el rendimiento, no te vuelvas loco.

Entonces, si usa todos los datos, intente SELECT * por simplicidad (imagínese tener muchas columnas y hacer una consulta ÚNASE ... puede ser horrible). Entonces - medir. Compare con la consulta con los nombres de columna enumerados explícitamente.

No especule sobre el rendimiento, mídalo!

La lista explícita es más útil cuando tiene una columna que contiene big data (como el cuerpo de una publicación o artículo), y no la necesita en una consulta dada. Entonces, al no devolverlo en su respuesta, el servidor DB puede ahorrar tiempo, ancho de banda y rendimiento de disco. El resultado de su consulta también será menor, lo que es bueno para cualquier caché de consulta.

3
Paweł Hajdan

definitivamente definiendo las columnas, porque SQL Server no tendrá que hacer una búsqueda en las columnas para extraerlas. Si define las columnas, SQL puede omitir ese paso.

3
Nick Berardi

Siempre es mejor especificar las columnas que necesita, si lo piensa una vez, SQL no tiene que pensar "wtf is *" cada vez que realiza una consulta. Además de eso, alguien más tarde puede agregar columnas a la tabla que realmente no necesita en su consulta y, en ese caso, será mejor que especifique todas sus columnas.

3
BrewinBombers

Seleccionar es igualmente eficiente (en términos de velocidad) si usa * o columnas.

La diferencia es sobre la memoria, no la velocidad. Cuando selecciona varias columnas, SQL Server debe asignar espacio de memoria para que le sirva la consulta, incluidos todos los datos de todas las columnas que ha solicitado, incluso si solo está usando una de ellas.

Lo que importa en términos de rendimiento es el plan de ejecución que, a su vez, depende en gran medida de su cláusula WHERE y la cantidad de ÚNASE, ÚLTIMA ÚNICA, etc.

Para su pregunta solo use SELECT *. Si necesitas todas las columnas no hay diferencia de rendimiento.

2
Jorge Córdoba

El resultado es demasiado grande. Es lento generar y enviar el resultado del motor SQL al cliente.

El lado del cliente, al ser un entorno de programación genérico, no está ni debería estar diseñado para filtrar y procesar los resultados (por ejemplo, la cláusula WHERE, cláusula ORDER), ya que el número de filas puede ser enorme (por ejemplo, decenas de millones de filas).

2
kennytm

Nombrar cada columna que espera obtener en su aplicación también garantiza que no se romperá si alguien altera la tabla, siempre y cuando sus columnas aún estén presentes (en cualquier orden).

2
Don

NO es más rápido usar nombres de campo explícitos en lugar de *, si y solo si, necesita obtener los datos de todos los campos.

El software de su cliente no debería depender del orden de los campos devueltos, por lo que también es una tontería.

Y es posible (aunque improbable) que necesite obtener todos los campos usando * porque todavía no sabe qué campos existen (piense en una estructura de base de datos muy dinámica).

Otra desventaja de usar nombres de campo explícitos es que si hay muchos de ellos y son largos, entonces resulta más difícil leer el código y/o el registro de consultas.

Así que la regla debería ser: si necesita todos los campos, use *, si solo necesita un subconjunto, nómbralos explícitamente.

2
user9385

Depende de la versión de su servidor de base de datos, pero las versiones modernas de SQL pueden almacenar el plan de cualquier manera. Yo diría que vaya con lo que sea más fácil de mantener con su código de acceso a datos.

1
Keith

Una de las razones por las que es mejor especificar exactamente qué columnas desea es debido a posibles cambios futuros en la estructura de la tabla.

Si está leyendo los datos manualmente utilizando un enfoque basado en índices para llenar una estructura de datos con los resultados de su consulta, en el futuro, cuando agregue/elimine una columna, tendrá dolores de cabeza al tratar de descubrir qué fue lo que no funcionó.

En cuanto a lo que es más rápido, voy a ceder a otros por su experiencia.

1
dpollock

Y recuerde que si tiene una unión interna, por definición, no necesita todas las columnas, ya que los datos en las columnas de unión se repiten.

No es como listar columnas en el servidor SQl es difícil o incluso requiere mucho tiempo. Simplemente arrástrelos desde el navegador de objetos (puede hacer todo de una vez arrastrando desde las columnas de Word). Poner un impacto de rendimiento permanente en su sistema (ya que esto puede reducir el uso de índices y el envío de datos innecesarios a través de la red) y hacer que sea más probable que tenga problemas inesperados a medida que la base de datos cambie (a veces se agregan columnas que no quiere que el usuario vea, por ejemplo) solo para ahorrar menos de un minuto de tiempo de desarrollo es miope y poco profesional.

1
HLGEM

Lo que todos dijeron arriba, más:

Si te estás esforzando por un código fácil de leer, haz algo como:

SELECCIONA foo, barra de widgets;

es instantáneamente legible y muestra intención. Si haces esa llamada sabes lo que estás volviendo. Si los widgets solo tienen columnas foo y barra, entonces, al seleccionar * significa que todavía tiene que pensar en lo que está recuperando, confirme que el pedido se haya asignado correctamente, etc. Sin embargo, si los widgets tienen más columnas pero solo está interesado en foo y la barra, entonces su código se vuelve desordenado cuando solicita un comodín y luego solo usa algo de lo que se devuelve.

1
Faisal

SELECCIONAR * es necesario si desea obtener metadatos como el número de columnas.

1
Mark Etable

Para agregar a lo que todos los demás han dicho, si todas las columnas que está seleccionando están incluidas en un índice, su conjunto de resultados se extraerá del índice en lugar de buscar datos adicionales de SQL.

1
Mike

Como con la mayoría de los problemas, depende de lo que quieras lograr. Si desea crear una cuadrícula de db que permita todas las columnas en cualquier tabla, entonces "Seleccionar *" es la respuesta. Sin embargo, si solo necesitará ciertas columnas y agregar o eliminar columnas de la consulta se hace con poca frecuencia, entonces especifíquelas individualmente.

También depende de la cantidad de datos que desee transferir desde el servidor. Si una de las columnas está definida como memo, gráfico, blob, etc. y no necesita esa columna, es mejor que no use "Seleccionar *" o obtendrá un montón de datos que no necesita. Querer y tu rendimiento podría sufrir.

1
Mark

Si la eficiencia importa o no, depende mucho del tamaño de sus conjuntos de datos de producción (y su tasa de crecimiento). Si sus conjuntos de datos no van a ser tan grandes y no van a crecer tan rápidamente, es posible que no haya una gran ventaja en el rendimiento al seleccionar columnas individuales.

Con conjuntos de datos más grandes y tasas de crecimiento de datos más rápidas, la ventaja de rendimiento se vuelve cada vez más importante.

Para ver gráficamente si hay alguna diferencia o no, sugeriría usar el analizador de consultas para ver el plan de ejecución de consultas para un SELECT * y el equivalente SELECT col1, col2, etc. Eso debería decirle cuál de las dos consultas es más eficiente. También puede generar algunos datos de prueba de diferentes volúmenes para ver cuáles son los tiempos.

0
Scott Lawrence

Voy a ser criticado por esto, pero hago una selección * porque casi todos mis datos se recuperan de las Vistas de SQL Server que combinan los valores necesarios de varias tablas en una única Vista de fácil acceso.

Entonces quiero todas las columnas de la vista que no cambiarán cuando se agreguen nuevos campos a las tablas subyacentes. Esto tiene el beneficio adicional de permitirme cambiar de dónde provienen los datos. El Campo A en la Vista puede ser calculado una vez y luego puedo cambiarlo para que sea estático. De cualquier manera, la Vista me proporciona FieldA.

La belleza de esto es que permite que mi capa de datos obtenga conjuntos de datos. Luego los pasa a mi BL que luego puede crear objetos a partir de ellos. Mi aplicación principal solo conoce e interactúa con los objetos. Incluso permito que mis objetos se creen a sí mismos cuando se pasa un datarow.

Por supuesto, soy el único desarrollador, así que eso también ayuda :)

0
klkitchens

Definir absolutamente las columnas que desea seleccionar cada vez. No hay razón para no hacerlo y la mejora del rendimiento merece la pena.

Nunca deberían haber dado la opción de "SELECCIONAR *"

0
cazlab

Si necesita cada columna, simplemente utilice SELECT *, pero recuerde que el orden podría cambiar potencialmente, por lo que cuando consuma los resultados, acceda a ellos por nombre y no por índice.

Ignoraría los comentarios sobre cómo * debe ir a la lista: es probable que el análisis y la validación de columnas con nombre sean iguales al tiempo de procesamiento, si no más. No optimizar prematuramente ;-)

0
DamienG

La principal diferencia entre los dos es la cantidad de datos pasados ​​de un lado a otro. Cualquier argumento sobre la diferencia de tiempo es fundamentalmente defectuoso en que "seleccionar *" y "seleccionar col1, ..., colN" dan como resultado la misma cantidad de trabajo relativo realizado por el motor de DB. Sin embargo, la transmisión de 15 columnas por fila frente a 5 columnas por fila es una diferencia de 10 columnas.

0
Jeff Hubbard

En términos de eficiencia de ejecución, no tengo conocimiento de ninguna diferencia significativa. Pero para la eficiencia de los programadores escribiría los nombres de los campos porque

  • Usted sabe el orden si necesita indexar por número, o si su conductor se comporta de forma extraña en valores de blob, y necesita un orden definido
  • Solo lee los campos que necesita, si alguna vez agrega más campos
  • Obtiene un error de SQL si escribe incorrectamente o renombra un campo, no un valor vacío de un conjunto de registros/fila
  • Puedes leer mejor lo que está pasando.
0
Erik

Veo que varias personas parecen pensar que lleva mucho más tiempo especificar las columnas. Como puede arrastrar la lista de columnas desde el explorador de objetos, puede tardar un minuto más en especificar columnas (es decir, si tiene muchas columnas y necesita dedicar algo de tiempo a colocarlas en líneas separadas) en la consulta. ¿Por qué la gente piensa que es tan lento?

0
HLGEM

Siempre recomiendo especificar las columnas que necesita, en caso de que cambie su esquema y no necesite la columna adicional.

Además, califique los nombres de columna con el nombre de la tabla. Esto es crítico cuando la consulta contiene uniones. Sin las calificaciones de la tabla, puede ser difícil recordar qué columna proviene de qué tabla, y agregar una columna con un nombre similar a una de las otras tablas puede romper su consulta.

0
mxsscott

En cuanto al rendimiento he visto comentarios que ambos son iguales. Pero el aspecto de la usabilidad hay algunos de + y s

Cuando utiliza un (seleccione *) en una consulta y si alguien altera la tabla y agrega nuevos campos que no son necesarios para la consulta anterior, es una sobrecarga innecesaria. ¿Y qué pasa si el campo recién agregado es un blob o un campo de imagen? Tu tiempo de respuesta de consulta va a ser muy lento entonces.

Por otra parte, si usa a (seleccione col1, col2, ..) y si la tabla se modifica y agrega nuevos campos y si esos campos son necesarios en el conjunto de resultados, siempre debe editar su consulta de selección después de la modificación de la tabla.

Pero siempre sugiero utilizar select col1, col2, ... en sus consultas y alterar la consulta si la tabla se modifica más adelante ...

0
Lahiru Cooray

Es particularmente importante que el rendimiento no utilice select * cuando tiene una combinación porque, por definición, al menos dos campos contienen los mismos datos. No desea desperdiciar recursos de red enviando datos que no necesita del servidor de base de datos a la aplicación o al servidor web. Puede parecer más fácil usar select *, pero es una mala práctica. Ya que es fácil arrastrar los nombres de las columnas a la consulta, simplemente haga eso en su lugar.

Otro problema que ocurre cuando se usa select * es que hay idiotas que eligen agregar nuevos campos en el medio de la tabla (siempre es una mala práctica), si usa select * como base para una inserción, de repente su orden de columnas puede ser mal y puede intentar ingresar el número de seguro social en los honorarios (la cantidad de dinero que un orador puede recibir para elegir un ejemplo no aleatorio), lo que podría ser algo muy malo para la integridad de los datos. Incluso si la selección no es una inserción, se ve mal para el cliente cuando los datos están repentinamente en el orden en el informe o la página web.

Creo que pensar en ninguna circunstancia cuando se usa select * es preferible a usar una lista de columnas. Puede pensar que es más fácil de mantener, pero en realidad no lo es y hará que su aplicación se vuelva más lenta sin ninguna razón cuando los campos que no necesita se agregan a las tablas. También tendrá que enfrentar el problema de arreglar las cosas que no se habrían roto si hubiera usado una lista de columnas, por lo que el tiempo que ahorra sin agregar una columna se consume haciendo esto.

0
HLGEM

oye, sé práctico. use select * when prototyping y seleccione columnas específicas al implementar y desplegar. Desde la perspectiva del plan de ejecución, ambos son relativamente idénticos en los sistemas modernos. sin embargo, la selección de columnas específicas limita la cantidad de datos que deben recuperarse del disco, almacenarse en la memoria y enviarse a través de la red.

en última instancia, el mejor plan es seleccionar columnas específicas.

0
siculars

También tenga en cuenta los cambios. Hoy, Select * solo selecciona las columnas que necesita, pero mañana también puede seleccionar la columna varbinary (MAX) que acabo de agregar sin avisarle, y ahora también está recuperando todos los 3.18 Gigabytes de datos binarios que no estaban en la mesa de ayer.

0
Michael Stum

Pensemos en cuál es más rápido. Si puede seleccionar solo los datos que necesita, entonces es más rápido. Sin embargo, al realizar pruebas, puede extraer todos los datos para juzgar qué datos se pueden filtrar según las necesidades comerciales.

0
mikedopp

Hay casos en los que SELECT * es bueno para fines de mantenimiento, pero en general debe evitarse.

Estos son casos especiales como vistas o procedimientos almacenados en los que desea que los cambios en las tablas subyacentes se propaguen sin necesidad de ir y cambiar todas las vistas y procedimientos almacenados que utilizan la tabla. Incluso entonces, esto puede causar problemas en sí mismo, como en el caso de que tenga dos vistas unidas. Una tabla subyacente cambia y ahora la vista es ambigua porque ambas tablas tienen una columna con el mismo nombre. (Tenga en cuenta que esto puede suceder siempre que no califique todas sus columnas con prefijos de tabla). Incluso con prefijos, si tienes una construcción como:

SELECCIONE A., B. - puede tener problemas donde el cliente ahora tiene dificultades para seleccionar el campo correcto.

En general, no uso SELECT * a menos que esté tomando una decisión de diseño consciente y que los riesgos relacionados sean bajos.

0
Cade Roux

El SELECT * podría estar bien si realmente necesitara todas las columnas, pero aún así debería enumerarlas todas individualmente. Ciertamente, no debería seleccionar todas las filas de una tabla, incluso si la aplicación y la base de datos están en el mismo servidor o red. La transferencia de todas las filas llevará tiempo, especialmente a medida que aumenta el número de filas. Debe tener al menos una cláusula donde filtrar los resultados y/o buscar los resultados para seleccionar solo el subconjunto de filas que deben mostrarse. Existen varias herramientas de ORM según el idioma de la aplicación que esté utilizando para ayudar a consultar y localizar el subconjunto de datos que necesita. Por ejemplo, en .NET Linq to SQL, Entity Framework y nHibernate todo le ayudará con esto.

0
bkaid

Use nombres de campo específicos, de modo que si alguien cambia la tabla en usted, no obtendrá resultados inesperados. Sobre el tema: SIEMPRE especifique los nombres de los campos cuando haga una inserción, así que si necesita agregar una columna más adelante, no tiene que volver atrás y reparar su programa y cambiar la base de datos al mismo tiempo en la versión de producción.

0
stu

Si le preocupa la velocidad, asegúrese de usar declaraciones preparadas. De lo contrario, estoy con ilitirit que los cambios es contra lo que te proteges.

/Alano

0
Allan Wind

Considero que la lista de nombres de columnas es particularmente importante si es probable que otros desarrolladores trabajen con el código, o que la base de datos cambie, para que siempre obtenga datos consistentes.

0
Sam Cogan

Este es un post antiguo, pero sigue siendo válido. Para referencia, tengo una consulta muy complicada que consiste en:

  • 12 mesas
  • 6 combinaciones izquierdas
  • 9 uniones internas
  • 108 columnas en total en las 12 tablas
  • Solo necesito 54 columnas
  • Una columna de 4 cláusulas orden por

Cuando ejecuto la consulta usando Select *, toma un promedio de 2869ms. Cuando ejecuto la consulta usando Select, toma un promedio de 1513ms.

El total de filas devueltas es 13,949.

No hay duda de que seleccionar nombres de columna significa un rendimiento más rápido que Select *

Para consultar directamente la base de datos (por ejemplo, en una solicitud de sqlplus o mediante una herramienta de administración de db), seleccionar * generalmente está bien: le ahorra la molestia de escribir todas las columnas.

Por otro lado, en el código de aplicación es mejor enumerar las columnas. Esto tiene varios beneficios:

  • El código es más claro.
  • Sabrá en qué orden regresan los resultados (esto puede o no ser importante para usted)
0
Morikal

Bueno, realmente depende de tus métricas y propósito:

  1. Si tiene 250 columnas y desea (de hecho) seleccionarlas todas, use seleccionar * si desea llegar a casa el mismo día :)
  2. Si su codificación necesita flexibilidad y la tabla que necesita es pequeña, nuevamente, seleccionar * lo ayuda a codificar más rápido y a mantenerlo más fácil.
  3. Si desea una ingeniería y un rendimiento robustos:
    • escriba los nombres de sus columnas si son solo unos pocos, o
    • escribe una herramienta que te permita seleccionar/generar fácilmente los nombres de tus columnas

Como regla general, cuando necesito seleccionar todas las columnas, usaría "seleccionar *" a menos que tenga una razón muy específica para hacerlo de otra manera (además, creo que es más rápido en tablas con muchas, muchas columnas)

Y por último, pero no menos importante, ¿cómo desea agregar o eliminar una columna de la tabla para afectar su código o su mantenimiento?

0
Notitze