1

We just upgraded our database from mariadb 5.5.56 to MySQL 8. We are facing issue that some update queries to an InnoDB takes a long time randomly. Please note that 99% of the time, query is fast but then randomly suddenly it takes huge time and then again back to normal. We DO NOT face this issue in mariadb 5.5.56

CREATE TABLE `users` (
  `uid` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `pid` int(10) unsigned NOT NULL DEFAULT '0',
  `ipaddr` int(10) unsigned DEFAULT '0',
  PRIMARY KEY (`uid`,`pid`),
  KEY `pid` (`pid`)
) ENGINE=InnoDB AUTO_INCREMENT=161089 DEFAULT CHARSET=utf8
/*!50100 PARTITION BY HASH (`pid`)
PARTITIONS 101
mysql> update users set ipaddr=2148888835 where uid=1 limit 1;
Query OK, 1 row affected **(39.51 sec)**
Rows matched: 1  Changed: 1  Warnings: 0
mysql> update users set ipaddr=2148888835 where uid=1 limit 1;
Query OK, 1 row affected (0.01 sec)
Rows matched: 1  Changed: 1  Warnings: 0

query is very simple and it uses primary key as shown below

mysql> explain update users set ipaddr=123 where uid=1;
+----+-------------+-------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------+---------------+---------+---------+-------+------+----------+-------------+
| id | select_type | table | partitions                                                                                                                                                                                                                                                                                                                                                                                                 | type  | possible_keys | key     | key_len | ref   | rows | filtered | Extra       |
+----+-------------+-------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------+---------------+---------+---------+-------+------+----------+-------------+
|  1 | UPDATE      | users | p0,p1,p2,p3,p4,p5,p6,p7,p8,p9,p10,p11,p12,p13,p14,p15,p16,p17,p18,p19,p20,p21,p22,p23,p24,p25,p26,p27,p28,p29,p30,p31,p32,p33,p34,p35,p36,p37,p38,p39,p40,p41,p42,p43,p44,p45,p46,p47,p48,p49,p50,p51,p52,p53,p54,p55,p56,p57,p58,p59,p60,p61,p62,p63,p64,p65,p66,p67,p68,p69,p70,p71,p72,p73,p74,p75,p76,p77,p78,p79,p80,p81,p82,p83,p84,p85,p86,p87,p88,p89,p90,p91,p92,p93,p94,p95,p96,p97,p98,p99,p100 | range | PRIMARY       | PRIMARY | 4       | const |    1 |   100.00 | Using where |
+----+-------------+-------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------+---------------+---------+---------+-------+------+----------+-------------+
1 row in set, 1 warning (0.00 sec)


I enabled profiling and it shows updating takes long time.

mysql> SHOW PROFILE;                                                                                                        +--------------------------------+-----------+
| Status                         | Duration  |
+--------------------------------+-----------+
| starting                       |  0.000045 |
| Executing hook on transaction  |  0.000005 |
| starting                       |  0.000005 |
| checking permissions           |  0.000004 |
| Opening tables                 |  0.000017 |
| init                           |  0.000005 |
| System lock                    |  0.000193 |
| updating                       | 39.470708 |
| end                            |  0.000009 |
| query end                      |  0.000004 |
| waiting for handler commit     |  0.038291 |
| closing tables                 |  0.000039 |
| freeing items                  |  0.000024 |
| cleaning up                    |  0.000028 |
+--------------------------------+-----------+
14 rows in set, 1 warning (0.00 sec)

Although the tables were freshly created using mysqldump, I even tried optimising the table but it didn't help.


mysql> optimize table users;
+--------------+----------+----------+-------------------------------------------------------------------+
| Table        | Op       | Msg_type | Msg_text                                                          |
+--------------+----------+----------+-------------------------------------------------------------------+
| mesibo.users | optimize | note     | Table does not support optimize, doing recreate + analyze instead |
| mesibo.users | optimize | status   | OK                                                                |
+--------------+----------+----------+-------------------------------------------------------------------+
2 rows in set (2 min 3.07 sec)

Below is config file. Our server has 64GB ram, we allocated 16G to innodb, however changing this value or removing it from configuration does not help.

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
log-error=/var/log/mysql/mysqld.log
pid-file=/run/mysqld/mysqld.pid
innodb_buffer_pool_size=16G
max_connections = 1024

Any clue what might be wrong here?

Rahul
  • 390
  • 4
  • 14
  • Your `LIMIT` clause does not make sense, because there is no accompanying `ORDER BY`. Also, could it be that there is some _other_ process on your MySQL which occasionally spikes and consumes resources? – Tim Biegeleisen Nov 24 '19 at 09:32
  • 1
    @TimBiegeleisen any insight how to debug? As I mentioned, we do not face this issue with our existing and loaded mariadb 5.5 server. Our new MySQL8 server is not even on production and have no other processes running. If you point me to get you some info, I can do that – Rahul Nov 24 '19 at 09:35
  • I don't even understand what the query is supposed to be doing. – Tim Biegeleisen Nov 24 '19 at 09:36
  • Have you tried running this on another install of MySQL 8 (like in a Docker container or a VM on your computer)? Maybe it's a weird server-specific issue. If you don't see it on the other install, it might narrow down the problem space. – Cully Nov 24 '19 at 09:40
  • @Cully, it's not running in VM or a container. The machine specs is i7 6700, 64GB RAM, 512GB NVMe. The entire specs is superior to our mariadb-5.5 setup. – Rahul Nov 24 '19 at 09:44
  • I'm asking if you've tried running the query on another install of MySQL 8. If you try on another install and don't have the issue, it could point to it being a problem with your server. – Cully Nov 24 '19 at 09:46
  • I am setting up another, will post results here. However any other clues in the mean time – Rahul Nov 24 '19 at 09:52
  • @Cully, I installed on another server and I could not reproduce the issue. However, I now reinstalled MySQL8 on this server (after deleting /var/lib/mysql/*) and reloaded the database. Issue is back. Any clue? – Rahul Nov 24 '19 at 10:13
  • I have no idea. Did you have the same MySQL configuration on the second server (the one you didn't have the issue on)? – Cully Nov 24 '19 at 21:18
  • can you give out put of `show create table of users ` ? – EchoMike444 Nov 25 '19 at 06:45
  • can you run ` explain update users set ipaddr=123 where uid=1;` of both version ? – EchoMike444 Nov 25 '19 at 06:46
  • @Cully, all, we started getting same issue on second server after adding more data. – Rahul Nov 26 '19 at 03:01
  • @EchoMike444 post updated with user table definition, explain is same. – Rahul Nov 26 '19 at 03:06
  • We have multiple connecting updating the same table but different rows at the same time. Since it's an innodb, it should not lock but in case any MySQL8 specific issue. – Rahul Nov 26 '19 at 03:10
  • because you have partitions can you run ` EXPLAIN PARTITIONS` , and can you run `EXPLAIN ANALYZE ` – EchoMike444 Nov 26 '19 at 03:26
  • I got a partial answer, it seems that MySQL8 is not using index when subquery has group columns which is taking a long time. Although it's a separate subquery in which `users` database is used, but it appears to be lock the table. This was not happening with mariadb 5.5, I have posted a separate question here https://stackoverflow.com/questions/59044056/mysql-8-is-not-using-index-when-subquery-has-a-group-column – Rahul Nov 26 '19 at 05:26

0 Answers0