<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
    <channel>
        <title>MySQL Forums - Performance</title>
        <description>Forum for MySQL Performance and Benchmarks.</description>
        <link>https://forums.mysql.com/list.php?24</link>
        <lastBuildDate>Sun, 17 May 2026 20:59:51 +0000</lastBuildDate>
        <generator>Phorum 5.2.23</generator>
        <item>
            <guid>https://forums.mysql.com/read.php?24,741107,741107#msg-741107</guid>
            <title>Increased Statistics Ratio in Database Load on Performance Insights When vCPU is Exceeded in AWS RDS for MySQL (8.0.42) During Load Spikes (no replies)</title>
            <link>https://forums.mysql.com/read.php?24,741107,741107#msg-741107</link>
            <description><![CDATA[ Hello, I am using AWS RDS for MySQL (8.0.42).<br />
For performance testing related to an event, I applied a spike load to the database. The load was approximately 7 to 8 times the current vCPU capacity, with a sudden influx of concurrent users. During this time, I noticed an unusually high ratio of statistics in the database load on Performance Insights, which does not occur under normal conditions. Could you please provide advice on the possible causes of this issue and any recommendations for improvement?<br />
Let me know if you need help refining the phrasing or adding more technical details!]]></description>
            <dc:creator>wanseok kim</dc:creator>
            <category>Performance</category>
            <pubDate>Wed, 20 Aug 2025 04:22:58 +0000</pubDate>
        </item>
        <item>
            <guid>https://forums.mysql.com/read.php?24,740586,740586#msg-740586</guid>
            <title>Refresh MySQL on RDS Amazon (no replies)</title>
            <link>https://forums.mysql.com/read.php?24,740586,740586#msg-740586</link>
            <description><![CDATA[ Hi Experts,<br />
Iam a Microsoft sql server dba, currently taking task on MySQL on AWS RDS.<br />
I have a question how do we refresh Database from Production to Developemtn environment.If i take export the database and then import database.What happens to users &amp; Logins will the existing users/logins on developemnt environment still be able to connect the development database,So iam assuming steps to be<br />
1.Take the import from production database.<br />
2.Take all the logins/users access information script it out<br />
3.Once the developement database is imported <br />
4.Run the users/login scripts on the dev database.<br />
<br />
Could you please let me know how do i refresh database from production .<br />
Thank in advance.]]></description>
            <dc:creator>sandeep rathore</dc:creator>
            <category>Performance</category>
            <pubDate>Thu, 17 Apr 2025 08:17:58 +0000</pubDate>
        </item>
        <item>
            <guid>https://forums.mysql.com/read.php?24,740489,740489#msg-740489</guid>
            <title>MySQL Workbench username (?!?), SSL CA (?!?) (no replies)</title>
            <link>https://forums.mysql.com/read.php?24,740489,740489#msg-740489</link>
            <description><![CDATA[ I am studying for my third SQL certification on Coursera. It requires<br />
downloading the &quot;Connecting to Mode Analytics - Updated.pdf&quot; (MODE:<br />
<a href="https://mode.com/"  rel="nofollow">https://mode.com/</a>), which on page 5 provides the option to connect to a<br />
database. I chose MySQL, but it is asking me to provide four pieces of<br />
information that I have never been asked while working with MySQL <br />
Workbench 8.0:<br />
<br />
It is asking for:<br />
(1) A username (Is this for MySQL Workbench?),<br />
(2) A password (Is this for MySQL Workbench?),<br />
(3) A &quot;Custom Trusted SSL CA Certificate&quot; (I&#039;m not sure where to get this),<br />
(4) To &quot;Choose a file&quot; (What kind of file is this?).<br />
<br />
Does MySQL have a default username? I have never been asked for one.<br />
If so, where can I find it?<br />
-<br />
Does anyone know what the &quot;Custom Trusted SSL CA Certificate&quot; refers to<br />
and where I can obtain it or choose it from?<br />
-<br />
And does anyone know what file I need to choose for the &quot;Choose a file&quot; <br />
option? What kind of file is it referring to?<br />
-<br />
I hope someone has gone through this environment setup and understands<br />
what the MODE site is asking for. Any assistance would be much appreciated!]]></description>
            <dc:creator>David Hernandez</dc:creator>
            <category>Performance</category>
            <pubDate>Sun, 23 Mar 2025 21:27:59 +0000</pubDate>
        </item>
        <item>
            <guid>https://forums.mysql.com/read.php?24,740302,740302#msg-740302</guid>
            <title>MySQL running VERY slowly on a new i9 machine.  Ideas or advice? (1 reply)</title>
            <link>https://forums.mysql.com/read.php?24,740302,740302#msg-740302</link>
            <description><![CDATA[ Hello All:<br />
<br />
I have been using MySQL 8.0.26 on my i7 Dell Inspiron laptop for about 5 years (full specs below).  Last week, I purchased some upgraded hardware for an important project: An i9 CyberPowerPC gaming computer with 64 Gig of RAM.<br />
<br />
The problem is that the exact same MySQL queries are running MUCH slower on the i9 machine compared with my i7 laptop.  The databases and tables are identical (I just finished migrating them), as are the MySQL configs.  <br />
<br />
Using one of my more complex queries, I benchmarked some performance numbers. <br />
 As you can see, the new machine is slower by a factor of more than 2x:<br />
<br />
 - CyberPowerPC i9: MySQL Query Test<br />
   + Run Time = 219.188 seconds<br />
<br />
 - Dell i7: MySQL Query Test<br />
   + Run Time = 98.297 seconds<br />
<br />
I know the CyberPowerPC is not running slowly for everything.  Below are some benchmark numbers for a particularly large and complex spreadsheet.  As you can see, the new hardware does buy me quite a bit of performance in Excel.<br />
<br />
 - CyberPowerPC: Excel Sheet Test<br />
   + Open File = 17.42 seconds<br />
   + Run Analysis = 1:41 minutes/seconds<br />
   + Clear Filter = 24.24 seconds<br />
   + Recalc = 6.43 seconds<br />
<br />
<br />
 - Dell Laptop: Excel Sheet Test<br />
   + Open File = 29.42 seconds<br />
   + Run Analysis = 2:47 minutes/seconds<br />
   + Clear Filter = 39.18 seconds<br />
   + Recalc = 14.00 seconds<br />
<br />
What is going on here?  Can I resolve this?  Or should I get a different machine?<br />
<br />
Any help would be appreciated!<br />
<br />
Ken<br />
<br />
<br />
Full Specs:<br />
<br />
Dell Inspiron Laptop<br />
 - 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz   2.80 GHz<br />
 - 16.0 GB Ram<br />
 - 64 bit Windows 10 Home<br />
 - 1 TB SSD<br />
 - MySQL 8.0.26 (64 bit)<br />
<br />
CyberPowerPC Gaming Desktop<br />
 - Intel(R) Core(TM) i9-14900KF   3.20 GHz<br />
 - 64.0 GB Ram<br />
 - 64-bit Windows 11 Home<br />
 - 2 TB SSD<br />
 - MySQL 8.0.41 (64 bit)]]></description>
            <dc:creator>Ken W</dc:creator>
            <category>Performance</category>
            <pubDate>Sat, 22 Feb 2025 03:45:01 +0000</pubDate>
        </item>
        <item>
            <guid>https://forums.mysql.com/read.php?24,739830,739830#msg-739830</guid>
            <title>SQL Performance with sysbench on different disks (no replies)</title>
            <link>https://forums.mysql.com/read.php?24,739830,739830#msg-739830</link>
            <description><![CDATA[ Hello everybody,<br />
<br />
I have some problem about performance with sysbench on my different OVH servers, here are my results :<br />
<br />
With this command : sysbench --test=fileio --file-test-mode=seqwr run<br />
<br />
RISE-2 server : ( Intel Xeon-E 2386G / 64Gb RAM DDR4 ECC )<br />
Two NVMe disks mounted in RAID 1 (SoftRAID) : SAMSUNG MZVL2512HCJQ-00B07 / 488.16Gb / Performance Write SQL : average 27 MiB/s &lt;========== BAD PERFORMANCE !!!<br />
<br />
RISE-S server : ( AMD Ryzen 7 9700K / 64Gb RAM DDR5 )<br />
Two NVMe disks mounted in RAID 1 (SoftRAID) : SAMSUNG MZVL2512HCJQ-00B07 / 488.16Gb / Performance Write SQL : average 34 MiB/s &lt;========== BAD PERFORMANCE !!!<br />
<br />
KS-5 server : ( Intel Xeon-E3 1270 v6 / 32Gb RAM DDR4 ECC )<br />
Two NVMe disks mounted in RAID 1 (SoftRAID) : INTEL SSDPE2MX450G7 / 429.04Gb / Performance Write SQL : average 542 MiB/s &lt;========== OK !!!<br />
<br />
SYS-LE-2 server : ( Intel Xeon-E 2274G / 64Gb RAM DDR4 ECC )<br />
Two NVMe disks mounted in RAID 1 (SoftRAID) : SAMSUNG MZQLB1T9HAJR-00007 / 1.78Tb / Performance Write SQL : Environ 886 MiB/s &lt;========== OK !!!<br />
<br />
It seems the disk SAMSUNG MZVL2512HCJQ-00B07 has poor performance about write.<br />
What do you think about these results??? Is it the disk fault?<br />
<br />
BUT if we use command : fio, all is fine with good performance.<br />
With this command : fio --name=rand-write --ioengine=libaio --iodepth=32 --rw=randwrite --invalidate=1 --bsrange=4k:4k,4k:4k --size=512m --runtime=120 --time_based --do_verify=1 --direct=1 --group_reporting --numjobs=1<br />
<br />
RISE-2 server : IOPS =213K / BW=830MiB/s (870MB/s).<br />
RISE-S server : IOPS=453k, BW=1771MiB/s (1857MB/s)(208GiB/120001msec)<br />
KS-5 server : IOPS=117k, BW=459MiB/s (481MB/s)(53.7GiB/120001msec)<br />
SYS-LE-2 server : IOPS=148k, BW=577MiB/s (605MB/s)(67.6GiB/120001msec)<br />
<br />
I don’t really know what’s happen. I’m not an expert about this.<br />
<br />
Regards,<br />
<br />
Christophe.]]></description>
            <dc:creator>Christophe CHEVALLIER</dc:creator>
            <category>Performance</category>
            <pubDate>Mon, 16 Dec 2024 22:47:22 +0000</pubDate>
        </item>
        <item>
            <guid>https://forums.mysql.com/read.php?24,739368,739368#msg-739368</guid>
            <title>Duplicate buckets in event_statements_histogram_by_digest (no replies)</title>
            <link>https://forums.mysql.com/read.php?24,739368,739368#msg-739368</link>
            <description><![CDATA[ Hi,<br />
I am hoping to use the event_statements_histogram_by_digest table to extract histogram data about my queries - so that I can calculate quantiles (above what is available in event_statements_summary). <br />
<br />
However when I look at the buckets, for a few digests there are actually 900 buckets. Two sets of 0-&gt;449. One set contains data, while the other has 0 for COUNT and COUNT_BUCKET_AND_LOWER.<br />
<br />
Furthermore, I get inconsistent results when querying the table. When I search for a specific schema_name AND digest AND bucket_number I get 1 row, however if I use a range on the bucket_number &gt;= x AND range &lt; x+1 I get 2 rows - one with data, the other 0 values.<br />
<br />
For example:<br />
<br />
mysql&gt; SELECT * FROM events_statements_histogram_by_digest WHERE SCHEMA_NAME = &#039;X&#039; AND DIGEST = &#039;Y&#039; AND BUCKET_NUMBER &gt;= 449 AND BUCKET_NUMBER &lt; 500;<br />
+------------------+------------------------------------------------------------------+---------------+------------------+----------------------+--------------+------------------------+-----------------+<br />
| SCHEMA_NAME      | DIGEST                                                           | BUCKET_NUMBER | BUCKET_TIMER_LOW | BUCKET_TIMER_HIGH    | COUNT_BUCKET | COUNT_BUCKET_AND_LOWER | BUCKET_QUANTILE |<br />
+------------------+------------------------------------------------------------------+---------------+------------------+----------------------+--------------+------------------------+-----------------+<br />
| X | Y |           449 | 9120108393559408 | 18446744073709551615 |            0 |               18930820 |        1.000000 |<br />
| X | Y |           449 | 9120108393559408 | 18446744073709551615 |            0 |                      0 |        0.000000 |<br />
+------------------+------------------------------------------------------------------+---------------+------------------+----------------------+--------------+------------------------+-----------------+<br />
2 rows in set (0.26 sec)<br />
<br />
mysql&gt; SELECT * FROM events_statements_histogram_by_digest WHERE SCHEMA_NAME = &#039;X&#039; AND DIGEST = &#039;Y&#039; AND BUCKET_NUMBER = 449;<br />
+------------------+------------------------------------------------------------------+---------------+------------------+----------------------+--------------+------------------------+-----------------+<br />
| SCHEMA_NAME      | DIGEST                                                           | BUCKET_NUMBER | BUCKET_TIMER_LOW | BUCKET_TIMER_HIGH    | COUNT_BUCKET | COUNT_BUCKET_AND_LOWER | BUCKET_QUANTILE |<br />
+------------------+------------------------------------------------------------------+---------------+------------------+----------------------+--------------+------------------------+-----------------+<br />
| X | Y |           449 | 9120108393559408 | 18446744073709551615 |            0 |               18930820 |        1.000000 |<br />
+------------------+------------------------------------------------------------------+---------------+------------------+----------------------+--------------+------------------------+-----------------+<br />
1 row in set (0.12 sec)<br />
<br />
<br />
Why is this? And how can I reliably query this table to collect all buckets for a given query.]]></description>
            <dc:creator>Matt Nolf</dc:creator>
            <category>Performance</category>
            <pubDate>Tue, 26 Nov 2024 18:19:26 +0000</pubDate>
        </item>
        <item>
            <guid>https://forums.mysql.com/read.php?24,730579,730579#msg-730579</guid>
            <title>MySQL:  New JSON format for EXPLAIN (no replies)</title>
            <link>https://forums.mysql.com/read.php?24,730579,730579#msg-730579</link>
            <description><![CDATA[ MySQL:  New JSON format for EXPLAIN<br />
- <a href="https://blogs.oracle.com/mysql/post/new-json-format-for-explain"  rel="nofollow">https://blogs.oracle.com/mysql/post/new-json-format-for-explain</a>]]></description>
            <dc:creator>Edwin Desouza</dc:creator>
            <category>Performance</category>
            <pubDate>Mon, 04 Nov 2024 16:22:41 +0000</pubDate>
        </item>
        <item>
            <guid>https://forums.mysql.com/read.php?24,728117,728117#msg-728117</guid>
            <title>Why do users report a performance decline in 8.0? (4 replies)</title>
            <link>https://forums.mysql.com/read.php?24,728117,728117#msg-728117</link>
            <description><![CDATA[ Many users claim that the performance of 8.0 has declined, but this is a misconception, often based on simple sysbench test results. Users should test our open-source version in real-world environments or use better tools like BenchmarkSQL TPCC to evaluate the optimized performance, ideally testing in a clustered environment.<br />
<br />
The feedback on performance decline mostly comes from tests on low-end machines. The reason for the performance decline in these environments is that the official version uses a new redo log mechanism, which employs a batch activation approach. This mechanism is more efficient in high-concurrency scenarios, but compared to the previous user thread self-activation mechanism, it offers no advantage in low-concurrency situations. Overall, in cases with low concurrency, the response speed has decreased, but overall efficiency has improved. However, this new mechanism greatly improves concurrent write capabilities, allowing 8.0 to outperform version 5.7 significantly in high-concurrency scenarios.]]></description>
            <dc:creator>Bin Wang</dc:creator>
            <category>Performance</category>
            <pubDate>Thu, 24 Oct 2024 00:44:41 +0000</pubDate>
        </item>
        <item>
            <guid>https://forums.mysql.com/read.php?24,727040,727040#msg-727040</guid>
            <title>Analyzing sql query performance issues (no replies)</title>
            <link>https://forums.mysql.com/read.php?24,727040,727040#msg-727040</link>
            <description><![CDATA[ Hello,<br />
 I have few questions in regards to query performance tuning. (Note- its version 8.0.32)<br />
<br />
1) I understand we use &quot;explain analyze&quot; to see the execution plan and it shows the exact resource consumption by running the query behind the scene. But still its quite difficult to understand the exact part of the query which is taking time or relating the exact line of the plan to exact predicate of the query. So is there any other option available through which we can see these information?<br />
<br />
2)And is there any option to mimic or force certain execution path of the query so that it always follows the same without deviating from that. As because we saw change in execution path for same query many times impact the query response time negatively.<br />
<br />
3) We want to track the historical query response time for any query , if there any data dictionary of catalog tables which which can be queried to see when the application query was running fast vs slow in past, and then further dig into it to fix it if needed (for example if its changing execution path in between on some days) ?]]></description>
            <dc:creator>Bapi P</dc:creator>
            <category>Performance</category>
            <pubDate>Sat, 12 Oct 2024 08:58:23 +0000</pubDate>
        </item>
        <item>
            <guid>https://forums.mysql.com/read.php?24,726697,726697#msg-726697</guid>
            <title>MySQL thread_stack vs memory usage (no replies)</title>
            <link>https://forums.mysql.com/read.php?24,726697,726697#msg-726697</link>
            <description><![CDATA[ Hey all, I run a MySQL8 DB on AWS RDS. Recently, I got a request to increase thread_stack by around 20%. While testing it on lower environments, I noticed that the DB memory usage decreased (freeable memory increased), and I was expecting the opposite.<br />
<br />
Does anyone know if this is expected or if I should consider different metrics to measure the impact of this change?<br />
<br />
Thank you.]]></description>
            <dc:creator>Andre Aguiar</dc:creator>
            <category>Performance</category>
            <pubDate>Fri, 04 Oct 2024 16:05:42 +0000</pubDate>
        </item>
        <item>
            <guid>https://forums.mysql.com/read.php?24,726063,726063#msg-726063</guid>
            <title>Flex MySQL 8.0  on AzUre (3 replies)</title>
            <link>https://forums.mysql.com/read.php?24,726063,726063#msg-726063</link>
            <description><![CDATA[ This is probably an Azure question but i can&#039;t get a sensible response from MS.<br />
<br />
Did anything change on Azure&#039;s memory management for MariaDB and MySQL in the last few months?<br />
<br />
I&#039;d been running 5 MariaDB servers on Azure for 2 years or so with no problems. Then about 2 months ago all 5 started reaching 100% memory and crashing. MS could only tell me it was &quot;workload&quot; and to increase (i.e. double) the vCores/memory.<br />
<br />
The workload hasn&#039;t changed in those 2 years but I did that and the servers ran ok. But at twice the expense. <br />
<br />
MariaDB is being retired on Azure anyway so i brought forward my migration to FLex MySQL servers. <br />
<br />
I&#039;m finding that these MySQL servers are also hitting 100% memory every few hours... but at least they don&#039;t crash; they just kick users out and reduce memory usage and carry on. Nevertheless i&#039;d like to keep this to a minimum.<br />
<br />
I believe the usual formulae for calculating memory usage is &quot;different&quot; in Azure; certain parameters in Azure (e.g. max_connections and max_allowed_packet) default to extremely high values that would normally be discouraged. I&#039;ve reduced them but no change in memory usage.<br />
<br />
Slow Queries isn&#039;t telling me anything interesting.<br />
<br />
There may be lots of smallish improvements to be made to some queries but the fact remains that this was perfectly stable for 2 years... then suddenly across 5 servers there&#039;s now a problem.<br />
<br />
Each server has about 80 - 100 customer databases of identical structure. About 110 tables and 30 views in each database. Triggers for insert, update and delete on about half the tables. Databases range is size from 50mb to 100GB. About 150 concurrent connections on each server at any one time.<br />
<br />
Comments please.]]></description>
            <dc:creator>Nigel Gomm</dc:creator>
            <category>Performance</category>
            <pubDate>Thu, 19 Sep 2024 15:02:32 +0000</pubDate>
        </item>
        <item>
            <guid>https://forums.mysql.com/read.php?24,725019,725019#msg-725019</guid>
            <title>Variable time execution for INSERT (no replies)</title>
            <link>https://forums.mysql.com/read.php?24,725019,725019#msg-725019</link>
            <description><![CDATA[ Hello,<br />
<br />
I do an INSERT in a table who has around 1 million rows in MySQL 8.0. I don&#039;t know why I have different execution times for the same data to insert.<br />
<br />
For example, I measure one time 281 milliseconds and an other time 1 second. There are no other queries running at the same time except mine.<br />
<br />
How is it possible ?<br />
<br />
UPDATE 1 : Additional informations<br />
Somes lines in my.ini :<br />
<br />
default-storage-engine=INNODB  <br />
sql-mode=&quot;STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION&quot;  <br />
slow-query-log=1 <br />
table_open_cache=2000  <br />
tmp_table_size=697M   <br />
thread_cache_size=10  <br />
key_buffer_size=8M   <br />
read_buffer_size=64K   <br />
read_rnd_buffer_size=256K   <br />
innodb_flush_log_at_trx_commit=1<br />
innodb_log_file_size=48M   <br />
innodb_thread_concurrency=9  <br />
OS : Microsoft Windows Server 2019 Standard (64 bits)<br />
RAM : 16 GB<br />
4 cores<br />
2 disks - 120 GB x2, don&#039;t know if it&#039;s NVME or SSD (it&#039;s not mine)<br />
<br />
SELECT COUNT(*) FROM information_schema.tables;<br />
Result : 203<br />
<br />
SHOW GLOBAL STATUS;<br />
Result : <a href="https://justpaste.it/e5ek0"  rel="nofollow">https://justpaste.it/e5ek0</a><br />
<br />
SHOW GLOBAL VARIABLES;<br />
Result : <a href="https://justpaste.it/fev9k"  rel="nofollow">https://justpaste.it/fev9k</a><br />
<br />
SHOW FULL PROCESSLIST;<br />
Result : <a href="https://justpaste.it/63gdx"  rel="nofollow">https://justpaste.it/63gdx</a><br />
<br />
SHOW ENGINE INNODB STATUS;<br />
Result : <a href="https://justpaste.it/fot5h"  rel="nofollow">https://justpaste.it/fot5h</a>]]></description>
            <dc:creator>Matt K</dc:creator>
            <category>Performance</category>
            <pubDate>Wed, 03 Jul 2024 15:20:42 +0000</pubDate>
        </item>
        <item>
            <guid>https://forums.mysql.com/read.php?24,724532,724532#msg-724532</guid>
            <title>inter-region data import speed issue (no replies)</title>
            <link>https://forums.mysql.com/read.php?24,724532,724532#msg-724532</link>
            <description><![CDATA[ Hi,<br />
<br />
A MySQL database dump is located on an AWS EC2 instance in the us-east-1 (N.Virginia) region (ec2-use1). The RDS instance is located in the ap-southeast-2 (Sydney) region (rds-apse2).<br />
<br />
I use the following command to import the data and it performs at a speed of about ~2.5MB/sec, with peaks up to 3:<br />
<pre class="bbcode">
[user@ec2-use1]$ pv user_service.dump | mysql --defaults-file=mysqlroot.cnf -h rds-apse2 -u sp user_service</pre>
<br />
However, if I launch an EC2 instance in the RDS region (ec2-apse2) and import the data through a pipe:<br />
<pre class="bbcode">
[user@ec2-use1]$ pv user_service.dump | ssh ec2-user@ec2-apse2 mysql --defaults-file=mysqlroot.cnf -h rds-apse2 -u sp user_service</pre>
<br />
the speed doubles (averaging 5.5MB/sec with peaks up to 10):<br />
<br />
If I import the data through an SSH tunnel:<br />
<pre class="bbcode">
[user@ec2-use1]$ ssh -L 3306:rds-apse2:3306 ec2-user@ec2-apse2
[user@ec2-use1]$ pv user_service.dump | mysql --defaults-file=mysqlroot.cnf -h localhost -u sp user_service</pre>
<br />
the speed is the same as without SSH.<br />
<br />
Any ideas why the speed increases when working through the SSH pipe (or why does the mysql tool alone perform slowly)?<br />
<br />
<br />
I also tried the following:<br />
<br />
1. Disabled Nagle algorithm (compiled a library with redefined <b>socket()</b> function) and loaded it with <b>LD_PRELOAD</b> - it didn&#039;t help:<br />
<pre class="bbcode">
# pv user_service.dump | LD_PRELOAD=/home/ec2-user/tcp_nodelay.so mysql --defaults-file=mysqlroot.cnf -h rds-apse2 -u sp user_service
^C.5MiB 0:00:23 [2.99MiB/s] [==============&gt;</pre>
<br />
2. Disabled SSH compression - it didn&#039;t change the speed at all:<br />
<pre class="bbcode">
# pv user_service.dump | ssh -o Compression=no ec2-user@ec2-apse2 mysql --defaults-file=mysqlroot.cnf -h rds-apse2 -u sp user_service
    390MiB 0:01:14 [5.20MiB/s]</pre>
<br />
3. Played with low and high values of <b>--net-buffer-length</b> mysql&#039;s cli parameter - nothing&#039;s changed<br />
<br />
4.. Increased <b>--max-allowed-packet</b> value of mysql&#039;s cli parameter to its maximum value - didn&#039;t help<br />
<br />
Regards,<br />
Alex]]></description>
            <dc:creator>Alex Kolesnik</dc:creator>
            <category>Performance</category>
            <pubDate>Tue, 28 May 2024 12:12:13 +0000</pubDate>
        </item>
        <item>
            <guid>https://forums.mysql.com/read.php?24,724399,724399#msg-724399</guid>
            <title>query is super slow until either i remove one particular JOIN or the ORDER BY (no replies)</title>
            <link>https://forums.mysql.com/read.php?24,724399,724399#msg-724399</link>
            <description><![CDATA[ Here&#039;s my query:<br />
<br />
SELECT *<br />
FROM calls ca<br />
JOIN conferences co ON ca.conference_id = co.id<br />
JOIN conference_participants p ON co.id = p.conference_id AND p.caller_id IN (&#039;group:40&#039;)<br />
WHERE ca.duration &gt;= 60<br />
ORDER BY ca.created_at DESC<br />
LIMIT 100;<br />
<br />
If I remove the &quot;JOIN conference_participants p&quot; bit or if I remove the &quot;ORDER BY&quot; bit the query is plenty fast but with both of those in there the query slows to crawl and I don&#039;t have a clue how to fix it.<br />
<br />
Here&#039;s the EXPLAIN:<br />
<br />
id: 1<br />
select_type: SIMPLE<br />
table: p<br />
partitions: NULL<br />
type: ref<br />
possible_keys: conference_participants_conference_id_index,conference_participants_caller_id_index,idx_conference_id_caller_id,conference_participants_caller_id_index2<br />
key: conference_participants_caller_id_index<br />
key_len: 130<br />
ref: const<br />
rows: 49600<br />
filtered: 100.00<br />
Extra: Using temporary; Using filesort<br />
<br />
id: 1<br />
select_type: SIMPLE<br />
table: ca<br />
partitions: NULL<br />
type: ref<br />
possible_keys: calls_conference_id_index,duration_queue,duration_user_created,idx_duration_created_at<br />
key: calls_conference_id_index<br />
key_len: 9<br />
ref: mediphone.p.conference_id<br />
rows: 1<br />
filtered: 50.00<br />
Extra: Using where<br />
<br />
id: 1<br />
select_type: SIMPLE<br />
table: co<br />
partitions: NULL<br />
type: eq_ref<br />
possible_keys: PRIMARY<br />
key: PRIMARY<br />
key_len: 8<br />
ref: mediphone.p.conference_id<br />
rows: 1<br />
filtered: 100.00<br />
Extra: NULL<br />
<br />
Here are the CREATE TABLES:<br />
<br />
CREATE TABLE `calls` (<br />
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,<br />
  `organization_id` int(10) unsigned NOT NULL,<br />
  `conference_id` bigint(20) unsigned DEFAULT NULL,<br />
  `user_id` bigint(20) unsigned DEFAULT NULL,<br />
  `sid` char(34) COLLATE utf8mb4_unicode_ci DEFAULT NULL,<br />
  `original_type` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL,<br />
  `type` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL,<br />
  `queue_name` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL,<br />
  `from` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL,<br />
  `to` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL,<br />
  `direction` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL,<br />
  `priority` int(10) unsigned DEFAULT NULL,<br />
  `age` int(10) unsigned DEFAULT NULL,<br />
  `duration` int(10) unsigned NOT NULL DEFAULT &#039;0&#039;,<br />
  `user_hold_duration` int(10) unsigned NOT NULL DEFAULT &#039;0&#039;,<br />
  `total_hold_duration` int(10) unsigned NOT NULL DEFAULT &#039;0&#039;,<br />
  `status` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL,<br />
  `reason` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL,<br />
  `created_at` timestamp NULL DEFAULT NULL,<br />
  `updated_at` timestamp NULL DEFAULT NULL,<br />
  `reverseCreated` int(11) DEFAULT NULL,<br />
  PRIMARY KEY (`id`),<br />
  UNIQUE KEY `calls_sid_unique` (`sid`),<br />
  KEY `calls_created_at_index` (`created_at`),<br />
  KEY `calls_organization_id_index` (`organization_id`),<br />
  KEY `calls_conference_id_index` (`conference_id`),<br />
  KEY `calls_user_id_index` (`user_id`),<br />
  KEY `calls_original_type_index` (`original_type`),<br />
  KEY `calls_type_index` (`type`),<br />
  KEY `calls_queue_name_index` (`queue_name`),<br />
  KEY `calls_from_index` (`from`),<br />
  KEY `calls_to_index` (`to`),<br />
  KEY `calls_direction_index` (`direction`),<br />
  KEY `calls_priority_index` (`priority`),<br />
  KEY `calls_status_index` (`status`),<br />
  KEY `calls_reason_index` (`reason`),<br />
  KEY `type` (`type`),<br />
  KEY `type_sid` (`type`,`sid`),<br />
  KEY `sid_type` (`sid`,`type`),<br />
  KEY `duration_queue` (`duration`,`queue_name`),<br />
  KEY `queue_duration` (`queue_name`,`duration`),<br />
  KEY `duration_user_created` (`duration`,`user_id`,`created_at`),<br />
  KEY `user_duration_created` (`user_id`,`duration`,`created_at`),<br />
  KEY `created_user_duration` (`created_at`,`user_id`,`duration`),<br />
  KEY `created_duration_user` (`created_at`,`duration`,`user_id`),<br />
  KEY `sid_user_duration_created` (`sid`,`user_id`,`duration`,`created_at`),<br />
  KEY `created_user` (`created_at`,`user_id`),<br />
  KEY `user_created` (`user_id`,`created_at`),<br />
  KEY `search_test` (`created_at`,`type`,`queue_name`),<br />
  KEY `search_test2` (`created_at`,`type`,`queue_name`,`from`),<br />
  KEY `search_test3` (`created_at`,`type`),<br />
  KEY `idx_duration_created_at` (`duration`,`created_at`),<br />
  KEY `reverseCreated` (`reverseCreated`),<br />
  CONSTRAINT `calls_conference_id_foreign` FOREIGN KEY (`conference_id`) REFERENCES `conferences` (`id`),<br />
  CONSTRAINT `calls_organization_id_foreign` FOREIGN KEY (`organization_id`) REFERENCES `organizations` (`id`),<br />
  CONSTRAINT `calls_user_id_foreign` FOREIGN KEY (`user_id`) REFERENCES `users` (`id`)<br />
) ENGINE=InnoDB AUTO_INCREMENT=2318098 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci<br />
<br />
CREATE TABLE `conferences` (<br />
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,<br />
  `organization_id` int(10) unsigned DEFAULT NULL,<br />
  `sid` char(34) COLLATE utf8mb4_unicode_ci DEFAULT NULL,<br />
  `name` char(34) COLLATE utf8mb4_unicode_ci NOT NULL,<br />
  `owner_user_id` bigint(20) unsigned DEFAULT NULL,<br />
  `duration` int(10) unsigned DEFAULT NULL,<br />
  `events` int(10) unsigned NOT NULL DEFAULT &#039;1&#039;,<br />
  `ending_participant_id` bigint(20) unsigned DEFAULT NULL,<br />
  `created_at` timestamp NULL DEFAULT NULL,<br />
  `updated_at` timestamp NULL DEFAULT NULL,<br />
  `deleted_at` timestamp NULL DEFAULT NULL,<br />
  PRIMARY KEY (`id`),<br />
  UNIQUE KEY `conferences_name_unique` (`name`),<br />
  UNIQUE KEY `conferences_sid_unique` (`sid`),<br />
  UNIQUE KEY `conferences_ending_participant_id_unique` (`ending_participant_id`),<br />
  KEY `conferences_organization_id_index` (`organization_id`),<br />
  KEY `conferences_owner_user_id_index` (`owner_user_id`),<br />
  CONSTRAINT `conferences_ending_participant_id_foreign` FOREIGN KEY (`ending_participant_id`) REFERENCES `conference_participants` (`id`),<br />
  CONSTRAINT `conferences_organization_id_foreign` FOREIGN KEY (`organization_id`) REFERENCES `organizations` (`id`),<br />
  CONSTRAINT `conferences_owner_user_id_foreign` FOREIGN KEY (`owner_user_id`) REFERENCES `users` (`id`)<br />
) ENGINE=InnoDB AUTO_INCREMENT=1861837 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci<br />
<br />
CREATE TABLE `conference_participants` (<br />
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,<br />
  `conference_id` bigint(20) unsigned NOT NULL,<br />
  `call_leg_id` bigint(20) unsigned DEFAULT NULL,<br />
  `user_id` bigint(20) unsigned DEFAULT NULL,<br />
  `sid` char(34) COLLATE utf8mb4_unicode_ci DEFAULT NULL,<br />
  `task_sid` char(34) COLLATE utf8mb4_unicode_ci DEFAULT NULL,<br />
  `caller_id` varchar(32) COLLATE utf8mb4_unicode_ci NOT NULL,<br />
  `has_joined_conference` tinyint(1) NOT NULL DEFAULT &#039;1&#039;,<br />
  `is_hidden` tinyint(1) NOT NULL DEFAULT &#039;0&#039;,<br />
  `is_muted` tinyint(1) NOT NULL DEFAULT &#039;0&#039;,<br />
  `is_on_hold` tinyint(1) NOT NULL DEFAULT &#039;0&#039;,<br />
  `created_at` timestamp NULL DEFAULT NULL,<br />
  `updated_at` timestamp NULL DEFAULT NULL,<br />
  `deleted_at` timestamp NULL DEFAULT NULL,<br />
  PRIMARY KEY (`id`),<br />
  UNIQUE KEY `conference_participants_call_leg_id_unique` (`call_leg_id`),<br />
  UNIQUE KEY `conference_participants_sid_unique` (`sid`),<br />
  KEY `conference_participants_conference_id_index` (`conference_id`),<br />
  KEY `conference_participants_user_id_index` (`user_id`),<br />
  KEY `conference_participants_caller_id_index` (`caller_id`),<br />
  KEY `conference_participants_has_joined_conference_index` (`has_joined_conference`),<br />
  KEY `conference_participants_is_hidden_index` (`is_hidden`),<br />
  KEY `conference_participants_is_muted_index` (`is_muted`),<br />
  KEY `conference_participants_is_on_hold_index` (`is_on_hold`),<br />
  KEY `conference_participants_task_sid_index` (`task_sid`),<br />
  KEY `idx_conference_id_caller_id` (`conference_id`,`caller_id`),<br />
  KEY `conference_participants_caller_id_index2` (`caller_id`,`conference_id`),<br />
  CONSTRAINT `conference_participants_call_leg_id_foreign` FOREIGN KEY (`call_leg_id`) REFERENCES `call_legs` (`id`),<br />
  CONSTRAINT `conference_participants_conference_id_foreign` FOREIGN KEY (`conference_id`) REFERENCES `conferences` (`id`),<br />
  CONSTRAINT `conference_participants_user_id_foreign` FOREIGN KEY (`user_id`) REFERENCES `users` (`id`)<br />
) ENGINE=InnoDB AUTO_INCREMENT=3969413 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci]]></description>
            <dc:creator>Thomas Anderson</dc:creator>
            <category>Performance</category>
            <pubDate>Tue, 21 May 2024 03:27:24 +0000</pubDate>
        </item>
        <item>
            <guid>https://forums.mysql.com/read.php?24,723597,723597#msg-723597</guid>
            <title>Incredibly slow count(*) on MariaDB / MySQL (1 reply)</title>
            <link>https://forums.mysql.com/read.php?24,723597,723597#msg-723597</link>
            <description><![CDATA[ Problem: <br />
SELECT COUNT(*) FORM contact_activity takes ~6 minutes<br />
Profiling the query shows 100% of the time is spent over &#039;sending data&#039; although it&#039;s only the count that is returned, no other data, no join, nothing. <br />
<br />
There are ~600M records in the table, roughly 3GB in size, including indices.<br />
It&#039;s well partitioned.<br />
It has relevant indices, and the EXPLAIN for SELECT COUNT(*) shows its users the index. <br />
Regular operations take reasonable time i.e. up to 2-3 minutes<br />
<br />
Additional info:<br />
MariaDB - version 10.11.7<br />
3 indices defined, none on text, all BTREE -<br />
Primary - int(11) + datetime, index size is ~30% of the table size<br />
Index-1, nullable, non unique - index int(11), size is ~15% of the table size<br />
Index-1, nullable, non unique - index int(11), size is ~15% of the table size<br />
Partition is monthly i.e. PARTITION BY RANGE COLUMNS(activity_datetime)<br />
<br />
<br />
What I&#039;ve tried <br />
- Isolation level was set REPEATABLE-READ (it was changed after the problem occurred hence this isn&#039;t the cause, but neither the solution)<br />
- Standalone server with SSD, 32GB RAM and 16 cores, solely serves the DB<br />
- SELECT COUNT(id) - doesn&#039;t change anything as the same index is used<br />
- FORCE INDEX usage - doesn&#039;t change anything <br />
- innodb_buffer_pool_size set to 50GB<br />
- innodb_buffer_pool_chunk_size set to 2GB<br />
- innodb_read_io_threads set to 8 (changed from default 4)<br />
- SHOW ENGINE INNODB STATUS - shows nothing special, deadlock rarely happens, and for sure isn&#039;t the cause<br />
<br />
5.5 seconds - when attempted sampling the same table over 20M records<br />
17.8 seconds - when attempted sampling on a copy table with 100M records and 2 columns only - id and active_datetime, indexed.<br />
<br />
The above simply doesn&#039;t make sense to me, I&#039;d appreciate any guidance on how to further dig into it / fix it. <br />
<br />
Cheers]]></description>
            <dc:creator>Michael Modan</dc:creator>
            <category>Performance</category>
            <pubDate>Thu, 04 Apr 2024 11:39:22 +0000</pubDate>
        </item>
        <item>
            <guid>https://forums.mysql.com/read.php?24,723525,723525#msg-723525</guid>
            <title>Re: MySQL 8.0 performance degradation compared to 5.6 (no replies)</title>
            <link>https://forums.mysql.com/read.php?24,723525,723525#msg-723525</link>
            <description><![CDATA[ We recently upgraded from MySQL 5.6 to MySQL 8.0.36. We&#039;ve noticed a significant drop in performance. A query that previously took 2 minutes to execute in MySQL 5.6 is now taking 5 minutes in MySQL 8.0.36. Somehow the MySQL optimiser is not choosing the correct index to retrieve the data efficiently. It&#039;s important to note that the &#039;entry_date&#039; column, which is used in the WHERE condition, does not have an index in either MySQL version<br />
<br />
EXAMPLE:1<br />
<br />
mysql5.6<br />
<br />
mysql&gt; select count(*) from test where entry_date BETWEEN &quot;2019-12-31&quot; AND &quot;2022-02-09&quot; group by account_id;<br />
+----------+<br />
| count(*) |<br />
+----------+<br />
|        6 |<br />
|        4 |<br />
|        5 |<br />
|        3 |<br />
|        1 |<br />
|        4 |<br />
|    87216 |<br />
|      407 |<br />
|     6484 |<br />
|     9383 |<br />
|       24 |<br />
|       12 |<br />
|        2 |<br />
|      261 |<br />
|      269 |<br />
|      121 |<br />
|       11 |<br />
|       35 |<br />
|        7 |<br />
|        1 |<br />
|       28 |<br />
|      180 |<br />
|      182 |<br />
|       68 |<br />
|        4 |<br />
|      214 |<br />
|       13 |<br />
|        6 |<br />
|     3897 |<br />
|     3895 |<br />
|        1 |<br />
|        7 |<br />
|        9 |<br />
|        2 |<br />
|        1 |<br />
|        1 |<br />
|        1 |<br />
|        5 |<br />
|    16969 |<br />
|     9981 |<br />
|    17363 |<br />
|       21 |<br />
|       11 |<br />
|        8 |<br />
|        5 |<br />
|        4 |<br />
|       10 |<br />
|        7 |<br />
|        5 |<br />
|        9 |<br />
|       27 |<br />
|        4 |<br />
|       65 |<br />
|       29 |<br />
|       28 |<br />
|        1 |<br />
|        1 |<br />
|       31 |<br />
|       29 |<br />
|        4 |<br />
|        1 |<br />
|        1 |<br />
|       28 |<br />
|       11 |<br />
|       29 |<br />
|        1 |<br />
|        2 |<br />
|        5 |<br />
|        2 |<br />
|        4 |<br />
|        1 |<br />
|        6 |<br />
|       18 |<br />
|        1 |<br />
|       23 |<br />
|        1 |<br />
|      167 |<br />
|       71 |<br />
|        2 |<br />
|       63 |<br />
|       93 |<br />
|        1 |<br />
|     4824 |<br />
|        6 |<br />
|        1 |<br />
|        5 |<br />
|        5 |<br />
|        5 |<br />
|        5 |<br />
|        5 |<br />
|        1 |<br />
|        4 |<br />
|      304 |<br />
|    17140 |<br />
|    10061 |<br />
|    17541 |<br />
|       12 |<br />
|        8 |<br />
|       13 |<br />
|       12 |<br />
|        8 |<br />
|       13 |<br />
|       26 |<br />
|     4907 |<br />
|    21219 |<br />
|    84580 |<br />
|   361932 |<br />
|  1127220 |<br />
|  5475308 |<br />
|      240 |<br />
|     3673 |<br />
|      240 |<br />
|      710 |<br />
|     3673 |<br />
|      710 |<br />
|        4 |<br />
|      309 |<br />
|      202 |<br />
|      894 |<br />
|     2647 |<br />
|       88 |<br />
|      376 |<br />
|     1415 |<br />
|   358596 |<br />
|  1111577 |<br />
|  5415590 |<br />
|       33 |<br />
|       35 |<br />
|       97 |<br />
|        1 |<br />
|       14 |<br />
|      864 |<br />
|        6 |<br />
|       31 |<br />
|        1 |<br />
|       29 |<br />
|        7 |<br />
|        1 |<br />
|        1 |<br />
|       95 |<br />
|       28 |<br />
|        1 |<br />
|        9 |<br />
|      101 |<br />
|        5 |<br />
|       31 |<br />
|      426 |<br />
|       41 |<br />
|      118 |<br />
|       11 |<br />
|        6 |<br />
|        6 |<br />
|        6 |<br />
|        4 |<br />
|        4 |<br />
|        4 |<br />
|       35 |<br />
|       51 |<br />
|        2 |<br />
|       48 |<br />
|      341 |<br />
|       55 |<br />
|       12 |<br />
|        6 |<br />
|      168 |<br />
|       33 |<br />
|        3 |<br />
|       18 |<br />
|       61 |<br />
|       55 |<br />
|       32 |<br />
|       17 |<br />
|       52 |<br />
|       36 |<br />
|        2 |<br />
|      178 |<br />
|        7 |<br />
|        2 |<br />
|       34 |<br />
|     3373 |<br />
|   135356 |<br />
|       92 |<br />
|       85 |<br />
|      187 |<br />
|       87 |<br />
|       87 |<br />
|   137661 |<br />
|       15 |<br />
|        3 |<br />
|       38 |<br />
|       44 |<br />
|        3 |<br />
|       12 |<br />
|     1708 |<br />
|        5 |<br />
|        4 |<br />
|      147 |<br />
|        9 |<br />
|       11 |<br />
|        2 |<br />
|       56 |<br />
|        8 |<br />
|       36 |<br />
|       77 |<br />
|        2 |<br />
|       98 |<br />
|     3290 |<br />
|     3207 |<br />
|        8 |<br />
|        4 |<br />
|      642 |<br />
|     1937 |<br />
|      279 |<br />
|       14 |<br />
|       34 |<br />
|       26 |<br />
|        1 |<br />
|        4 |<br />
|        4 |<br />
|       27 |<br />
|       43 |<br />
|       29 |<br />
|        1 |<br />
|        2 |<br />
|      158 |<br />
|        1 |<br />
|      235 |<br />
|      103 |<br />
|       54 |<br />
|      107 |<br />
|      138 |<br />
|       15 |<br />
|       27 |<br />
|       12 |<br />
|        9 |<br />
|        3 |<br />
|       17 |<br />
|       16 |<br />
|        4 |<br />
|      256 |<br />
|      116 |<br />
|       28 |<br />
|       24 |<br />
|       12 |<br />
|       19 |<br />
|       21 |<br />
|        6 |<br />
|        1 |<br />
|       29 |<br />
|       13 |<br />
|        7 |<br />
|       30 |<br />
|        1 |<br />
|       35 |<br />
|       13 |<br />
|        2 |<br />
|        1 |<br />
|       73 |<br />
|       71 |<br />
|        1 |<br />
|     1277 |<br />
|        1 |<br />
|      178 |<br />
|        1 |<br />
|     1245 |<br />
|     1274 |<br />
|       24 |<br />
|        5 |<br />
|        1 |<br />
|        5 |<br />
|       30 |<br />
|        4 |<br />
|        1 |<br />
|        1 |<br />
|        1 |<br />
|        6 |<br />
|        2 |<br />
|        2 |<br />
+----------+<br />
278 rows in set (2 min 10.97 sec)<br />
<br />
<br />
<br />
mysql8.0.36<br />
<br />
mysql&gt; select count(*) from test where entry_date BETWEEN &quot;2019-12-31&quot; AND &quot;2022-02-09&quot; group by account_id;<br />
+----------+<br />
| count(*) |<br />
+----------+<br />
|        6 |<br />
|        4 |<br />
|        5 |<br />
|        3 |<br />
|        1 |<br />
|        4 |<br />
|    87216 |<br />
|      407 |<br />
|     6484 |<br />
|     9383 |<br />
|       24 |<br />
|       12 |<br />
|        2 |<br />
|      261 |<br />
|      269 |<br />
|      121 |<br />
|       11 |<br />
|       35 |<br />
|        7 |<br />
|        1 |<br />
|       28 |<br />
|      180 |<br />
|      182 |<br />
|       68 |<br />
|        4 |<br />
|      214 |<br />
|       13 |<br />
|        6 |<br />
|     3897 |<br />
|     3895 |<br />
|        1 |<br />
|        7 |<br />
|        9 |<br />
|        2 |<br />
|        1 |<br />
|        1 |<br />
|        1 |<br />
|        5 |<br />
|    16969 |<br />
|     9981 |<br />
|    17363 |<br />
|       21 |<br />
|       11 |<br />
|        8 |<br />
|        5 |<br />
|        4 |<br />
|       10 |<br />
|        7 |<br />
|        5 |<br />
|        9 |<br />
|       27 |<br />
|        4 |<br />
|       65 |<br />
|       29 |<br />
|       28 |<br />
|        1 |<br />
|        1 |<br />
|       31 |<br />
|       29 |<br />
|        4 |<br />
|        1 |<br />
|        1 |<br />
|       28 |<br />
|       11 |<br />
|       29 |<br />
|        1 |<br />
|        2 |<br />
|        5 |<br />
|        2 |<br />
|        4 |<br />
|        1 |<br />
|        6 |<br />
|       18 |<br />
|        1 |<br />
|       23 |<br />
|        1 |<br />
|      167 |<br />
|       71 |<br />
|        2 |<br />
|       63 |<br />
|       93 |<br />
|        1 |<br />
|     4824 |<br />
|        6 |<br />
|        1 |<br />
|        5 |<br />
|        5 |<br />
|        5 |<br />
|        5 |<br />
|        5 |<br />
|        1 |<br />
|        4 |<br />
|      304 |<br />
|    17140 |<br />
|    10061 |<br />
|    17541 |<br />
|       12 |<br />
|        8 |<br />
|       13 |<br />
|       12 |<br />
|        8 |<br />
|       13 |<br />
|       26 |<br />
|     4907 |<br />
|    21219 |<br />
|    84580 |<br />
|   361932 |<br />
|  1127220 |<br />
|  5475308 |<br />
|      240 |<br />
|     3673 |<br />
|      240 |<br />
|      710 |<br />
|     3673 |<br />
|      710 |<br />
|        4 |<br />
|      309 |<br />
|      202 |<br />
|      894 |<br />
|     2647 |<br />
|       88 |<br />
|      376 |<br />
|     1415 |<br />
|   358596 |<br />
|  1111577 |<br />
|  5415590 |<br />
|       33 |<br />
|       35 |<br />
|       97 |<br />
|        1 |<br />
|       14 |<br />
|      864 |<br />
|        6 |<br />
|       31 |<br />
|        1 |<br />
|       29 |<br />
|        7 |<br />
|        1 |<br />
|        1 |<br />
|       95 |<br />
|       28 |<br />
|        1 |<br />
|        9 |<br />
|      101 |<br />
|        5 |<br />
|       31 |<br />
|      426 |<br />
|       41 |<br />
|      118 |<br />
|       11 |<br />
|        6 |<br />
|        6 |<br />
|        6 |<br />
|        4 |<br />
|        4 |<br />
|        4 |<br />
|       35 |<br />
|       51 |<br />
|        2 |<br />
|       48 |<br />
|      341 |<br />
|       55 |<br />
|       12 |<br />
|        6 |<br />
|      168 |<br />
|       33 |<br />
|        3 |<br />
|       18 |<br />
|       61 |<br />
|       55 |<br />
|       32 |<br />
|       17 |<br />
|       52 |<br />
|       36 |<br />
|        2 |<br />
|      178 |<br />
|        7 |<br />
|        2 |<br />
|       34 |<br />
|     3373 |<br />
|   135356 |<br />
|       92 |<br />
|       85 |<br />
|      187 |<br />
|       87 |<br />
|       87 |<br />
|   137661 |<br />
|       15 |<br />
|        3 |<br />
|       38 |<br />
|       44 |<br />
|        3 |<br />
|       12 |<br />
|     1708 |<br />
|        5 |<br />
|        4 |<br />
|      147 |<br />
|        9 |<br />
|       11 |<br />
|        2 |<br />
|       56 |<br />
|        8 |<br />
|       36 |<br />
|       77 |<br />
|        2 |<br />
|       98 |<br />
|     3290 |<br />
|     3207 |<br />
|        8 |<br />
|        4 |<br />
|      642 |<br />
|     1937 |<br />
|      279 |<br />
|       14 |<br />
|       34 |<br />
|       26 |<br />
|        1 |<br />
|        4 |<br />
|        4 |<br />
|       27 |<br />
|       43 |<br />
|       29 |<br />
|        1 |<br />
|        2 |<br />
|      158 |<br />
|        1 |<br />
|      235 |<br />
|      103 |<br />
|       54 |<br />
|      107 |<br />
|      138 |<br />
|       15 |<br />
|       27 |<br />
|       12 |<br />
|        9 |<br />
|        3 |<br />
|       17 |<br />
|       16 |<br />
|        4 |<br />
|      256 |<br />
|      116 |<br />
|       28 |<br />
|       24 |<br />
|       12 |<br />
|       19 |<br />
|       21 |<br />
|        6 |<br />
|        1 |<br />
|       29 |<br />
|       13 |<br />
|        7 |<br />
|       30 |<br />
|        1 |<br />
|       35 |<br />
|       13 |<br />
|        2 |<br />
|        1 |<br />
|       73 |<br />
|       71 |<br />
|        1 |<br />
|     1277 |<br />
|        1 |<br />
|      178 |<br />
|        1 |<br />
|     1245 |<br />
|     1274 |<br />
|       24 |<br />
|        5 |<br />
|        1 |<br />
|        5 |<br />
|       30 |<br />
|        4 |<br />
|        1 |<br />
|        1 |<br />
|        1 |<br />
|        6 |<br />
|        2 |<br />
|        2 |<br />
+----------+<br />
278 rows in set (5 min 11.80 sec)<br />
<br />
<br />
<br />
EXAMPLE:2 (8.0.36)<br />
<br />
<br />
+-----------+----+------------------+<br />
| a         | b  | c                |<br />
+-----------+----+------------------+<br />
| 10006203  | pi |       118.000000 |<br />
| 1001010   | `b |    108962.000000 |<br />
| 1001020   | `c |     55000.000000 |<br />
| 1001031   | `e |     58842.000000 |<br />
| 1001032   | `f |    212777.000000 |<br />
| 1001033   | `g |    113884.000000 |<br />
| 1001034   | `h |         0.000000 |<br />
| 1001035   | `i |     33663.100000 |<br />
| 100104001 | s` |    350000.000000 |<br />
| 1001051   | jd |    -39690.000000 |<br />
| 1001052   | je |    -20439.000000 |<br />
| 1001053   | jf |    -92505.000000 |<br />
| 1001054   | jg |    -25359.000000 |<br />
| 1001055   | jh |   -158234.000000 |<br />
| 1002010   | `j |         0.000000 |<br />
| 1002020   | `k |      1779.000000 |<br />
| 1003011   | `p |    617053.430000 |<br />
| 1003012   | `q |    -24445.880000 |<br />
| 1003013   | if |         0.000000 |<br />
| 1003014   | kd |         0.000000 |<br />
| 1003015   | li |         0.000000 |<br />
| 1003016   | on |    122393.000000 |<br />
| 1003017   | ox |      7045.920000 |<br />
| 1003018   | ph |    240644.000000 |<br />
| 1003019   | qh |   3355663.180000 |<br />
| 1003021   | `r |   7259670.000000 |<br />
| 1003022   | `s |   2081271.000000 |<br />
| 1003023   | lj |         0.000000 |<br />
| 1003024   | nt |   3000000.000000 |<br />
| 1003025   | ny |         0.000000 |<br />
| 1003026   | oo |   5000000.000000 |<br />
| 1003027   | ot |   1500000.000000 |<br />
| 1003028   | pb |         0.000000 |<br />
| 1003029   | pg |         0.000000 |<br />
| 1003030   | pl |         0.000000 |<br />
| 1003031   | qe |         0.000000 |<br />
| 1003032   | qf |         0.000000 |<br />
| 1003033   | qg |   4195039.000000 |<br />
| 1003034   | qm |         0.000000 |<br />
| 1004040   | `v |         0.000000 |<br />
| 1005021   | ae |     56461.570000 |<br />
| 1005022   | af |     51806.810000 |<br />
| 1005023   | ag |     16093.030000 |<br />
| 1005024   | h` |   5253629.550000 |<br />
| 1005025   | ha |  46676992.880000 |<br />
| 1005026   | hb | 113738866.400000 |<br />
| 1005031   | kn |   1288595.330000 |<br />
| 10050401  | ls |    251685.740000 |<br />
| 1006010   | ai |         0.000000 |<br />
| 1006021   | gm |     39968.490000 |<br />
| 1006022   | gn |     13303.350000 |<br />
| 1006023   | go |     39835.170000 |<br />
| 1006024   | hc |   1468944.940000 |<br />
| 1006025   | hd |   5246885.760000 |<br />
| 1006026   | he |  17952494.720000 |<br />
| 1006027   | ku |    365021.150000 |<br />
| 1006028   | lt |      8607.900000 |<br />
| 1006031   | gq |         0.000000 |<br />
| 1006032   | gr |         0.000000 |<br />
| 1006033   | gs |         0.000000 |<br />
| 1006034   | hf |         0.000000 |<br />
| 1006035   | hk |         0.000000 |<br />
| 1006036   | hg |         0.000000 |<br />
| 1006037   | kt |         0.000000 |<br />
| 1006041   | gu |         0.000000 |<br />
| 1006042   | gv |         0.000000 |<br />
| 1006043   | gw |         0.000000 |<br />
| 1006044   | hh |         0.000000 |<br />
| 1006045   | hi |         0.000000 |<br />
| 1006046   | hj |         0.000000 |<br />
| 1006047   | ks |         0.000000 |<br />
| 1006050   | ak |     70628.180000 |<br />
| 1006056   | ig |   2700000.000000 |<br />
| 1006060   | al |    851826.000000 |<br />
| 1006071   | aq |     13903.000000 |<br />
| 1006072   | ar |     13903.000000 |<br />
| 1006074   | j` |     12994.000000 |<br />
| 1006090   | ao |    237600.000000 |<br />
| 1006101   | kg |     16962.760000 |<br />
| 1006102   | nx |    169269.650000 |<br />
| 1006104   | qc |    254802.270000 |<br />
| 1006105   | qy |     55623.520000 |<br />
| 1006106   | r` |     29027.270000 |<br />
| 1006107   | rq |    424990.720000 |<br />
| 1006108   | rr |    171805.970000 |<br />
| 1006120   | jk |     30000.000000 |<br />
| 1006131   | ki |         0.000000 |<br />
| 1006132   | lp |     13500.000000 |<br />
| 1006141   | kk |     10011.000000 |<br />
| 1006142   | lq |    200000.000000 |<br />
| 1006143   | mg |     18000.000000 |<br />
| 10061501  | rb |     37006.400000 |<br />
| 10061502  | rs |     23126.400000 |<br />
| 10061503  | sv |     13211.000000 |<br />
| 1006201   | mi |         0.000000 |<br />
| 1006202   | ob |   1080618.680000 |<br />
| 2003031   | bx |         0.000000 |<br />
| 500505601 | rn |     57109.000000 |<br />
+-----------+----+------------------+<br />
98 rows in set, 1 warning (15 min 47.93 sec)<br />
<br />
mysql&gt; select version();<br />
+-------------------------+<br />
| version()               |<br />
+-------------------------+<br />
| 8.0.36-0ubuntu0.20.04.1 |<br />
<br />
<br />
<br />
<br />
+-----------+----+------------------+<br />
| a         | b  | c                |<br />
+-----------+----+------------------+<br />
| 10006203  | pi |       118.000000 |<br />
| 1001010   | `b |    108962.000000 |<br />
| 1001020   | `c |     55000.000000 |<br />
| 1001031   | `e |     58842.000000 |<br />
| 1001032   | `f |    212777.000000 |<br />
| 1001033   | `g |    113884.000000 |<br />
| 1001034   | `h |         0.000000 |<br />
| 1001035   | `i |     33663.100000 |<br />
| 100104001 | s` |    350000.000000 |<br />
| 1001051   | jd |    -39690.000000 |<br />
| 1001052   | je |    -20439.000000 |<br />
| 1001053   | jf |    -92505.000000 |<br />
| 1001054   | jg |    -25359.000000 |<br />
| 1001055   | jh |   -158234.000000 |<br />
| 1002010   | `j |         0.000000 |<br />
| 1002020   | `k |      1779.000000 |<br />
| 1003011   | `p |    617053.430000 |<br />
| 1003012   | `q |    -24445.880000 |<br />
| 1003013   | if |         0.000000 |<br />
| 1003014   | kd |         0.000000 |<br />
| 1003015   | li |         0.000000 |<br />
| 1003016   | on |    122393.000000 |<br />
| 1003017   | ox |      7045.920000 |<br />
| 1003018   | ph |    240644.000000 |<br />
| 1003019   | qh |   3355663.180000 |<br />
| 1003021   | `r |   7259670.000000 |<br />
| 1003022   | `s |   2081271.000000 |<br />
| 1003023   | lj |         0.000000 |<br />
| 1003024   | nt |   3000000.000000 |<br />
| 1003025   | ny |         0.000000 |<br />
| 1003026   | oo |   5000000.000000 |<br />
| 1003027   | ot |   1500000.000000 |<br />
| 1003028   | pb |         0.000000 |<br />
| 1003029   | pg |         0.000000 |<br />
| 1003030   | pl |         0.000000 |<br />
| 1003031   | qe |         0.000000 |<br />
| 1003032   | qf |         0.000000 |<br />
| 1003033   | qg |   4195039.000000 |<br />
| 1003034   | qm |         0.000000 |<br />
| 1004040   | `v |         0.000000 |<br />
| 1005021   | ae |     56461.570000 |<br />
| 1005022   | af |     51806.810000 |<br />
| 1005023   | ag |     16093.030000 |<br />
| 1005024   | h` |   5253629.550000 |<br />
| 1005025   | ha |  46676992.880000 |<br />
| 1005026   | hb | 113738866.400000 |<br />
| 1005031   | kn |   1288595.330000 |<br />
| 10050401  | ls |    251685.740000 |<br />
| 1006010   | ai |         0.000000 |<br />
| 1006021   | gm |     39968.490000 |<br />
| 1006022   | gn |     13303.350000 |<br />
| 1006023   | go |     39835.170000 |<br />
| 1006024   | hc |   1468944.940000 |<br />
| 1006025   | hd |   5246885.760000 |<br />
| 1006026   | he |  17952494.720000 |<br />
| 1006027   | ku |    365021.150000 |<br />
| 1006028   | lt |      8607.900000 |<br />
| 1006031   | gq |         0.000000 |<br />
| 1006032   | gr |         0.000000 |<br />
| 1006033   | gs |         0.000000 |<br />
| 1006034   | hf |         0.000000 |<br />
| 1006035   | hk |         0.000000 |<br />
| 1006036   | hg |         0.000000 |<br />
| 1006037   | kt |         0.000000 |<br />
| 1006041   | gu |         0.000000 |<br />
| 1006042   | gv |         0.000000 |<br />
| 1006043   | gw |         0.000000 |<br />
| 1006044   | hh |         0.000000 |<br />
| 1006045   | hi |         0.000000 |<br />
| 1006046   | hj |         0.000000 |<br />
| 1006047   | ks |         0.000000 |<br />
| 1006050   | ak |     70628.180000 |<br />
| 1006056   | ig |   2700000.000000 |<br />
| 1006060   | al |    851826.000000 |<br />
| 1006071   | aq |     13903.000000 |<br />
| 1006072   | ar |     13903.000000 |<br />
| 1006074   | j` |     12994.000000 |<br />
| 1006090   | ao |    237600.000000 |<br />
| 1006101   | kg |     16962.760000 |<br />
| 1006102   | nx |    169269.650000 |<br />
| 1006104   | qc |    254802.270000 |<br />
| 1006105   | qy |     55623.520000 |<br />
| 1006106   | r` |     29027.270000 |<br />
| 1006107   | rq |    424990.720000 |<br />
| 1006108   | rr |    171805.970000 |<br />
| 1006120   | jk |     30000.000000 |<br />
| 1006131   | ki |         0.000000 |<br />
| 1006132   | lp |     13500.000000 |<br />
| 1006141   | kk |     10011.000000 |<br />
| 1006142   | lq |    200000.000000 |<br />
| 1006143   | mg |     18000.000000 |<br />
| 10061501  | rb |     37006.400000 |<br />
| 10061502  | rs |     23126.400000 |<br />
| 10061503  | sv |     13211.000000 |<br />
| 1006201   | mi |         0.000000 |<br />
| 1006202   | ob |   1080618.680000 |<br />
| 2003031   | bx |         0.000000 |<br />
| 500505601 | rn |     57109.000000 |<br />
+-----------+----+------------------+<br />
98 rows in set, 1 warning (8 min 6.27 sec)<br />
<br />
mysql&gt; select version();<br />
+-----------+<br />
| version() |<br />
+-----------+<br />
| 5.6.48    |<br />
+-----------+<br />
1 row in set (0.00 sec)]]></description>
            <dc:creator>santhakumar g</dc:creator>
            <category>Performance</category>
            <pubDate>Fri, 29 Mar 2024 09:46:00 +0000</pubDate>
        </item>
        <item>
            <guid>https://forums.mysql.com/read.php?24,723079,723079#msg-723079</guid>
            <title>Mysql 5.7 -&gt;  8.0 migration (2 replies)</title>
            <link>https://forums.mysql.com/read.php?24,723079,723079#msg-723079</link>
            <description><![CDATA[ Hey there<br />
Recently we&#039;ve been working on migration from mysql 5.7 to mysql 8.0 and after migration we found that performance for some endpoints has been degradaded.<br />
<br />
For the context, we have a cluster with 1 writer and 1 read replica. Each customer has it&#039;s own database withing the database instance. And there&#039;s a separate database on the same instance that stores statistics for each customer. I understand that it might be not the optimal solution, just explain how things organized for better understanding.<br />
<br />
<br />
In these endpoints we&#039;re using SQL views that aggregates data from multiple tables and multiple databases and there&#039;s a table with statistic information that are updated via table swap (using rename operation).<br />
<br />
After some investigation we found that that in mysql8 has been introduced function called `update_referencing_views_metadata` which update meta information on views in case if referenced table is updated.<br />
So in our case we have around 300 databases that reference statistics table and when we rename the table it takes ~50 seconds because it has to update information for 300 views.<br />
In mysql 5.7 we didn&#039;t observe such behavior.<br />
<br />
So I wonder if someone can explain or might know what&#039;s the reason for that method so it has been introduced and is there any workarounds, may be there&#039;re some mysql settings that manages that.<br />
<br />
And another issue we&#039;ve been observing is that mysql start using not optimal indexes on views and query takes much more time that it was in mysql 5.7. So for example instead of complex index is start using pk which doesn&#039;t perform so well as the complex index and we had to tune queryes y adding hints.<br />
<br />
Thanks a lot]]></description>
            <dc:creator>Max Shkutnyk</dc:creator>
            <category>Performance</category>
            <pubDate>Fri, 01 Mar 2024 15:12:41 +0000</pubDate>
        </item>
        <item>
            <guid>https://forums.mysql.com/read.php?24,723008,723008#msg-723008</guid>
            <title>JSON insert performance (no replies)</title>
            <link>https://forums.mysql.com/read.php?24,723008,723008#msg-723008</link>
            <description><![CDATA[ Hi,<br />
<br />
We plan to store JSON documents in MySQL 8.0<br />
The documents are pretty simple: max 25 attributes, with short values.<br />
<br />
Are there any performance benchmarks? What is the maximum throughput that can be reached?<br />
<br />
Any recommendations for configuration / setup parameters<br />
<br />
Jaco Verheul]]></description>
            <dc:creator>Jaco Verheul</dc:creator>
            <category>Performance</category>
            <pubDate>Mon, 26 Feb 2024 10:26:15 +0000</pubDate>
        </item>
        <item>
            <guid>https://forums.mysql.com/read.php?24,719022,719022#msg-719022</guid>
            <title>100x to 200x InnoDB performance degradation MySQL 5.7 -&gt; 8.0.36 ? (3 replies)</title>
            <link>https://forums.mysql.com/read.php?24,719022,719022#msg-719022</link>
            <description><![CDATA[ Hi, I&#039;ve posted in the newbies forum, because I&#039;m completely new to MySQL 8.0 specifically (I have experience with MySQL 5.7) and have developed over 400 web apps and websites using MySQL over the course of 15 years.<br />
<br />
I&#039;ve recently migrated from an old server that had MySQL 5.7 and my new server came with MySQL 8.0.36, so this week I&#039;ve checked all the web apps for errors and performance changes and although everything &quot;works&quot;, it&#039;s unbelievably, excruciatingly slow.  I&#039;m talking 100 to 200 TIMES SLOWER (!!) than under MySQL 5.7.<br />
<br />
I&#039;ve isolated the issue to queries that select rows from InnoDB tables.  MyISAM is lightning fast (and faster than on the old server too).  So there seems to be some kind of bug in the MySQL 8.0 InnoDB engine that did not exist under MySQL 5.7.<br />
<br />
For example, I&#039;ve got an users table that contain 200K rows and for which there are lots of both READ and WRITE operations every second.  This table&#039;s engine is InnoDB because on the old server under MySQL 5.7 it had performance improvements over MyISAM.<br />
<br />
Now, under MYSQL 8.0, simply counting the rows with a couple WHERE statements takes 12 to 20 seconds! It&#039;s just a simple SELECT query with no join, no sub-query and yes, there are indexes on every column that are used in the WHERE statements.  That table size is only 100MB.<br />
<br />
If I go to phpMyAdmin and change its engine from InnoDB to MyISAM and run the same query, it&#039;s 0.1 second (yes, zero point one) so it&#039;s a factor of 120 to 200 times slower! I tried to leave the computer for an hour, came back and ran the same query and it&#039;s still consistently 0.1 second under MyISAM.  To me, there&#039;s something way, WAY off with InnoDB under MySQL 8.0 or perhaps there&#039;s some kind of configuration value that&#039;s missing in my.cnf? I kept most of it to default values that came with WHM 116.0.9<br />
<br />
Any help would be appreciated, otherwise I will have to abandon InnoDB and set every table of every web app on that server to MyISAM as it&#039;s the only solution I can see right now.]]></description>
            <dc:creator>Ben D.</dc:creator>
            <category>Performance</category>
            <pubDate>Tue, 03 Sep 2024 09:44:10 +0000</pubDate>
        </item>
        <item>
            <guid>https://forums.mysql.com/read.php?24,710665,710665#msg-710665</guid>
            <title>Hyphen in FULLTEXT (3 replies)</title>
            <link>https://forums.mysql.com/read.php?24,710665,710665#msg-710665</link>
            <description><![CDATA[ Table have 26 milj rows, 2,3GiB (simple key, value table). InnoDB.<br />
<br />
When i do query with hyphen, query is really slow (3sec). Every other query run smootly. What can I do to fix this?<br />
<br />
Examples:<br />
<br />
SELECT value FROM tablename  WHERE MATCH(value) AGAINST (&#039;&quot;978-951-1-47590-3&quot;&#039; IN BOOLEAN MODE) LIMIT 1;<br />
+-------------------+<br />
| value             |<br />
+-------------------+<br />
| 978-951-1-47590-3 |<br />
+-------------------+<br />
1 row in set (2.908 sec)<br />
<br />
SELECT value FROM tablename WHERE MATCH(value) AGAINST (&#039;&quot;9789511475903&quot;&#039; IN BOOLEAN MODE) LIMIT 1;<br />
+---------------+<br />
| value         |<br />
+---------------+<br />
| 9789511475903 |<br />
+---------------+<br />
1 row in set (0.025 sec)<br />
<br />
SELECT value FROM tablename WHERE MATCH(value) AGAINST (&#039;&quot;Parhaat neuvot sadan vuoden takaa.&quot;&#039; IN BOOLEAN MODE) LIMIT 1;<br />
+------------------------------------+<br />
| value                              |<br />
+------------------------------------+<br />
| Parhaat neuvot sadan vuoden takaa. |<br />
+------------------------------------+<br />
1 row in set (0.001 sec)]]></description>
            <dc:creator>Mikko L</dc:creator>
            <category>Performance</category>
            <pubDate>Mon, 20 Nov 2023 18:12:40 +0000</pubDate>
        </item>
        <item>
            <guid>https://forums.mysql.com/read.php?24,710659,710659#msg-710659</guid>
            <title>MySQL Telemetry Tracing with OCI APM (no replies)</title>
            <link>https://forums.mysql.com/read.php?24,710659,710659#msg-710659</link>
            <description><![CDATA[ MySQL Telemetry Tracing with OCI APM<br />
- <a href="https://blogs.oracle.com/mysql/post/mysql-telemetry-tracing-with-oci-apm"  rel="nofollow">https://blogs.oracle.com/mysql/post/mysql-telemetry-tracing-with-oci-apm</a>]]></description>
            <dc:creator>Edwin Desouza</dc:creator>
            <category>Performance</category>
            <pubDate>Wed, 15 Nov 2023 22:51:05 +0000</pubDate>
        </item>
        <item>
            <guid>https://forums.mysql.com/read.php?24,710218,710218#msg-710218</guid>
            <title>Queries in creating index (1 reply)</title>
            <link>https://forums.mysql.com/read.php?24,710218,710218#msg-710218</link>
            <description><![CDATA[ Hello Everyone,<br />
<br />
<br />
I have a doubt in creating index which is my sql query contains id, name, age columns in where clause , so i am trying to create index on this respective columns but my index is not at all using the sql query. so i added one column which is not using my sql query now its started using the index.<br />
<br />
may i know the reason behind that.]]></description>
            <dc:creator>Lekha Kumaravellu</dc:creator>
            <category>Performance</category>
            <pubDate>Wed, 25 Oct 2023 07:32:18 +0000</pubDate>
        </item>
        <item>
            <guid>https://forums.mysql.com/read.php?24,710174,710174#msg-710174</guid>
            <title>Performance issue in MYSQL 5.7 (no replies)</title>
            <link>https://forums.mysql.com/read.php?24,710174,710174#msg-710174</link>
            <description><![CDATA[ Hello Everyone,<br />
 <br />
I am facing performance issue in my query , My table contains 28278163 this many no.of rows.<br />
<br />
Problem:- My query is using one default index it self.<br />
<br />
I created proper index for my query, and my query is using the index which I created, but I didn&#039;t found any difference in my execution time.<br />
          <br />
          Before timings =1 minute.<br />
          After creating index timings = 1 minute<br />
<br />
After that I have dropped my Index, and the default index together. after I ran the explain plan the no.of rows scanned are very huge(4573864).I observed that execution time has been reduced to 30 secs , I am wondering how could it happens<br />
<br />
<br />
          Before timings =1 minute.<br />
          After creating index timings = 30 secs<br />
<br />
Here is the table schema<br />
<br />
<br />
CREATE TABLE `sales` (<br />
  `sales_report_id` bigint(22) NOT NULL AUTO_INCREMENT,<br />
  `report_date` date DEFAULT NULL,<br />
  `cust_id` int(11) DEFAULT NULL,<br />
  `client_number` varchar(255) DEFAULT NULL,<br />
  `customer` varchar(400) DEFAULT NULL,<br />
  `user_id` int(9) DEFAULT NULL,<br />
  `salesman` varchar(100) DEFAULT NULL,<br />
  `agent_code` varchar(75) DEFAULT NULL,<br />
  `index_id` int(9) DEFAULT NULL,<br />
  `index_code` varchar(25) DEFAULT NULL,<br />
  `index_label` varchar(200) DEFAULT NULL,<br />
  `family_id` int(9) DEFAULT NULL,<br />
  `family_code` varchar(25) DEFAULT NULL,<br />
  `family_label` varchar(200) DEFAULT NULL,<br />
  `niche_id` int(6) DEFAULT NULL,<br />
  `niche_code` varchar(10) DEFAULT NULL,<br />
  `niche_label` varchar(200) DEFAULT NULL,<br />
  `segment_id` int(6) DEFAULT NULL,<br />
  `segment_code` varchar(10) DEFAULT NULL,<br />
  `segment_label` varchar(200) DEFAULT NULL,<br />
  `master_id` int(9) DEFAULT NULL,<br />
  `master_code` varchar(50) DEFAULT NULL,<br />
  `master_label` varchar(255) DEFAULT NULL,<br />
  `client_category_code` varchar(255) DEFAULT NULL,<br />
  `client_category_name` varchar(200) DEFAULT NULL,<br />
  `channel_id` int(7) DEFAULT NULL,<br />
  `channel` varchar(200) DEFAULT NULL,<br />
  `gross_amount` decimal(19,4) DEFAULT NULL,<br />
  `net_amount` decimal(19,4) DEFAULT NULL,<br />
  `promotion_amount` int(7) DEFAULT NULL,<br />
  `quantity` int(11) DEFAULT NULL,<br />
  `business_unit_id` int(5) NOT NULL,<br />
  `business_unit_name` varchar(200) DEFAULT NULL,<br />
  `report_year` int(11) GENERATED ALWAYS AS (year(`report_date`)) STORED,<br />
  `report_month` tinyint(4) GENERATED ALWAYS AS (month(`report_date`)) STORED,<br />
  `report_month_name` varchar(20) GENERATED ALWAYS AS (monthname(`report_date`)) STORED,<br />
  `report_quarter` tinyint(4) GENERATED ALWAYS AS (quarter(`report_date`)) STORED,<br />
  `report_semester` tinyint(4) GENERATED ALWAYS AS ((case when (month(`report_date`) between 1 and 6) then 1 else 2 end)) STORED,<br />
  `report_annual` tinyint(4) GENERATED ALWAYS AS ((case when (month(`report_date`) between 1 and 12) then 1 else 0 end)) STORED,<br />
  PRIMARY KEY (`sales_report_id`,`business_unit_id`),<br />
  KEY `sales_report_mv_reprtdte_usrid` (`report_date`,`user_id`),<br />
  KEY `sales_report_mv_reprtdte_usrid_slsman` (`report_date`,`user_id`,`salesman`),<br />
  KEY `sales_report_mv_reprtdte_usrid_slsman_idxcde_idxlbl_cstomr` (`report_date`,`user_id`,`salesman`,`index_code`,`index_label`,`customer`),<br />
  KEY `sr_mv_bu_id_rep_dat_usr_id_cust_id` (`business_unit_id`,`report_date`,`user_id`,`cust_id`),<br />
  KEY `sr_mv_idx_buid_ccn_rptdte_usrid` (`business_unit_id`,`client_category_name`,`report_date`,`user_id`),<br />
  KEY `srmv_idx_buid_rptdte_mstrcde_usrid_qty` (`business_unit_id`,`report_date`,`master_code`,`user_id`,`quantity`),<br />
  KEY `srmv_idx_buid_rptdte_mstrcde_usrid_netamt` (`business_unit_id`,`report_date`,`master_code`,`user_id`,`net_amount`),<br />
  KEY `srmv_idx_buid_rptdte_mstrcde_usrid_grssamt` (`business_unit_id`,`report_date`,`master_code`,`user_id`,`gross_amount`),<br />
  KEY `sr_mv_cust_id` (`cust_id`),<br />
  KEY `sr_mv_buid_usrid_rptdte_idxid_custid` (`business_unit_id`,`user_id`,`report_date`,`index_id`,`cust_id`),<br />
  KEY `sr_mv_buid_chnnlid_mstrid_rptdte_prmtnamt` (`business_unit_id`,`channel_id`,`master_id`,`report_date`,`promotion_amount`),<br />
  KEY `sr_mv_buid_chnnlid_famid_rptdte_prmtnamton` (`business_unit_id`,`channel_id`,`family_id`,`report_date`,`promotion_amount`),<br />
  KEY `sr_mv_buid_chnnlid_idxid_rptdte_prmtnamt` (`business_unit_id`,`channel_id`,`index_id`,`report_date`,`promotion_amount`),<br />
  KEY `sr_mv_buid_usrid_rptdte_idxcde_chnlid_grsamt` (`business_unit_id`,`user_id`,`report_date`,`index_code`,`channel_id`,`gross_amount`),<br />
  KEY `sr_mv_buid_usrid_rptdte_idxcde_idxlbl_slsman_grsamt` (`business_unit_id`,`user_id`,`report_date`,`index_code`,`index_label`,`salesman`,`gross_amount`),<br />
  KEY `srmv_buid_rdte_uid_cnum_cstid_idxcd_fcde_mcd_rmnth_namt_gamt_qty` (`business_unit_id`,`report_date`,`user_id`,`client_number`,`cust_id`,`index_code`,`family_code`,`master_code`,`report_month`,`net_amount`,`gross_amount`,`quantity`),<br />
  KEY `srmv_cstid_rptyr_idxcde_fmcde_buid` (`cust_id`,`report_year`,`index_code`,`family_code`,`business_unit_id`,`gross_amount`,`net_amount`),<br />
  KEY `sr_mv_ctid_uid_rdt_mid_fmid_nid_segmtid_icd_fcd_mcd_Na_qt_gamt` (`cust_id`,`user_id`,`report_date`,`master_id`,`family_id`,`niche_id`,`segment_id`,`index_code`,`family_code`,`master_code`,`net_amount`,`quantity`,`gross_amount`),<br />
  KEY `srmv_custid_cnum_buid_rdte_usrid_idxcd_fcde_mcde_gamt_qty` (`cust_id`,`client_number`,`business_unit_id`,`report_date`,`user_id`,`index_code`,`family_code`,`master_code`,`gross_amount`,`quantity`),<br />
  KEY `srmv_cstid_buid_rtdt_mstrid_fmlid_nsid_sgmtid_idxd` (`cust_id`,`business_unit_id`,`report_date`,`master_id`,`family_id`,`niche_id`,`segment_id`,`index_id`,`quantity`,`gross_amount`),<br />
  KEY `SRMV_RPTDT_BUID_USID_CHNLID_MSTRID_NET_GRS_QTY` (`report_date`,`business_unit_id`,`user_id`,`channel_id`,`cust_id`,`master_id`,`net_amount`,`gross_amount`,`quantity`) USING BTREE,<br />
  KEY `SRMV_RPTDT_USRID_CUSTID_NET_GRS_QTY` (`report_date`,`user_id`,`cust_id`,`net_amount`,`gross_amount`,`quantity`) USING BTREE,<br />
  KEY `SRMV_CUSTID_RPTDT_NET_GRS_QTY` (`cust_id`,`report_date`,`net_amount`,`gross_amount`,`quantity`) USING BTREE,<br />
  KEY `srmv_rptdt_custid_net_grs_qty` (`report_date`,`cust_id`,`net_amount`,`gross_amount`,`quantity`) USING BTREE,<br />
  KEY `srmv_buid_usrid_custid_rptdte_grssamt` (`business_unit_id`,`user_id`,`cust_id`,`report_date`,`gross_amount`),<br />
  KEY `test_lekha2` (`business_unit_id`,`user_id`,`cust_id`,`report_date`,`index_code`,`index_label`,`report_year`,`report_month`,`gross_amount`) USING BTREE,<br />
  KEY `srmvv_usrid_fmid_rportdte_buid` (`user_id`,`family_id`,`report_date`,`business_unit_id`)<br />
) ENGINE=InnoDB AUTO_INCREMENT=28278163 DEFAULT CHARSET=utf8<br />
/*!50500 PARTITION BY LIST  COLUMNS(business_unit_id)<br />
(PARTITION sr_mv_p1 VALUES IN (1) ENGINE = InnoDB,<br />
 PARTITION sr_mv_p2 VALUES IN (2) ENGINE = InnoDB,<br />
 PARTITION sr_mv_p3 VALUES IN (3) ENGINE = InnoDB,<br />
 PARTITION sr_mv_p4 VALUES IN (4) ENGINE = InnoDB,<br />
 PARTITION sr_mv_p5 VALUES IN (5) ENGINE = InnoDB,<br />
 PARTITION sr_mv_p6 VALUES IN (6) ENGINE = InnoDB,<br />
 PARTITION sr_mv_p7 VALUES IN (7) ENGINE = InnoDB,<br />
 PARTITION sr_mv_p8 VALUES IN (8) ENGINE = InnoDB,<br />
 PARTITION sr_mv_p9 VALUES IN (9) ENGINE = InnoDB,<br />
 PARTITION sr_mv_p10 VALUES IN (10) ENGINE = InnoDB,<br />
 PARTITION sr_mv_p11 VALUES IN (11) ENGINE = InnoDB,<br />
 PARTITION sr_mv_p12 VALUES IN (12) ENGINE = InnoDB,<br />
 PARTITION sr_mv_p13 VALUES IN (13) ENGINE = InnoDB,<br />
 PARTITION sr_mv_p14 VALUES IN (14) ENGINE = InnoDB,<br />
 PARTITION sr_mv_p15 VALUES IN (15) ENGINE = InnoDB,<br />
 PARTITION sr_mv_p16 VALUES IN (16) ENGINE = InnoDB,<br />
 PARTITION sr_mv_p17 VALUES IN (17) ENGINE = InnoDB,<br />
 PARTITION sr_mv_p18 VALUES IN (18) ENGINE = InnoDB,<br />
 PARTITION sr_mv_p19 VALUES IN (19) ENGINE = InnoDB,<br />
 PARTITION sr_mv_p20 VALUES IN (20) ENGINE = InnoDB,<br />
 PARTITION sr_mv_p21 VALUES IN (21) ENGINE = InnoDB,<br />
 PARTITION sr_mv_p22 VALUES IN (22) ENGINE = InnoDB,<br />
 PARTITION sr_mv_p23 VALUES IN (23) ENGINE = InnoDB,<br />
 PARTITION sr_mv_p24 VALUES IN (24) ENGINE = InnoDB,<br />
 PARTITION sr_mv_p25 VALUES IN (25) ENGINE = InnoDB,<br />
 PARTITION sr_mv_p26 VALUES IN (26) ENGINE = InnoDB,<br />
 PARTITION sr_mv_p27 VALUES IN (27) ENGINE = InnoDB,<br />
 PARTITION sr_mv_p28 VALUES IN (28) ENGINE = InnoDB,<br />
 PARTITION sr_mv_p29 VALUES IN (29) ENGINE = InnoDB,<br />
 PARTITION sr_mv_p30 VALUES IN (30) ENGINE = InnoDB,<br />
 PARTITION sr_mv_p31 VALUES IN (31) ENGINE = InnoDB,<br />
 PARTITION sr_mv_p32 VALUES IN (32) ENGINE = InnoDB,<br />
 PARTITION sr_mv_p33 VALUES IN (33) ENGINE = InnoDB,<br />
 PARTITION sr_mv_p34 VALUES IN (34) ENGINE = InnoDB,<br />
 PARTITION sr_mv_p35 VALUES IN (35) ENGINE = InnoDB,<br />
 PARTITION sr_mv_p36 VALUES IN (36) ENGINE = InnoDB,<br />
 PARTITION sr_mv_p37 VALUES IN (37) ENGINE = InnoDB,<br />
 PARTITION sr_mv_p38 VALUES IN (38) ENGINE = InnoDB,<br />
 PARTITION sr_mv_p39 VALUES IN (39) ENGINE = InnoDB,<br />
 PARTITION sr_mv_p40 VALUES IN (40) ENGINE = InnoDB) */<br />
<br />
<br />
Here is my query <br />
<br />
SELECT  STRAIGHT_JOIN SQL_CALC_FOUND_ROWS<br />
			concat_ws(&#039;-&#039;,index_code,index_label) as partindexcode,<br />
			business_unit_name as bu_name,<br />
			&#039;&#039; AS mon, <br />
			&#039;&#039; as subtotal,<br />
			ROUND(SUM(CASE WHEN report_date between &#039;2022-01-01&#039; and &#039;2022-12-31&#039; THEN gross_amount ELSE 0 END),0) as salestotal,<br />
            <br />
            IFNULL(ROUND(((CASE WHEN MAX(YEAR(report_date)) = YEAR(&#039;2023-10-04&#039;) THEN (((SUM(CASE WHEN report_date between  &#039;2022-01-01&#039; AND &#039;2022-12-31&#039; THEN gross_amount ELSE 0 END) ) / (196)) * (259)) ELSE (SUM(CASE WHEN report_date between  &#039;2022-01-01&#039; AND &#039;2022-12-31&#039; THEN gross_amount ELSE 0 END)) END)/(SUM(CASE WHEN report_date between &#039;2021-01-01&#039; and &#039;2021-12-31&#039; THEN gross_amount ELSE 0 END))) * 100,0<br />
			), 0) as hist_vs_projection_perf,<br />
            <br />
            <br />
            <br />
			&#039;&#039; as histInd,<br />
			 &#039;&#039;  as weight_of_line_for_total,<br />
			&#039;&#039; as partindex_id,&#039;&#039; as bu_id , 0 as report_lvl,0 as is_start       <br />
			FROM<br />
				sales				<br />
			WHERE<br />
			business_unit_id IN (20,31,32) and<br />
				(report_date between &#039;2021-01-01&#039; and &#039;2022-12-31&#039;) and user_id in (368,370,371,376,385,388,389,486,493,524,369,380,381,382,383,384,386,387,417,530,544,598,372,373,374,375,377,378,379,488) having ((partindexcode != &quot;&quot;) and (partindexcode IS NOT NULL))  UNION ALL <br />
			( SELECT  STRAIGHT_JOIN <br />
			concat_ws(&#039;-&#039;,index_code,index_label) as partindexcode,<br />
			business_unit_name as bu_name,<br />
			MONTHNAME(report_date) AS mon, <br />
			&#039;&#039; as subtotal,<br />
			ROUND(SUM(CASE WHEN report_date between &#039;2022-01-01&#039; and &#039;2022-12-31&#039; THEN gross_amount ELSE 0 END)) AS salestotal,<br />
			IFNULL(ROUND(((CASE WHEN MONTH(report_date) = MONTH(&#039;2023-10-04&#039;) and MAX(YEAR(report_date)) = YEAR(&#039;2023-10-04&#039;) THEN (((SUM(CASE WHEN report_date between  &#039;2022-01-01&#039; AND &#039;2022-12-31&#039; THEN gross_amount ELSE 0 END) ) / (2)) * (22)) ELSE (SUM(CASE WHEN report_date between  &#039;2022-01-01&#039; AND &#039;2022-12-31&#039; THEN gross_amount ELSE 0 END)) END)/(SUM(CASE WHEN report_date between &#039;2021-01-01&#039; and &#039;2021-12-31&#039; THEN gross_amount ELSE 0 END))) * 100,0<br />
			),0) as hist_vs_projection_perf,<br />
			&#039;&#039; as histInd,<br />
			&#039;&#039; as weight_of_line_for_total,&#039;&#039; as partindex_id,&#039;&#039; as bu_id ,  0 as report_lvl,0 as is_start <br />
			FROM <br />
				sales<br />
			WHERE<br />
			business_unit_id IN (20,31,32) and<br />
			(report_date between &#039;2021-01-01&#039; and &#039;2022-12-31&#039; and user_id in (368,370,371,376,385,388,389,486,493,524,369,380,381,382,383,384,386,387,417,530,544,598,372,373,374,375,377,378,379,488)) GROUP BY MONTH(report_date)  )  UNION ALL ( SELECT  STRAIGHT_JOIN <br />
		concat_ws(&#039;-&#039;,index_code,index_label) as partindexcode,<br />
		business_unit_name as bu_name, &#039;&#039; as mon , <br />
		&#039;&#039; as subtotal,<br />
		ROUND(SUM(CASE WHEN report_date between &#039;2022-01-01&#039; and &#039;2022-12-31&#039; THEN gross_amount ELSE 0 END)) AS salestotal,IFNULL(ROUND(((CASE WHEN MAX(YEAR(report_date)) = YEAR(&#039;2023-10-04&#039;) THEN (((SUM(CASE WHEN report_date between  &#039;2022-01-01&#039; AND &#039;2022-12-31&#039; THEN gross_amount ELSE 0 END) ) / (196)) * (259)) ELSE (SUM(CASE WHEN report_date between  &#039;2022-01-01&#039; AND &#039;2022-12-31&#039; THEN gross_amount ELSE 0 END)) END)/(SUM(CASE WHEN report_date between &#039;2021-01-01&#039; and &#039;2021-12-31&#039; THEN gross_amount ELSE 0 END))) * 100,0<br />
		),0) as hist_vs_projection_perf,&#039;&#039; as histInd,<br />
		&#039;&#039;  as weight_of_line_for_total,<br />
		index_id as partindex_id,<br />
		business_unit_id as bu_id ,<br />
		0 as report_lvl,<br />
		0 as is_start <br />
		FROM <br />
			sales<br />
		WHERE<br />
		business_unit_id IN (20,31,32) and<br />
		(report_date between &#039;2021-01-01&#039; and &#039;2022-12-31&#039;) and user_id in (368,370,371,376,385,388,389,486,493,524,369,380,381,382,383,384,386,387,417,530,544,598,372,373,374,375,377,378,379,488)<br />
		   GROUP BY index_code ) LIMIT 0, 50<br />
<br />
<br />
Here is the index which i created<br />
<br />
create index `test_lekha2` on sales_report_mv (`business_unit_id`,`user_id`,cust_id,`report_date`,`index_code`,index_label,`report_year`,`report_month`,`gross_amount`) USING BTREE; --]]></description>
            <dc:creator>Lekha Kumaravellu</dc:creator>
            <category>Performance</category>
            <pubDate>Fri, 13 Oct 2023 09:22:15 +0000</pubDate>
        </item>
        <item>
            <guid>https://forums.mysql.com/read.php?24,709888,709888#msg-709888</guid>
            <title>Query not properly using indices (no replies)</title>
            <link>https://forums.mysql.com/read.php?24,709888,709888#msg-709888</link>
            <description><![CDATA[ Hello everyone,<br />
<br />
I&#039;m currently facing some challenges on column indexation and I would love to get some help. I have trimmed down the problem a lot to illustrate the issue better and it goes like this:<br />
<br />
I have a query which has to retrieve all the rows from a table based on some foreign key ids from another table (foreign keys being filtered by one condition). This is the query:<br />
<br />
SELECT *<br />
FROM monitor<br />
WHERE<br />
    zone_id IN (SELECT id FROM zone WHERE main = TRUE);<br />
<br />
This query does not use the index for the column zone_id and it takes a very long time, whereas if I do this other query:<br />
<br />
SELECT *<br />
FROM monitor<br />
WHERE<br />
    zone_id IN (&#039;1&#039;,&#039;2&#039;,&#039;3&#039;,&#039;4&#039;,&#039;5&#039;,&#039;6&#039;,&#039;9&#039;);<br />
<br />
It indexes the column properly and it&#039;s basically instant.<br />
<br />
The array used is the result of the former subquery.<br />
I have removed a lot more stuff from the query to make my point simpler, but tried this simpler scenario and got the same results.<br />
Why is this happening and is there any way I can dynamically select the filter array?<br />
<br />
Thanks a lot in advance!<br />
Thanks in]]></description>
            <dc:creator>Manuel Diez Silva</dc:creator>
            <category>Performance</category>
            <pubDate>Thu, 31 Aug 2023 12:10:09 +0000</pubDate>
        </item>
        <item>
            <guid>https://forums.mysql.com/read.php?24,709853,709853#msg-709853</guid>
            <title>Slow query in a view, how to improve it (similar to putting indexes?) (no replies)</title>
            <link>https://forums.mysql.com/read.php?24,709853,709853#msg-709853</link>
            <description><![CDATA[ Hi everyone!<br />
<br />
I made quite a complex View on my MySQL database, and I realized that some queries are slow. My first idea was to add indexes but it&#039;s not possible to do on a view so I&#039;m lost on how to improve the performance of my query.<br />
<br />
I&#039;ll share here my View query, and I&#039;ll do my best to explain it, then I&#039;ll share my database structure (stripped down to what is needed only for the view).<br />
<br />
<pre class="bbcode">
CREATE VIEW conversations_search AS (
    SELECT a.id, a.organization_id, a.status, a.way, a.agent_id, a.subject, a.snooze_until, a.channel_id, a.source, a.contact_id, a.name, a.email, a.created, a.message, a.category, a.is_personal, a.is_customer, a.last_update,
        CONCAT(DATE_FORMAT(a.last_update, &#039;%Y%m%d&#039;), a.is_customer, DATE_FORMAT(a.last_update, &#039;%H%i%S&#039;), RIGHT(LPAD(a.id, 6, &#039;0&#039;), 6)) AS priority_sort,
        CONCAT(DATE_FORMAT(a.last_update, &#039;%Y%m%d%H%i%S&#039;), RIGHT(LPAD(a.id, 6, &#039;0&#039;), 6)) AS date_sort,
        CONCAT(RIGHT(LPAD(CAST((UTC_TIMESTAMP() - a.last_update) AS UNSIGNED) * 100, 12, &#039;0&#039;), 12), RIGHT(LPAD(a.id, 6, &#039;0&#039;), 6)) AS longest_sort
    FROM (
        SELECT c.id, c.organization_id, c.status, e.way, c.agent_id, c.subject AS subject, c.snooze_until, c.channel_id, c.source, c.contact_id, cn.name, cn.email, e.created, e.message, e.category, c.is_personal,
            IF(pc.customer_id IS NULL, 0, 1) AS is_customer,
            (
                IFNULL(
                    (SELECT created FROM messages WHERE conversation_id = c.id AND way = &#039;IN&#039; ORDER BY created DESC LIMIT 1),
                    IFNULL(
                        (SELECT created FROM messages WHERE conversation_id = c.id AND way = &#039;OUT&#039; ORDER BY created DESC LIMIT 1),
                        (SELECT created FROM message_drafts WHERE conversation_id = c.id)
                    )
                )
            ) AS last_update
        FROM (
            SELECT m.way, m.created, m.message, m.conversation_id, &#039;MESSAGE&#039; AS category FROM messages m WHERE `status` != &#039;DRAFT&#039;
            UNION
            SELECT NULL AS way, n.created AS created, n.message, n.conversation_id, &#039;NOTE&#039; AS category FROM conversation_notes n WHERE `status` != &#039;DRAFT&#039;
        ) AS e LEFT JOIN conversations c ON c.id = e.conversation_id LEFT JOIN contacts cn ON cn.id = c.contact_id
            LEFT JOIN processor_customers pc ON pc.contact_id = c.contact_id
    ) AS a
);</pre>
<br />
<br />
<b>Explaination</b>: This view loads a few columns related to a tickets, including:<br />
<br />
<ul>* the ticket id <br /> * the organization_id to which the ticket is affected <br /> * The status (closed, opened, etc) <br /> * the way the last message was sent (received or sent) <br /> * The assigned agent id <br /> * The subject <br /> * The snooze time (if any) <br /> * the channel id (like support@xxx.com) <br /> * The contact id (From email) <br /> * The contact&#039;s name <br /> * The contact&#039;s email <br /> * The ticket&#039;s creation date <br /> * the last message content <br /> * the category (if the last entry ss a message or a note) <br /> * If the received message is personal (the channel where the email was sent is personal, like <a href="mailto:&#121;&#111;&#117;&#64;&#101;&#109;&#97;&#105;&#108;&#46;&#99;&#111;&#109;">&#121;&#111;&#117;&#64;&#101;&#109;&#97;&#105;&#108;&#46;&#99;&#111;&#109;</a>, or open to anyone in the team, like support@..) <br /> * If the contact is a customer <br /> * The last time the ticket was updated <br /> * A column that is used to sort by priority <br /> * A column to sort by date <br /> * A column to sort by waiting longer</ul>
<br />
I&#039;m definitely not a DB expert, so maybe there a ton of improvements available already on that query, but what I realized is that in production, a simple query like :<br />
<br />
&gt; SELECT COUNT(id) FROM conversations_search WHERE organization_id = X;<br />
Takes about 2.5 seconds to run. I tried with a few different IDs, and the result is between 900 and 18000, but still takes around 2.5 seconds.<br />
<br />
Clearly, its missing some optimisations...<br />
<br />
Here&#039;s my DB structure (I removed some useless columns for the sake of simplicity here):<br />
<br />
<pre class="bbcode">
CREATE TABLE `contacts` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `name` varchar(250) DEFAULT NULL,
  `email` varchar(250) NOT NULL,
  `created` datetime NOT NULL,
  `organization_id` int(11) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `email` (`email`,`organization_id`),
  KEY `organization_id` (`organization_id`),
  CONSTRAINT `contacts_ibfk_2` FOREIGN KEY (`organization_id`) REFERENCES `organizations` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=11181 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

CREATE TABLE `conversations` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `subject` varchar(250) DEFAULT NULL,
  `status` varchar(15) NOT NULL,
  `source` varchar(15) NOT NULL,
  `created` datetime(6) NOT NULL,
  `snooze_until` datetime DEFAULT NULL,
  `channel_id` bigint(20) unsigned DEFAULT NULL,
  `organization_id` int(11) NOT NULL,
  `contact_id` bigint(20) unsigned NOT NULL,
  `agent_id` bigint(20) unsigned DEFAULT NULL,
  `is_personal` tinyint(1) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `agent_id` (`agent_id`),
  KEY `channel_id` (`channel_id`),
  KEY `contact_id` (`contact_id`),
  KEY `organization_id` (`organization_id`),
  CONSTRAINT `conversations_ibfk_1` FOREIGN KEY (`agent_id`) REFERENCES `agents` (`id`),
  CONSTRAINT `conversations_ibfk_2` FOREIGN KEY (`channel_id`) REFERENCES `channels` (`id`),
  CONSTRAINT `conversations_ibfk_3` FOREIGN KEY (`contact_id`) REFERENCES `contacts` (`id`),
  CONSTRAINT `conversations_ibfk_4` FOREIGN KEY (`organization_id`) REFERENCES `organizations` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=17502 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

CREATE TABLE `messages` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `message` mediumtext DEFAULT NULL,
  `way` varchar(3) NOT NULL,
  `created` datetime(6) NOT NULL,
  `last_update` datetime NOT NULL,
  `status` varchar(20) NOT NULL,
  `conversation_id` bigint(20) unsigned NOT NULL,
  `contact_id` bigint(20) unsigned DEFAULT NULL,
  `agent_id` bigint(20) unsigned DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `agent_id` (`agent_id`),
  KEY `contact_id` (`contact_id`),
  KEY `conversation_id` (`conversation_id`),
  CONSTRAINT `messages_ibfk_1` FOREIGN KEY (`agent_id`) REFERENCES `agents` (`id`),
  CONSTRAINT `messages_ibfk_2` FOREIGN KEY (`contact_id`) REFERENCES `contacts` (`id`),
  CONSTRAINT `messages_ibfk_3` FOREIGN KEY (`conversation_id`) REFERENCES `conversations` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=27845 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

CREATE TABLE `conversation_notes` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `agent_id` bigint(20) unsigned DEFAULT NULL,
  `message` mediumtext DEFAULT NULL,
  `status` varchar(20) NOT NULL,
  `created` datetime(6) NOT NULL,
  `conversation_id` bigint(20) unsigned NOT NULL,
  PRIMARY KEY (`id`),
  KEY `agent_id` (`agent_id`),
  KEY `conversation_id` (`conversation_id`),
  CONSTRAINT `conversation_notes_ibfk_1` FOREIGN KEY (`agent_id`) REFERENCES `agents` (`id`),
  CONSTRAINT `conversation_notes_ibfk_2` FOREIGN KEY (`conversation_id`) REFERENCES `conversations` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1452 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

CREATE TABLE `message_drafts` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `content` mediumtext DEFAULT NULL,
  `created` datetime(6) NOT NULL,
  `last_updated` datetime NOT NULL,
  `conversation_id` bigint(20) unsigned NOT NULL,
  `agent_id` bigint(20) unsigned NOT NULL,
  PRIMARY KEY (`id`),
  KEY `agent_id` (`agent_id`),
  KEY `conversation_id` (`conversation_id`),
  CONSTRAINT `message_drafts_ibfk_1` FOREIGN KEY (`agent_id`) REFERENCES `agents` (`id`),
  CONSTRAINT `message_drafts_ibfk_2` FOREIGN KEY (`conversation_id`) REFERENCES `conversations` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=653 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

CREATE TABLE `agents` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `name` varchar(250) DEFAULT NULL,
  `email` varchar(250) NOT NULL,
  `organization_id` int(11) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `ix_agents_email` (`email`),
  UNIQUE KEY `email` (`email`,`organization_id`),
  KEY `organization_id` (`organization_id`),
  CONSTRAINT `agents_ibfk_1` FOREIGN KEY (`organization_id`) REFERENCES `organizations` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=679 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

CREATE TABLE `organizations` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(250) NOT NULL,
  `slug` varchar(250) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `ix_organizations_slug` (`slug`),
) ENGINE=InnoDB AUTO_INCREMENT=647 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;</pre>
<br />
How can I improve the query above?<br />
(The view contains these values because I can search by contact name or email, by status, by agent, by way (in/out), by channel, etc. All the columns can be used when searching.<br />
<br />
Thank you for your help!]]></description>
            <dc:creator>Cyril N.</dc:creator>
            <category>Performance</category>
            <pubDate>Mon, 28 Aug 2023 12:33:17 +0000</pubDate>
        </item>
        <item>
            <guid>https://forums.mysql.com/read.php?24,709435,709435#msg-709435</guid>
            <title>Timeout of Simple Query - Makes no sense (no replies)</title>
            <link>https://forums.mysql.com/read.php?24,709435,709435#msg-709435</link>
            <description><![CDATA[ We have a system that builds dynamic SQL based on selections made by the front-end. It works great (overall), but there appears to be an issue with what should be a simple query that times out.<br />
<br />
Here we go:<br />
<br />
-- This takes 20ms, 4800 records<br />
SELECT phw.person_main_ref_id AS ID<br />
FROM person_history_work phw<br />
WHERE MATCH(phw.work_summary) AGAINST(&#039;finance&#039;);<br />
<br />
-- This takes 20ms, 24000 records<br />
SELECT phw.person_main_ref_id AS ID<br />
FROM person_history_work phw<br />
WHERE MATCH(phw.work_title) AGAINST(&#039;software&#039;);<br />
<br />
-- This takes 700ms, returns 14000 records<br />
SELECT pm.ID<br />
FROM person_main pm      <br />
WHERE<br />
pm.ID IN  <br />
(<br />
    SELECT phw.person_main_ref_id AS ID<br />
    FROM person_history_work phw<br />
    WHERE phw.ID &lt; 50000<br />
)<br />
AND<br />
pm.ID IN<br />
(<br />
    SELECT phw.person_main_ref_id AS ID<br />
    FROM person_history_work phw<br />
    WHERE phw.ID &gt; 10000<br />
);<br />
<br />
-- This times out at over 60000ms, should return at max 4800 records<br />
SELECT pm.ID<br />
FROM person_main pm      <br />
WHERE<br />
pm.ID IN  <br />
(<br />
    SELECT phw.person_main_ref_id AS ID<br />
    FROM person_history_work phw<br />
    WHERE MATCH(phw.work_summary) AGAINST(&#039;finance&#039;)<br />
)<br />
AND<br />
pm.ID IN<br />
(<br />
    SELECT phw.person_main_ref_id AS ID<br />
    FROM person_history_work phw<br />
    WHERE MATCH(phw.work_title) AGAINST(&#039;software&#039;)<br />
);<br />
<br />
I&#039;m scratching my head on this one.The above AND compares only compare 4800 vs 2400 ID entries and independently they take less than 50ms each to execute. But put into the main query, it&#039;s more than 60000ms. It times out. Note this happens locally and on AWS.<br />
<br />
It&#039;s obviously not an issue with the ID counts being compared, because:<br />
<br />
-- This takes 24ms, returns 13183 records<br />
SELECT pm.ID<br />
FROM person_main pm      <br />
WHERE<br />
pm.ID IN  <br />
(<br />
    -- 49838 records<br />
    SELECT phw.person_main_ref_id AS ID<br />
    FROM person_history_work phw<br />
    WHERE phw.ID &lt; 50000<br />
)<br />
AND<br />
pm.ID IN<br />
(<br />
    -- 299679 records<br />
    SELECT phw.person_main_ref_id AS ID<br />
    FROM person_history_work phw<br />
    WHERE phw.ID &gt; 10000<br />
);<br />
<br />
So any idea what&#039;s going on here? Seems like it could be a bug or some serious issue with the engine optimization.]]></description>
            <dc:creator>David Allen</dc:creator>
            <category>Performance</category>
            <pubDate>Thu, 06 Jul 2023 16:05:27 +0000</pubDate>
        </item>
        <item>
            <guid>https://forums.mysql.com/read.php?24,709090,709090#msg-709090</guid>
            <title>TIME_WAIT (no replies)</title>
            <link>https://forums.mysql.com/read.php?24,709090,709090#msg-709090</link>
            <description><![CDATA[ On a windows 2022 server running an application (website) the pulls data from a Mysql database.<br />
the site stops responding, I run a netstat- a on the windows server to see over 40 of them :<br />
TCP    SERVERIPADDESS:59142    mysql-:3306          TIME_WAIT<br />
TCP    SERVERIPADDESS:59143    mysql-:3306          TIME_WAIT<br />
TCP    SERVERIPADDESS:59144    mysql-:3306          TIME_WAIT<br />
TCP    SERVERIPADDESS:59145    mysql-:3306          TIME_WAIT<br />
TCP    SERVERIPADDESS:59146    mysql-:3306          TIME_WAIT<br />
TCP    SERVERIPADDESS:59147    mysql-:3306          TIME_WAIT<br />
TCP    SERVERIPADDESS:59148    mysql-:3306          TIME_WAIT<br />
<br />
Do i need to look at the windows side (regedit) or look the Mysql side?]]></description>
            <dc:creator>na na</dc:creator>
            <category>Performance</category>
            <pubDate>Thu, 25 May 2023 14:09:07 +0000</pubDate>
        </item>
        <item>
            <guid>https://forums.mysql.com/read.php?24,709000,709000#msg-709000</guid>
            <title>Sysbench fileio (no replies)</title>
            <link>https://forums.mysql.com/read.php?24,709000,709000#msg-709000</link>
            <description><![CDATA[ HI,<br />
I am running sysbench fileio for mysql with below command<br />
./sysbench fileio --file-total-size=10G --file-test-mode=rndrw --time=300 --mysql-db=mysql --mysql-host=localhost --mysql-user=root prepare<br />
<br />
It generated 128 intermediate test_file.0 , and so on test_file.128.<br />
when I opened these files it shows only character ^@ which is 0x0 means null.<br />
<br />
Is all these files are valid? why it is having only NULL character. Could anyone explain it.<br />
<br />
When I run it, it is giving all the values as shown below.<br />
./sysbench fileio --file-total-size=10G --file-test-mode=rndrw --time=300 --mysql-db=mysql --mysql-host=localhost --mysql-user=root run<br />
Running the test with following options:<br />
Number of threads: 1<br />
Initializing random number generator from current time<br />
<br />
Extra file open flags: (none)<br />
128 files, 80MiB each<br />
10GiB total file size<br />
Block size 16KiB<br />
Number of IO requests: 0<br />
Read/Write ratio for combined random IO test: 1.50<br />
Periodic FSYNC enabled, calling fsync() each 100 requests.<br />
Calling fsync() at the end of test, Enabled.<br />
Using synchronous I/O mode<br />
Doing random r/w test<br />
Initializing worker threads…<br />
<br />
Threads started!<br />
<br />
Throughput:<br />
read: IOPS=157.09 2.45 MiB/s (2.57 MB/s)<br />
write: IOPS=104.73 1.64 MiB/s (1.72 MB/s)<br />
fsync: IOPS=335.32<br />
<br />
Latency (ms):<br />
min: 0.00<br />
avg: 1.67<br />
max: 139.93<br />
95th percentile: 10.84<br />
sum: 299863.61]]></description>
            <dc:creator>Rahul Raj</dc:creator>
            <category>Performance</category>
            <pubDate>Fri, 12 May 2023 08:11:28 +0000</pubDate>
        </item>
        <item>
            <guid>https://forums.mysql.com/read.php?24,708894,708894#msg-708894</guid>
            <title>Migration from MAaria-db (no replies)</title>
            <link>https://forums.mysql.com/read.php?24,708894,708894#msg-708894</link>
            <description><![CDATA[ Hi,<br />
<br />
We have migrated our db (for poc) to Aurora my sql based on 8.0.23 and we are facing huge performance issues where we see my sql doesn&#039;t use the correct indexes. We can&#039;t change the whole code to use force index.<br />
Anyone has encountered such an scenario ?<br />
<br />
Thanks in advance]]></description>
            <dc:creator>Nitzan Israeli</dc:creator>
            <category>Performance</category>
            <pubDate>Thu, 27 Apr 2023 07:50:01 +0000</pubDate>
        </item>
        <item>
            <guid>https://forums.mysql.com/read.php?24,708748,708748#msg-708748</guid>
            <title>Understanding Serializable Isolation Level (no replies)</title>
            <link>https://forums.mysql.com/read.php?24,708748,708748#msg-708748</link>
            <description><![CDATA[ from the docs:<br />
<a href="https://dev.mysql.com/doc/refman/8.0/en/innodb-transaction-isolation-levels.html"  rel="nofollow">https://dev.mysql.com/doc/refman/8.0/en/innodb-transaction-isolation-levels.html</a><br />
<br />
<br />
SERIALIZABLE<br />
<br />
This level is like REPEATABLE READ, but InnoDB implicitly converts all plain SELECT statements to SELECT ... FOR SHARE if autocommit is disabled. If autocommit is enabled, the SELECT is its own transaction. It therefore is known to be read only and can be serialized if performed as a consistent (nonlocking) read and need not block for other transactions. (To force a plain SELECT to block if other transactions have modified the selected rows, disable autocommit.)<br />
<br />
if we consider the example given here:<br />
<a href="https://www.postgresql.org/docs/current/transaction-iso.html#XACT-SERIALIZABLE"  rel="nofollow">https://www.postgresql.org/docs/current/transaction-iso.html#XACT-SERIALIZABLE</a><br />
<br />
As an example, consider a table mytab, initially containing:<br />
<br />
 class | value<br />
-------+-------<br />
     1 |    10<br />
     1 |    20<br />
     2 |   100<br />
     2 |   200<br />
Suppose that serializable transaction A computes:<br />
<br />
SELECT SUM(value) FROM mytab WHERE class = 1;<br />
and then inserts the result (30) as the value in a new row with class = 2. Concurrently, serializable transaction B computes:<br />
<br />
SELECT SUM(value) FROM mytab WHERE class = 2;<br />
and obtains the result 300, which it inserts in a new row with class = 1.<br />
<br />
---<br />
Per MySQL docs, Tx1 will lock rows 1,2 and Tx2 will lock rows 3,4. And both will be able to insert concurrently leading to a serialization anomaly.<br />
<br />
I tried running this example on MySQL 8.0 and it correctly handled the problem. It blocked one Tx and when both tried to commit it detected a deadlock and aborted one of the transactions. I am very impressed with it, however as per docs both transactions should have gone through since SELECT FOR SHARE would lock rows 1,2 for tx1 and rows 3,4 for tx2. Can someone explain this to me? what is happening behind the scenes in MySQL with this example? thanks.]]></description>
            <dc:creator>morpheus na</dc:creator>
            <category>Performance</category>
            <pubDate>Sat, 15 Apr 2023 16:32:47 +0000</pubDate>
        </item>
    </channel>
</rss>
