MySQL somme cumulative regroupées par date

Je sais qu'il y a eu quelques messages liés à cette, mais mon cas est un peu différent et je voulais avoir de l'aide sur ce.

J'ai besoin de tirer des données de la base de données qui est le nombre total d'interactions par jour. actuellement, c'est ce que j'ai

SELECT
   e.Date AS e_date,
   count(e.ID) AS num_interactions
FROM example AS e
JOIN example e1 ON e1.Date <= e.Date
GROUP BY e.Date;

La sortie de cette est proche de ce que je veux, mais pas exactement ce dont j'ai besoin.
le problème, je vais avoir, c'est les dates sont stockées avec l'heure, la minute et la seconde que l'interaction qui s'est passé, de sorte que le groupe en est pas de regroupement jours ensemble.

c'est ce à quoi ressemble la sortie. http://screencast.com/t/N1KFNFyil
sur 12-23 theres 5 interactions mais ce n'est pas groupés parce que l'horodatage est différent. j'ai donc besoin de trouver un moyen d'ignorer le timestamp et il suffit de regarder le jour.

si j'essaie GROUP BY DAY(e.Date) il regroupe les données par jour (j'.e tout ce qui est arrivé le 1er de chaque mois, sont regroupées en une seule ligne) et la sortie n'est pas ce que je veux, à tous les http://screencast.com/t/HN6DH3GV63M

GROUP BY DAY(e.Date), MONTH(e.Date) est de le diviser par mois et le jour du mois, mais encore une fois le compte est désactivé.

Je ne suis pas un MySQL expert à tous donc je suis perplexe sur ce que je suis absent

c'est le groupe par JOUR(), MOIS() capture d'écran. ne pouvait pas ajouter plus que 2 dans mon post. screencast.com/t/MnaXK7nLkY

OriginalL'auteur John Ruddell | 2014-03-09

  1. 14

    Nouvelle Réponse

    Au début, je ne comprenais pas que vous étiez en train de faire une course totale. Voici comment cela pourrait ressembler:

    SET @runningTotal = 0;
SELECT 
    e_date,
    num_interactions,
    @runningTotal := @runningTotal + totals.num_interactions AS runningTotal
FROM
(SELECT 
    DATE(eDate) AS e_date,
    COUNT(*) AS num_interactions
FROM example AS e
GROUP BY DATE(e.Date)) totals
ORDER BY e_date;

    Réponse Originale À Cette Question

    Vous pourriez obtenir des doublons en raison de votre jointure. Peut-être que e1 a plus d'un match de certaines lignes qui est de gonfler votre compte. Soit ça, soit la comparaison dans votre jointure est également de comparer les secondes, ce qui n'est pas ce que vous attendez.

    De toute façon, au lieu de couper le champ datetime dans les jours et les mois, juste la bande de l'époque. Voici comment vous le faites.

    SELECT
   DATE(e.Date) AS e_date,
   count(e.ID) AS num_interactions
FROM example AS e
JOIN example e1 ON DATE(e1.Date) <= DATE(e.Date)
GROUP BY DATE(e.Date);
    je vous remercie pour votre réponse. le décapage le temps est ce que je voulais faire. Je ne suis pas d'obtenir les bons résultats de encore donc je pense que cela a à voir avec la jointure. ce que je veux, c'est si le nombre est de 3 le premier jour, puis 4 sur la deuxième journée de l'affichage 7 pour la deuxième journée(le montant cumulé de la précédente avec le courant). le comte est gonflé, toujours avec la joindre par DATE() screencast.com/t/qcsRcZt7Ws4z... il y a seulement 5 interactions sur 2013-12-23.. donc je suppose que j'ai besoin de réfléchir à une façon différente de faire cela.
    Donc, le problème avec la jointure est son correspondant à chaque enregistrement avec tous les possibles. aka.. si il y a 5 cas, alors il correspond à 1 à tous les 5 puis le suivant avec tous les 5 de sorte que le comte est gonflé à 25 au lieu de 5. des idées quant à la façon de résoudre ce problème?
    Désolé, je n'avais pas compris que vous étiez en train de faire une course totale. Je vais ajouter à ma réponse
    Ce qui est excellent, car il fonctionne bien, même avec de grands ensembles de données
    Grande réponse @clhereistian (le tableau est lu une seule fois)! Merci, ça m'aide beaucoup. Astuce: si vous utilisez un ORM (comme Doctrine en PHP) qui peut accepte une requête par l'exécution : remplacer le SET @runningTotal = 0; par @runningTotal := 0, dans la sous-requête 🙂 (Cette astuce peut également vous aide à vous/moi de faire du multi-somme cumulative de l'UNION entre les requêtes)

    OriginalL'auteur clhereistian

  2. 11

    J'ai compris ce que je devais faire la nuit dernière... mais depuis que je suis nouveau à cela, je ne pouvais pas le poster alors... ce que j'ai fait qui a travaillé était ceci:

    SELECT
   DATE(e.Date) AS e_date,
   count(e.ID) AS num_daily_interactions,
   (
      SELECT 
         COUNT(id)
      FROM example 
      WHERE DATE(Date) <= e_date
   ) as total_interactions_per_day
FROM example AS e
GROUP BY e_date;

    Que ce serait moins efficace que votre requête? Je peut juste faire le calcul en python après en tirant le comte par jour si son plus efficace, parce que ce sera sur l'échelle de quelques milliers à des centaines de milliers de lignes retournées.

    Votre requête est bonne. Assurez-vous simplement votre date de comparaison est d'obtenir ce que vous attendez depuis que vous êtes à la comparaison d'une date de type pour un type datetime.
    la réponse est ce que je veux. je suis juste un peu hésitant, car il sera lente que ce tableau se développe. encore une fois merci pour tout.. très utile
    Je voudrais essayer d'Expliquer à la fois les requêtes. Je crois que ce l'on va exécuter la sous-requête pour chaque date, ce qui ne devrait pas être plus lente si nous avons le bon indice, mais @clhereistian n'a qu'un seul groupe par et puis juste itère sur elle, ce qui peut être mieux (en particulier si - c'était mon cas - vous avez en supplément, non-indexé les conditions de filtrage).
    J'ai fini par changer cette requête parce que c'était prendre un certain temps. si vous regardez mes plus récentes questions que j'ai poser une question au sujet de l'optimisation.. fini par aller avec deux requêtes et faire juste le nombre cumulatif en python... la requête a commencé à prendre les 14 et 15 secondes pour s'exécuter lorsque l'on compare 300 000 enregistrements à lui-même.. c'est 90,000,000,000 lignes à vérifier.. sa indexés et optimisé juste encore un peu avec beaucoup de les comparer.

    OriginalL'auteur John Ruddell