# Always long running queries against email\_stats (5+ hours)

**URL:** <https://forum.mautic.org/t/always-long-running-queries-against-email-stats-5-hours/23898>\
**Category:** Product Support\
**Created:** [April 27, 2022, 12:14am UTC](https://forum.mautic.org/t/always-long-running-queries-against-email-stats-5-hours/23898 "2022-04-27T00:14:15Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![renatocron](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.mautic.org/renatocron/32/6936_2.png) [@renatocron](https://forum.mautic.org/u/renatocron)\
**Post date:** [April 27, 2022, 1:10am UTC](https://forum.mautic.org/t/always-long-running-queries-against-email-stats-5-hours/23898/2 "2022-04-27T01:10:20Z")

</div>

Hi there,

Can you post some more info:  
Full email\_stats count/size  
Full email\_stats count where ch.date\_sent \> $foo  
Size of the indexes  
What storage engine the database/tables are

I dont think lead\_frequencyrules is being used, but that should not affect the query too much.  
That query maybe coming from a campaign, that’s why that has so many leads.

If possible to run the real query with EXPLAIN, you may be able to see what part exactly it’s stuck, or strace -p in the worse case.

I don’t have too much knowledge on the internals/query tunning of mysql, but AFAIK it can only do one index a time, and that list with a lot of IN is not going to be using the index (at least if this was postgres, it will try to do a (parallelo) seq scan, that will inevitability be slow

Also, did ever tried to use MariaDB instead? Mautic can run fine on mariadb:10.5.10 with ~ 30k leads/100k emails/week with 1 year retation, but I also have some smaller mautic running on percona-server:5.7  
the only time I had a CPU spike was when I was using this segment: [Slow segment runtime](https://forum.mautic.org/t/slow-segment-runtime/22816)

---

_[View the full topic](https://forum.mautic.org/t/always-long-running-queries-against-email-stats-5-hours/23898)._