Discussion :

[Sango64]

Bonjour,

Voici une requête qui me semblait simple mais dont je ne trouve pas la réponse...
Je suis sous Mysql, je précise car j'ai vu que c'était demandé dans plusieurs discussions ^_^.

Requête : lister l'évolution du nombre de client des 60 derniers jours.

Pour faire au plus simple, j'ai une table "client" avec des deux champs : id_client (int), date_creation_client (datetime).

Voici ma requête :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select date_creation_client, count(*) from client where date_creation_client >= "2016-07-27" group by DATE_FORMAT(date_creation_client, '%Y%m%d');

Ce qui me donne ce type de résultat :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
+---------------------+----------+
| date_creation_client     | count(*) |
+---------------------+----------+
| 2016-07-27 15:41:50 |        4 |
| 2016-07-28 12:24:04 |        2 |
| 2016-07-29 10:09:22 |        2 |
| 2016-07-30 11:45:46 |        1 |
| 2016-07-31 11:13:06 |        1 |
+---------------------+----------+

Hors j'aimerai avoir ce type de résultat :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
+---------------------+----------+
| date_creation_client     | count(*) |
+---------------------+----------+
| 2016-07-27 15:41:50 |        14 | =>  4 + 10 (nombre de client avant cette date)
| 2016-07-28 12:24:04 |        16 | => 2 + 4  (nombre de client du jour précédent) + 10 (nombre de client avant cette date)
| 2016-07-29 10:09:22 |        18 | => etc ...
| 2016-07-30 11:45:46 |        19 |
| 2016-07-31 11:13:06 |        20 |
+---------------------+----------+

J'espère avoir été clair et je vous remercie par avance pour votre aide.

[al1_24]

Ce que tu cherches à faire est une somme cumulée.

Pour obtenir le résultat que tu attends, il faut d'abord identifier les dates de regroupement puis mettre en relation les clients correspondant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
select  dat.date_creation_client
    ,   count(cli.client)
from    (   select  max(date_creation_client)   date_creation_client
            from    client
            where   date_creation_client >= "2016-07-27"
            group by DATE_FORMAT(date_creation_client, '%Y%m%d') 
        )   dat
    inner join
        client  cli
        on  dat.date_creation_client    >= cli.date_creation_client
group by dat.date_creation_client

[Sango64]

Merci beaucoup, c'est exactement le type de résultat que je cherchais à avoir

J'ai légèrement modifié ta requête :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
select  dat.date_creation_client
    ,   count(*)
from    (   select  max(date_creation_client)   date_creation_client
            from    client
            where   date_creation_client >= "2016-07-27"
            group by DATE_FORMAT(date_creation_client, '%Y%m%d') 
        )   dat
    inner join
        client  cli
        on  dat.date_creation_client    >= cli.date_creation_client or cli.date_creation_client is NULL
group by dat.date_creation_client;

La première modification se situe au niveau du "count", j'ai dû mettre une '*' sinon une erreur me remontée :

MariaDB [test]> select dat.date_creation_client , count(cli.client) from ( select max(date_creation_client) date_creation_client from client where date_creation_client >= "2016-07-27" group by DATE_FORMAT(date_creation_client, '%Y%m%d') ) dat inner join client cli on dat.date_creation_client >= cli.date_creation_client or cli.date_creation_client is NULL group by dat.date_creation_client;
ERROR 1054 (42S22): Unknown column 'cli.client' in 'field list'

La deuxième est la prise en compte des dates NULL avec mon 'or' dans la jointure.

Je mets le sujet en résolu

[SQLpro]

Bonjour,

Voici une requête qui me semblait simple mais dont je ne trouve pas la réponse...
Je suis sous Mysql, je précise car j'ai vu que c'était demandé dans plusieurs discussions ^_^.

C'est dommage d'être sous MySQmerde, car avec tout autre SGBDR y compris un vrai libre ceomme PostGreSQL, vous auriez pu faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
select DISTINCT date_creation_client, 
       count(*) OVER(PARTITION BY date_creation_client 
                     ORDER BY date_creation_client) AS NOMBRE_CUMUL
from   client 
where  date_creation_client >= '2016-07-27'

Les performances en plus !!!

À lire sur MySQmerde : http://blog.developpez.com/sqlpro/p9...oudre_aux_yeux

A +

[Sango64]

Merci pour l'information !
Je travaille très peu avec un SGBD et Mysql est plus ou moins imposé dans le projet que j'ai en charge.

Je garde votre article sous le coude

[Sango64]

Je reviens vers vous car j'aimerai compléter la requête que m'a proposé gentiment "al1_24".

Le problème que je rencontre c'est qu'il peut y avoir des dates manquantes dans ma liste de date.

Pour vraiment être clair, voici toutes les informations pour créer la base de données de test :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
CREATE DATABASE test CHARACTER SET utf8 COLLATE utf8_general_ci;
USE test;
 
CREATE TABLE IF NOT EXISTS client (
  id_client INTEGER NOT NULL AUTO_INCREMENT,
  date_creation_client DATETIME,
  PRIMARY KEY (id_client)
)
CHARACTER SET utf8 COLLATE utf8_general_ci;
 
INSERT INTO client (date_creation_client)
VALUES ('2016-07-27 15:41:50'),
('2016-07-18 15:41:50'),
('2016-07-19 15:41:50'),
('2016-07-20 15:41:50'),
('2016-07-21 15:41:50'),
(NULL),
(NULL),
(NULL),
('2016-07-22 15:41:50'),
('2016-07-23 15:41:50'),
('2016-07-24 15:41:50'),
('2016-07-25 15:41:50'),
('2016-07-26 15:41:50'),
('2016-07-27 15:41:50'),
('2016-07-27 16:41:50'),
('2016-07-27 17:41:50'),
('2016-07-27 18:41:50'),
('2016-07-29 10:09:22'),
('2016-07-29 11:09:22'),
('2016-07-31 11:13:06');

Et le résultat que l'on obtient :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
MariaDB [test]> select  dat.date_creation_client
    ->     ,   count(*)
    -> from    (   select  max(date_creation_client)   date_creation_client
    ->             from    client
    ->             where   date_creation_client >= "2016-07-27"
    ->             group by DATE_FORMAT(date_creation_client, '%Y%m%d') 
    ->         )   dat
    ->     inner join
    ->         client  cli
    ->         on  dat.date_creation_client    >= cli.date_creation_client or cli.date_creation_client is NULL
    -> group by dat.date_creation_client;
+----------------------+----------+
| date_creation_client | count(*) |
+----------------------+----------+
| 2016-07-27 18:41:50  |       17 |
| 2016-07-29 11:09:22  |       19 |
| 2016-07-31 11:13:06  |       20 |
+----------------------+----------+

Les calculs sont tous bon mais il me manque des dates ici : "2016-07-28" et "2016-07-30". J'aimerai avoir (si c'est possible) avoir un résultat de ce type :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
+----------------------+----------+
| date_creation_client | count(*) |
+----------------------+----------+
| 2016-07-27 18:41:50  |       17 |
| 2016-07-28 18:41:50  |       17 | <--- on a rajouté la date manquante avec le bon résultat
| 2016-07-29 11:09:22  |       19 |
| 2016-07-30 18:41:50  |       19 | <--- on a rajouté la date manquante avec le bon résultat
| 2016-07-31 11:13:06  |       20 |
+----------------------+----------+

Si dans le résultat les heures ne sont pas présentes cela ne me pose pas de soucis.

En recherchant avec mon ami google, j'ai trouvé un exemple de ce type qui répond exactement à mon besoin ici. Mais il me semble bien compliqué et les performances ne sont pas bonnes, la requête met plus de 4 secondes à s'exécuter sur ma base pré-prod...
J'ai aussi trouvé une solution qui consiste à passer par une table en base de données qui contient le range de date que je souhaite. Cette solution n'est pas adaptée à mon problème car le range de date change tous les jours : NOW() - 60 DAYS.

Peut être en passant par une procédure stockée ? Est ce une bonne idée ?

Merci par avance.

[SQLpro]

Je reviens vers vous car j'aimerai compléter la requête que m'a proposé gentiment "al1_24".

Le problème que je rencontre c'est qu'il peut y avoir des dates manquantes dans ma liste de date..

Dans ce cas il suffit de rajouter à votre base une table de date et faire un RIGHT OUTER JOIN vers cette table et utiliser la date de cette table en lieu et place de vos dates. Vous récupérer ainsi toutes dates manquantes.

Lisez l'article que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/cours/gestiontemps/

A +

[Sango64]

Je vais lire de ce pas votre sujet.
J'aurai aimé ne pas passer par une table temporaire mais si je n'ai pas le choix je pense que je m'y contraindrais.

[SQLpro]

Je vais lire de ce pas votre sujet.
J'aurai aimé ne pas passer par une table temporaire mais si je n'ai pas le choix je pense que je m'y contraindrais.

NON, NON !!!! Il ne s'agit en aucune manière d'une table temporaire, mais d'une table à créer en dur dans votre base.

A +

[SergioMaster]

Bonjour,

Dans ce cas il suffit de rajouter à votre base une table de date et faire un RIGHT OUTER JOIN vers cette table et utiliser la date de cette table en lieu et place de vos dates. Vous récupérer ainsi toutes dates manquantes.

une requête RECURSIVE aurait pu faire l'affaire non ? Mais bien sûr il faudrait que MySQL de ... le permette ?
s'il s'agit de MariaDB il semblerait que ce soit le cas https://mariadb.com/kb/en/sql-99/recursive-unions/
dans la théorie il suffirait donc, dans la requête récursive de
1) récupérer la date du jour - 60 jours
2) de faire une incrémentation 60 fois

[aieeeuuuuu]

s'il s'agit de MariaDB il semblerait que ce soit le cas https://mariadb.com/kb/en/sql-99/recursive-unions/

J'étais étonné, jusqu’à ce que je lise sur la page en question

Note: This page describes features which are not supported by MariaDB.

[SergioMaster]

[SQLpro]

Bonjour,

une requête RECURSIVE aurait pu faire l'affaire non ? Mais bien sûr il faudrait que MySQL de ... le permette ?
s'il s'agit de MariaDB il semblerait que ce soit le cas https://mariadb.com/kb/en/sql-99/recursive-unions/
dans la théorie il suffirait donc, dans la requête récursive de
1) récupérer la date du jour - 60 jours
2) de faire une incrémentation 60 fois

De toutes façons dans ce genre de cas c'est stupide de faire des requêtes récursives qui sont très difficiles à optimiser alors qu'une requête ensembliste y parvient et indexée c'est hyper performant.

A +

[SergioMaster]

Bonjour,

De toutes façons dans ce genre de cas c'est stupide de faire des requêtes récursives qui sont très difficiles à optimiser alors qu'une requête ensembliste y parvient et indexée c'est hyper performant.

Tu peux étayer le "stupide" ?
moi j'y vois l'avantage, de ne pas avoir de table en dur à créer et surtout remplir, bien sûr du coup cette CTE récursive n'est pas indexée mais pour 60 lignes
je ne pense pas qu'il y ait de grosses pénalités de performances

Ceci étant, comme MariaDB n'en a fait qu'un vœux pieux et non une réalité (je me demande bien pourquoi ils fournissent ces informations dans ce cas), tu n'es pas obligé de répondre (sauf pour ma curiosité)

[SQLpro]

Bonjour,

Tu peux étayer le "stupide" ?
moi j'y vois l'avantage, de ne pas avoir de table en dur à créer et surtout remplir, bien sûr du coup cette CTE récursive n'est pas indexée mais pour 60 lignes
je ne pense pas qu'il y ait de grosses pénalités de performances

Ceci étant, comme MariaDB n'en a fait qu'un vœux pieux et non une réalité (je me demande bien pourquoi ils fournissent ces informations dans ce cas), tu n'es pas obligé de répondre (sauf pour ma curiosité)

générer itérativement 60 lignes c'est effectivement pas beaucoup, mais c'est déjà moins rapide que de ne pas les générer. Mais le problème n'est pas de les générer. Le problème c'est d'y accéder. Or une table générée par récursivité n'a pas d'index. Une fois jointe avec une autre table, il faudra toujours faire un scan de table. Mettons que l'autre table possède 10000 lignes, ce qui n'est pas beaucoup. Cela fait donc un produit cartésien de 10 000 x 60 = 600 000 lignes à lire.
Avec un index, la lecture n'est plus itérative et l'on peut espérer au plus 3 lignes à lire soit 10 000 x 3 = 30 000 lignes c'est donc juste 15 fois plus rapide... Une paille
Mais il y a mieux. Dans les bons SGBDR ayant un optimiseur de qualité (je parle pas de MySQmerde...) il y a réutilisation des accès index déjà effectués. On peut espérer que sur 10 000 ligne face à 60, le taux de réutilisation pourrait être d'environ 167 fois (10 000 / 60). Mais comme il y a une date de début et une de fin, divisons par 2 ce résultat soit 83... Au total une optimisation de 1 245 fois...
En pratique je dirais entre 600 et 1000...

Alors ta table récursive, en termes polis, tu peut te la foutre au ...

Enfin, sur les mauvais SGBDR tu n'a aucune certitude que ta table récursive ne soit pas recalculé à la volée pour chaque jointure, cela dépend de comment l'optimiseur fait ses plans... Et dans ce cas l'optimisation avec une table en dur passe à 72 000 !

Ta pensée est celle d'une développeur qui voit l'itération et est incapable de se projeter dans un monde ensembliste ou les avantages sont les suivantes :

• par d'ordre (donc accès n'importe ou dans les tables et index, et par exemple parallélisme possible)
• indexation donc accélération des recherches ou arrangement des lignes

Pour bénéficier de cela il faut que les données des tables et le schéma de la base soient le plus statique possible.

A +

[SergioMaster]

Bonjour,

je suis d'accord sur le fait qu'utiliser une CTE recursive directement sur un ensemble de (selon ton exemple) 10000 lignes est une aberration mais AMHA, dans le cas proposé, l'ensemble sur lequel la jointure se ferait n'est que de au maximum (s'il n'y a pas de trous) 60 lignes puisque produit d'un regroupement (soit la jointure de la CTE récursive pour obtenir les 60 dates et l'autre CTE, requête déjà exprimée plus haut. Sauf que, encore une fois, MySQL ne supporte pas les CTE
Dommage car pour une statistique très certainement pas utilisée souvent cela me semblait acceptable

Ta pensée est celle d'une développeur qui voit l'itération et est incapable de se projeter dans un monde ensembliste ou les avantages sont les suivantes :
par d'ordre (donc accès n'importe ou dans les tables et index, et par exemple parallélisme possible)
indexation donc accélération des recherches ou arrangement des lignes

Je l'avoue ma pensée est bien celle d'un développeur, vieux de surcroit et qui de ce fait a toujours été habitué à réduire la consommation d'espace. Je suis cependant très conscient de la nécessité des index.

Mais dans le cas proposé je doute que la Date de Création d'un Client soit une colonne indexée ?

Enfin, sur les mauvais SGBDR tu n'as aucune certitude que ta table récursive ne soit pas recalculé à la volée pour chaque jointure, cela dépend de comment l'optimiseur fait ses plans.

ça, par contre, je ne l'avais pas envisagé ce serait vraiment avoir affaires avec un mauvais SGBDR

Reste que avec MySQL (ou MariaDB) le seul palliatif à ce manque (CTE) pourrait être une procédure ?
Qui a) créerait une table temporaire avec index << ce qui satisfait à l'indexation et au non recalcul

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
CREATE TEMPORARY TABLE IF NOT EXISTS 
  temp_table ( INDEX(unjour) ) 
ENGINE=MyISAM 
AS 
(
 
)

b) la remplirait en fonction de la date du jour
c) procéderait ensuite à la requête avec UNION
d) puis terminerait par la jointure
mais avec les mauvais SGBDR on sait jamais (déjà que je doute du dateadd )

[Sango64]

Bonjour

Merci pour l'intérêt que vous portez à ma problématique !

Citation Envoyé par Sango64 Voir le message
Je vais lire de ce pas votre sujet.
J'aurai aimé ne pas passer par une table temporaire mais si je n'ai pas le choix je pense que je m'y contraindrais.

NON, NON !!!! Il ne s'agit en aucune manière d'une table temporaire, mais d'une table à créer en dur dans votre base.

A +

Oui pardon dans ma tête je pensais aussi à une table à créer en dur mais c'est pas du tout ce que j'ai écrit >_<

Mais dans le cas proposé je doute que la Date de Création d'un Client soit une colonne indexée ?

Effectivement cette colonne n'est pas indexée.

Pour le moment, j'ai choisi l'option de créer une table en dur dans la base de données. J'ai une procédure stockée qui permet de créer cette table et de la remplir avec de CURRENT_DATE - 1 YEAR à CURRENT_DATE.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
USE `test`;
 
DELIMITER $$
 
DROP PROCEDURE table_dates_create;
 
CREATE PROCEDURE table_dates_create()
BEGIN
 
  DECLARE v_date DATE;
  DECLARE v_dateCurrent DATE;
 
  SET v_date = DATE_SUB(CURRENT_DATE(), INTERVAL 1 YEAR);
  SET v_dateCurrent = CURRENT_DATE();
 
  DROP TABLE IF EXISTS dates;
  CREATE TABLE dates (
    id_date INTEGER NOT NULL AUTO_INCREMENT,
    date DATE,
    PRIMARY KEY (id_date)
  )
  CHARACTER SET utf8 COLLATE utf8_general_ci;
 
  WHILE(DATEDIFF(v_dateCurrent, v_date) >= 0) DO
    INSERT INTO dates (date) VALUES (v_date);
    SET v_date = DATE_ADD(v_date, INTERVAL 1 DAY);
  END WHILE;
 
END $$
DELIMITER ;

J'ai aussi un event qui permet de mettre à jour cette table tous les jours.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
USE `test`;
 
DROP EVENT IF EXISTS updateTableDates;
 
DELIMITER $$
 
CREATE EVENT updateTableDates
ON SCHEDULE EVERY 1 DAY
STARTS '2016-01-01 00:00:00'
COMMENT 'add everyday the new current date and delete the oldest'
DO
  BEGIN
    DECLARE nbDaysInDateTable INT;
    SET nbDaysInDateTable = (SELECT COUNT(*) FROM dates);
 
    IF (nbDaysInDateTable > 365) THEN
      BEGIN
        DELETE FROM dates ORDER BY id_date LIMIT 1;
      END;
    END IF;
 
    INSERT INTO dates SET date=NOW();
  END $$
 
DELIMITER ;

Par la suite j'utilise cette requête :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
select  dat.date_creation_client
    ,   count(*)
from    (   select  dates   date_creation_client
            from    dates
            where   date >= "2016-08-04" 
        )   dat
    inner join
        client  cli
        on  dat.date_creation_client    >= cli.date_creation_client or cli.date_creation_client is NULL
group by dat.date_creation_client;

Cette dernière peut être lente (entre une et deux seconde à s'exécuter) mais elle répond à ma problématique.
Je vais encore chercher si je peux optimiser le temps, si vous avez des idées je suis toujours preneur

Bonne journée.

[SQLpro]

Bonjour,

je suis d'accord sur le fait qu'utiliser une CTE recursive directement sur un ensemble de (selon ton exemple) 10000 lignes est une aberration mais AMHA, dans le cas proposé, l'ensemble sur lequel la jointure se ferait n'est que de au maximum (s'il n'y a pas de trous) 60 lignes puisque produit d'un regroupement (soit la jointure de la CTE récursive pour obtenir les 60 dates et l'autre CTE, requête déjà exprimée plus haut. Sauf que, encore une fois, MySQL ne supporte pas les CTE
Dommage car pour une statistique très certainement pas utilisée souvent cela me semblait acceptable


Je l'avoue ma pensée est bien celle d'un développeur, vieux de surcroit et qui de ce fait a toujours été habitué à réduire la consommation d'espace. Je suis cependant très conscient de la nécessité des index.

Les index permettent de réduire très drastiquement l'espace car une lecture de table (scan) oblige à mettre l'intégralité de la table en cache, ce qui n'est pas le cas de l'index, qui ne met que les pages utilisées, deux ou trois au max...

Mais dans le cas proposé je doute que la Date de Création d'un Client soit une colonne indexée ?

Et pourquoi pas... La nécessité d'un index répond à une problématique de requête, pas à une problématique cosmétique...

ça, par contre, je ne l'avais pas envisagé ce serait vraiment avoir affaires avec un mauvais SGBDR

Reste que avec MySQL (ou MariaDB) le seul palliatif à ce manque (CTE) pourrait être une procédure ?
Qui a) créerait une table temporaire avec index << ce qui satisfait à l'indexation et au non recalcul

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
CREATE TEMPORARY TABLE IF NOT EXISTS 
  temp_table ( INDEX(unjour) ) 
ENGINE=MyISAM 
AS 
(
 
)

b) la remplirait en fonction de la date du jour
c) procéderait ensuite à la requête avec UNION
d) puis terminerait par la jointure
mais avec les mauvais SGBDR on sait jamais (déjà que je doute du dateadd )

Ce serait pire encore, car tu repasse par le monde itératif !!!!

A +

[Waldar]

Cette dernière peut être lente (entre une et deux seconde à s'exécuter) mais elle répond à ma problématique.
Je vais encore chercher si je peux optimiser le temps, si vous avez des idées je suis toujours preneur

Vous l'avez codée dans le mauvais sens.

J'ai regardé en diagonale la discussion, essayez quelque chose comme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
    select dat.dates                        as date_creation_client
         , sum(coalesce(cli.nb_clients, 0)) as nb_clients
      from dates as dat
 left join ( select date_format(date_creation_client, '%Y%m%d') as date_creation_client
                  , count(*)                                    as nb_clients
               from client
              where date_creation_client >= "2016-07-27"
           group by date_format(date_creation_client, '%Y%m%d') ) as cli
        on cli.date_creation_client >= dat.dates
     where dat.dates >= "2016-08-04"
  group by dat.dates
  order by dat.dates asc;

[Sango64]

Bonjour à tous,

Merci pour votre réponse Waldar, votre requête est effectivement beaucoup plus rapide !!

J'ai dû juste l'adapter un peu pour qu'elle réponde entièrement à mon besoin

Voilà ce que ça donne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
MariaDB [test]> select dat.date as date_creation_client
    ->          , sum(cli.nb_clients) as nb_clients
    ->       from dates as dat
    ->       left join ( select
    ->                   CASE WHEN date_creation_client IS NULL THEN '1970-01-01' 
    ->                    ELSE date_format(date_creation_client, '%Y-%m-%d') END as date_creation_client,
    ->                    count(*) as nb_clients
    ->                    from client
    ->                    group by date_creation_client ) as cli
    ->         on dat.date >= cli.date_creation_client
    ->      where dat.date >= "2016-07-22"
    ->   group by dat.date
    ->   order by dat.date asc;
+----------------------+------------+
| date_creation_client | nb_clients |
+----------------------+------------+
| 2016-07-22           |          8 |
| 2016-07-23           |          9 |
| 2016-07-24           |         10 |
| 2016-07-25           |         11 |
| 2016-07-26           |         12 |
| 2016-07-27           |         17 |
| 2016-07-28           |         17 |
| 2016-07-29           |         19 |
| 2016-07-30           |         19 |
| 2016-07-31           |         20 |
| 2016-08-01           |         20 |
| 2016-08-02           |         20 |
| 2016-08-03           |         20 |
| 2016-08-04           |         20 |
| 2016-08-05           |         20 |
| 2016-08-06           |         20 |
| 2016-08-07           |         20 |
| 2016-08-08           |         20 |
| 2016-08-09           |         20 |
| 2016-08-10           |         20 |
| 2016-08-11           |         20 |
| 2016-08-12           |         20 |
| 2016-08-13           |         20 |
| 2016-08-14           |         20 |
| 2016-08-15           |         20 |
| 2016-08-16           |         20 |
| 2016-08-17           |         20 |
| 2016-08-18           |         20 |
| 2016-08-19           |         20 |
| 2016-08-20           |         20 |
| 2016-08-21           |         20 |
| 2016-08-22           |         20 |
| 2016-08-23           |         20 |
| 2016-08-24           |         20 |
| 2016-08-25           |         20 |
| 2016-08-26           |         20 |
| 2016-08-27           |         20 |
| 2016-08-28           |         20 |
| 2016-08-29           |         20 |
| 2016-08-30           |         20 |
| 2016-08-31           |         20 |
| 2016-09-01           |         20 |
| 2016-09-02           |         20 |
| 2016-09-03           |         20 |
| 2016-09-04           |         20 |
| 2016-09-05           |         20 |
| 2016-09-06           |         20 |
| 2016-09-07           |         20 |
| 2016-09-08           |         20 |
| 2016-09-09           |         20 |
| 2016-09-10           |         20 |
| 2016-09-11           |         20 |
| 2016-09-12           |         20 |
| 2016-09-13           |         20 |
| 2016-09-14           |         20 |
| 2016-09-15           |         20 |
| 2016-09-16           |         20 |
| 2016-09-17           |         20 |
| 2016-09-18           |         20 |
| 2016-09-19           |         20 |
| 2016-09-20           |         20 |
| 2016-09-21           |         20 |
| 2016-09-22           |         20 |
| 2016-09-23           |         20 |
| 2016-09-24           |         20 |
| 2016-09-25           |         20 |
| 2016-09-26           |         20 |
| 2016-09-27           |         20 |
| 2016-09-28           |         20 |
| 2016-09-29           |         20 |
| 2016-09-30           |         20 |
| 2016-10-01           |         20 |
| 2016-10-02           |         20 |
| 2016-10-03           |         20 |
| 2016-10-04           |         20 |
| 2016-10-05           |         20 |
+----------------------+------------+
76 rows in set, 1 warning (0.00 sec)

Avez vous une explication de cette différence d'exécution entre la requête précédente et celle ci alors que la votre semble visuellement un peu plus complexe ?