Question

Parce que le vocabulaire décrivant ce que j'aimerais faire peut être si disparate, je n'ai pas eu de chance pour comprendre pourquoi MySQL 5.6 fait ce qu'il fait.

Considérez les deux requêtes simples suivantes:

#1
select sum(amount) as amt,
    (sum(amount) * (0.000+coalesce((select gas from gas_prices gp where gp.yw=yearweek(gl.stamp,0)),3.50))) as cost
from gas_log gl
where date_format(gl.stamp,'%X')=2013;

#2
select sum(amount) as amt,
    (sum(amount) * (0.000+coalesce((select gas from gas_prices gp where gp.yw=yearweek(gl.stamp,0)),3.50))) as cost
from gas_log gl
where date_format(gl.stamp,'%X')=2013 group by yearweek(gl.stamp,0);

La deuxième requête est identique au premier, avec un groupe simple pour obtenir les totaux hebdomadaires au lieu des totaux annuels. Les deux requêtes ont des sorties d'explication presque identiques:

+----+--------------------+-------+------+---------------+------+---------+------+------+----------------------------------------------+
| id | select_type        | table | type | possible_keys | key  | key_len | ref  | rows | Extra                                        |
+----+--------------------+-------+------+---------------+------+---------+------+------+----------------------------------------------+
|  1 | PRIMARY            | gl    | ALL  | NULL          | NULL | NULL    | NULL | 7428 | Using where; Using temporary; Using filesort |
|  2 | DEPENDENT SUBQUERY | gp    | ALL  | yw            | NULL | NULL    | NULL |   52 | Using where                                  |
+----+--------------------+-------+------+---------------+------+---------+------+------+----------------------------------------------+


+----+--------------------+-------+------+---------------+------+---------+------+------+-------------+
| id | select_type        | table | type | possible_keys | key  | key_len | ref  | rows | Extra       |
+----+--------------------+-------+------+---------------+------+---------+------+------+-------------+
|  1 | PRIMARY            | gl    | ALL  | NULL          | NULL | NULL    | NULL | 7428 | Using where |
|  2 | DEPENDENT SUBQUERY | gp    | ALL  | yw            | NULL | NULL    | NULL |   52 | Using where |
+----+--------------------+-------+------+---------------+------+---------+------+------+-------------+

gas_log Contient un horodatage du moment où le gaz a été pompé et combien a été pompé. gas_prices ressemble à ça:

10:11:09> select * from gas_prices limit 2;
+------------+--------+-------+--------+
| date       | yw     | gas   | diesel |
+------------+--------+-------+--------+
| 2013-01-07 | 201301 | 3.235 |  3.870 |
| 2013-01-14 | 201302 | 3.265 |  3.834 |
+------------+--------+-------+--------+

Pour la première requête, MySQL exécute la sous-requête uniquement et utilise cette valeur (trouvée en correspondant à la première ligne récupérée à partir de gas_log Contre sa semaine correspondante dans gas_prices) pour se multiplier avec la somme de tous les gallons connectés dans le journal des gaz, tandis que dans la deuxième requête, il fait ce que je suis réellement après: exécutez la sous-requête pour chacune des 52 semaines groupées en 2013, correspondant au prix du gaz de chaque semaine en conséquence.

Utilisant with rollup sur le group by fournit un résultat intéressant; Au lieu d'utiliser le premier prix de gaz dans la minuterie, il utilise le dernier! Ainsi, il fournit toujours un total de coûts incorrects pour tout girloge couvrant plus de la semaine.

Existe-t-il un moyen de réécrire la requête pour amener MySQL à présenter un total pour une minuterie donnée, mais correspond toujours à chacun gas_log Rimer à son prix correspondant dans gas_prices?

Pas de solution correcte

Licencié sous: CC-BY-SA avec attribution
Non affilié à dba.stackexchange
scroll top