How can I optimize/measure UPSERT performance on MYSQL? - mysql

Question

How can I measure mysql "UPSERT" performance? More specifically, get information about the implied search before the insert/update/replace?
using mysql 8, with a schema that has three fields. Two are part of the primary key. Table is currently innodb but that is not a hard requirement.
CREATE TABLE IF NOT EXISTS `test`.`recent`
( `uid` int NOT NULL, `gid` int NOT NULL, `last` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (`uid`,`gid`),
KEY `idx_last` (`last`) USING BTREE
) ENGINE=InnoDB;
+----------+----------+------+-----+-------------------+-------+
| Field | Type | Null | Key | Default | Extra |
+----------+----------+------+-----+-------------------+-------+
| uid | int(11) | NO | PRI | NULL | |
| gid | int(11) | NO | PRI | NULL | |
| last | datetime | NO | MUL | CURRENT_TIMESTAMP | |
+----------+----------+------+-----+-------------------+-------+
I plan to insert values using
INSERT INTO test.recent (uid,gid) VALUES (1, 1)
ON DUPLICATE KEY UPDATE last=NOW();
How do I go about figuring out the performance of this query, since EXPLAIN will not show the implied search, only the insert:
MYSQL> explain INSERT INTO test.recent (uid,gid) VALUES (1, 1) ON DUPLICATE KEY UPDATE last=NOW();
+----+-------------+--------+------------+------+---------------+------+---------+------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+--------+------------+------+---------------+------+---------+------+------+----------+-------+
| 1 | INSERT | recent | NULL | ALL | NULL | NULL | NULL | NULL | NULL | NULL | NULL |
+----+-------------+--------+------------+------+---------------+------+---------+------+------+----------+-------+
1 row in set (0.00 sec)
MYSQL> explain INSERT INTO test.recent (uid,gid) VALUES (1, 1);
+----+-------------+--------+------------+------+---------------+------+---------+------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+--------+------------+------+---------------+------+---------+------+------+----------+-------+
| 1 | INSERT | recent | NULL | ALL | NULL | NULL | NULL | NULL | NULL | NULL | NULL |
+----+-------------+--------+------------+------+---------------+------+---------+------+------+----------+-------+
1 row in set (0.00 sec)
which is different from the explain on an actual search:
MYSQL> explain select last from test.recent where uid=1 and gid=1;
+----+-------------+--------+------------+-------+---------------+---------+---------+-------------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+--------+------------+-------+---------------+---------+---------+-------------+------+----------+-------+
| 1 | SIMPLE | recent | NULL | const | PRIMARY | PRIMARY | 8 | const,const | 1 | 100.00 | NULL |
+----+-------------+--------+------------+-------+---------------+---------+---------+-------------+------+----------+-------+
1 row in set, 1 warning (0.00 sec)
One of the variables I am trying to figure out, is if performance would change at all if I use a blind update instead:
MYSQL> explain REPLACE INTO test.recent VALUES (1, 1, NOW());
+----+-------------+--------+------------+------+---------------+------+---------+------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+--------+------------+------+---------------+------+---------+------+------+----------+-------+
| 1 | REPLACE | recent | NULL | ALL | NULL | NULL | NULL | NULL | NULL | NULL | NULL |
+----+-------------+--------+------------+------+---------------+------+---------+------+------+----------+-------+
1 row in set (0.01 sec)
But as you can see, the information i get is the same (unhelpful) as I get for an "explain insert".
Another question I would like to answer based on measurements, is if things would change for better or worse (and by how much) If i tested both upserts approaches (on duplicate vs replace) with a DATE field (instead of the DATETIME), which in theory would results in less writes (but still the same number of implied searches). But again, explain is no help here.

Answer 1

Don't trust EXPLAIN with very few rows.
Your IODKU is optimal. Here's how it will work:
1-. Like a SELECT, drill down the PRIMARY KEY BTree to find the row with (1,1) or a gap where (1,1) should be. That is about as fast a lookup as can be had.
2a. If the row exists, UPDATE it.
2b. If the row does not exist, INSERT (and set last to the DEFAULT of `CURRENT_TIMESTAMP).
If you want, I can go into details of the steps. But we are talking sub-millisecond for each.
If I wanted to time the query, I would use some high-res timer. Very likely the timings would bounce around, depending of whether there is a breeze blowing, or a butterfly is flapping its wings, or the phase of the moon.
Caveat: If you "simplified" your query for this question, I may not be giving you correct info for the real query.
If you are doing a thousand IODKUs, then there may be optimizations that involve combining them. There are some typical optimizations that can easily give 10x speedup.