Ya estoy inscrito ¿Todavía no tienes acceso? Nuestros Planes
Ya estoy inscrito ¿Todavía no tienes acceso? Nuestros Planes
1
respuesta

QUERY COST variable

De acuerdo al video sobre las consultas más complejas y uso de joins y otras funciones como el group by u order by aporta mucho costo pero en donde estoy haciendo mis consultas sigue con el mismo numero de costo.

mysql> explain format=json SELECT p.codigo, YEAR(f.fecha) as anio, i.cantidad FROM tb_producto p INNER JOIN tb_item i ON i.codigo = p.codigo INNER JOIN tb_factura f ON f.numero = i.numero \G;
*************************** 1. row ***************************
EXPLAIN: {
  "query_block": {
    "select_id": 1,
    "cost_info": {
      "query_cost": "140304.75"
    },
    "nested_loop": [
      {
        "table": {
          "table_name": "p",
          "access_type": "index",
          "possible_keys": [
            "PRIMARY"
          ],
          "key": "PRIMARY",
          "used_key_parts": [
            "codigo"
          ],
          "key_length": "42",
          "rows_examined_per_scan": 35,
          "rows_produced_per_join": 35,
          "filtered": "100.00",
          "using_index": true,
          "cost_info": {
            "read_cost": "0.25",
            "eval_cost": "3.50",
            "prefix_cost": "3.75",
            "data_read_per_join": "36K"
          },
          "used_columns": [
            "codigo"
          ]
ERROR:
No query specified

mysql> explain format=json SELECT p.codigo, YEAR(f.fecha) as anio, SUM(i.cantidad) as cantida_sum FROM tb_producto p INNER JOIN tb_item i ON i.codigo = p.codigo INNER JOIN tb_factura f ON f.numero = i.numero GROUP BY p.codigo, YEAR(f.fecha) ORDER BY p.codigo, YEAR(f.fecha) \G;
*************************** 1. row ***************************
EXPLAIN: {
  "query_block": {
    "select_id": 1,
    "cost_info": {
      "query_cost": "140304.75"
    },
    "ordering_operation": {
      "using_filesort": false,
      "grouping_operation": {
        "using_temporary_table": true,
        "using_filesort": true,
        "nested_loop": [
          {
            "table": {
              "table_name": "p",
              "access_type": "index",
              "possible_keys": [
                "PRIMARY"
              ],
              "key": "PRIMARY",
              "used_key_parts": [
                "codigo"
              ],
              "key_length": "42",
              "rows_examined_per_scan": 35,
              "rows_produced_per_join": 35,
              "filtered": "100.00",
              "using_index": true,
              "cost_info": {
                "read_cost": "0.25",
                "eval_cost": "3.50",
                "prefix_cost": "3.75",
                "data_read_per_join": "36K"
              },
              "used_columns": [
                "codigo"
              ]
1 respuesta

Hola Leodan,

Entiendo que estás observando que el "query_cost" no cambia en tus consultas a pesar de haber agregado operaciones como GROUP BY y ORDER BY. Esto puede ser un poco confuso al principio, pero hay algunas razones por las cuales esto podría estar sucediendo.

El "query_cost" que ves en el resultado de EXPLAIN FORMAT=JSON es una estimación del costo total de ejecutar la consulta, basado en varios factores como el número de filas que se espera que sean examinadas y los índices utilizados. Sin embargo, este costo no siempre refleja cambios menores en la consulta, especialmente si la estructura general de la consulta y las tablas involucradas no cambian significativamente.

Aquí hay algunas cosas que podrías considerar para entender mejor por qué el costo no cambia:

  1. Índices: Si las tablas ya están bien indexadas, especialmente en las columnas utilizadas en los JOINs, GROUP BY y ORDER BY, el costo adicional de estas operaciones puede ser mínimo. Verifica si tienes índices en las columnas que estás utilizando para estas operaciones.

  2. Tamaño de los datos: Si estás trabajando con un conjunto de datos relativamente pequeño, los cambios en el costo pueden ser menos evidentes. A medida que el tamaño de los datos crezca, es posible que veas diferencias más pronunciadas.

  3. Optimización del plan de ejecución: MySQL puede optimizar el plan de ejecución de manera que las operaciones adicionales no impacten significativamente el costo si se pueden realizar de manera eficiente.

  4. Verifica otras métricas: Además del "query_cost", observa otras métricas en el plan de ejecución, como rows_examined_per_scan y rows_produced_per_join, para tener una idea más completa de cómo se está ejecutando la consulta.

Como ejemplo práctico, si tienes una tabla tb_producto con un índice en la columna codigo, y estás realizando un JOIN basado en esta columna, MySQL puede utilizar eficientemente este índice para minimizar el costo de la operación, incluso si agregas un GROUP BY o ORDER BY.

Espero que estas ideas te ayuden a comprender mejor lo que está ocurriendo con tus consultas. ¡Espero haber ayudado y buenos estudios!

Si este post te ayudó, por favor, marca como solucionado ✓. Continúa con tus estudios!