He estado trabajando para diferentes compañías, y he notado que algunas de ellas prefieren tener puntos de vista que se unirán a una mesa con todos sus "familiares". Pero luego, en la aplicación algunas veces, solo necesitamos usar solo 1 columna.

Entonces, ¿sería más rápido hacer selecciones simples y luego "unirlas" en el código del sistema?

El sistema podría ser php, java, asp, cualquier idioma que se conecte a la base de datos.

Entonces, la pregunta es, ¿qué pasa más rápido desde un lado del servidor (php, java, asp, ruby, python ...) a la base de datos? Ejecute una consulta que obtenga todo lo que necesitamos o vaya del lado del servidor a la base de datos y ejecute un consulta que solo obtiene las columnas de una tabla a la vez?

Lo que abordaría su pregunta es el tema ÚNASE A LA DESCOMPOSICIÓN.

De acuerdo con la página 209 del libro

Puede descomponer una combinación ejecutando múltiples consultas de tabla única en lugar de una combinación multitarea y luego realizando la combinación en la aplicación. Por ejemplo, en lugar de esta consulta única:

SELECT * FROM tag
JOIN tag_post ON tag_post.tag_id = tag.id
JOIN post ON tag_post.post_id = post.id
WHERE tag.tag = 'mysql';

Puede ejecutar estas consultas:

SELECT * FROM tag WHERE tag = 'mysql';
SELECT * FROM tag_post WHERE tag_id=1234;
SELECT * FROM post WHERE post.id IN (123,456,567,9098,8904);

¿Por qué demonios harías esto? A primera vista, parece un desperdicio, porque ha aumentado el número de consultas sin obtener nada a cambio. Sin embargo, tal reestructuración en realidad puede brindar importantes ventajas de rendimiento:

• El almacenamiento en caché puede ser más eficiente. Muchas aplicaciones almacenan en caché los "objetos" que se asignan directamente a las tablas. En este ejemplo, si el objeto con la etiqueta mysqlya está en caché, la aplicación omitirá la primera consulta. Si encuentra publicaciones con un ID de 123, 567 o 908 en la memoria caché, puede eliminarlas de la IN()lista. El caché de consultas también podría beneficiarse de esta estrategia. Si solo una de las tablas cambia con frecuencia, descomponer una unión puede reducir el número de invalidaciones de caché.
• Ejecutar las consultas individualmente a veces puede reducir la contención de bloqueo
• Hacer uniones en la aplicación hace que sea más fácil escalar la base de datos al colocar tablas en diferentes servidores.
• Las consultas en sí mismas pueden ser más eficientes. En este ejemplo, el uso de una IN()lista en lugar de una combinación permite a MySQL ordenar las ID de fila y recuperar filas de manera más óptima de lo que podría ser posible con una combinación.
• Puede reducir los accesos a filas redundantes. Hacer una unión en la aplicación significa recuperar cada fila solo una vez, mientras que una unión en la consulta es esencialmente una desnormalización que puede acceder repetidamente a los mismos datos. Por la misma razón, dicha reestructuración también podría reducir el tráfico total de la red y el uso de memoria.
• Hasta cierto punto, puede ver esta técnica como la implementación manual de una combinación hash en lugar del algoritmo de bucles anidados que MySQL usa para ejecutar una combinación. Una combinación hash podría ser más eficiente.

Como resultado, las uniones de acciones en la aplicación pueden ser más eficientes cuando almacena en caché y reutiliza una gran cantidad de datos de consultas anteriores, distribuye datos en varios servidores, reemplaza las uniones por IN()listas o una unión hace referencia a la misma tabla varias veces.

OBSERVACIÓN

Me gusta la primera viñeta porque InnoDB es un poco pesado cuando verifica la caché de consultas.

• Sep 05, 2012: ¿Vale la pena la sobrecarga de invalidación frecuente de caché de consultas?
• Jun 07, 2014: ¿Por qué query_cache_type está deshabilitado de manera predeterminada desde MySQL 5.6?

En cuanto al último punto, escribí una publicación el 11 de marzo de 2013 ( ¿Hay una diferencia de ejecución entre una condición JOIN y una condición WHERE? ) Que describe el algoritmo de bucle anidado. Después de leerlo, verá cuán buena puede ser la descomposición de unión.

En cuanto a todos los demás puntos del libro , los desarrolladores realmente buscan el rendimiento como resultado final. Algunos confían en medios externos (fuera de la aplicación) para mejorar el rendimiento, como usar un disco rápido, obtener más CPU / núcleos, ajustar el motor de almacenamiento y ajustar el archivo de configuración. Otros se abrocharán y escribirán un mejor código. Algunos pueden recurrir a la codificación de toda la inteligencia empresarial en los Procedimientos almacenados, pero aún así no aplican la descomposición conjunta (consulte ¿Cuáles son los argumentos en contra o para poner la lógica de la aplicación en la capa de la base de datos? Junto con las otras publicaciones). Todo depende de la cultura y la tolerancia de cada tienda de desarrolladores.

Algunos pueden estar satisfechos con el rendimiento y no tocar más el código. Otros simplemente no se dan cuenta de que hay grandes beneficios que uno puede cosechar si intentan unir la composición.

Para aquellos desarrolladores que estén dispuestos ...

DARLE UNA OPORTUNIDAD !!!

En Postgres (y probablemente cualquier RDBMS en un grado similar, MySQL en menor medida), menos consultas son casi siempre mucho más rápidas.

La sobrecarga de analizar y planificar múltiples consultas ya es más que cualquier ganancia posible en la mayoría de los casos.

Por no hablar del trabajo adicional que se debe hacer en el cliente, combinando los resultados, que generalmente es mucho más lento. Un RDBMS se especializa en ese tipo de tarea y las operaciones se basan en tipos de datos originales. No hay que enviar texty volver resultados intermedios ni transformarlos en tipos nativos del cliente, lo que puede incluso conducir a resultados menos correctos (¡o incorrectos!). Piensa en números de coma flotante ...

También transfiere más datos entre el servidor DB y el cliente. Esto puede ser insignificante para una mano llena de valores, o hacer una gran diferencia.

Si las consultas múltiples significan múltiples viajes de ida y vuelta al servidor de la base de datos, también recopila varias veces la latencia de la red y la sobrecarga de la transacción, posiblemente incluso la sobrecarga de la conexión. Gran, gran pérdida.

Dependiendo de su configuración, la latencia de la red por sí sola puede tomar más tiempo que el resto por orden de magnitud.

Pregunta relacionada sobre SO:

• ¿Cual es mejor? Realizar cálculos en sql o en su aplicación

Puede haber un punto de inflexión para consultas muy grandes y de larga duración porque las transacciones recopilan bloqueos en las filas de la base de datos en el camino. Las consultas muy grandes pueden contener muchos bloqueos durante un período prolongado de tiempo, lo que puede causar fricción con las consultas concurrentes .