MySQL/MariaDB 主键更新缓慢
MySQL/MariaDB slow UPDATE on PRIMARY KEY
查询:
UPDATE `cart` SET `user_id` = NULL, `completed` = 0 WHERE `id` = 6948;
Query OK, 0 rows affected (1.21 sec)
Rows matched: 1 Changed: 0 Warnings: 0
0 行受影响,但耗时 1210 毫秒。 SELECT 这一行的 id 总是花费 0 毫秒。
Table 大小为(6,354 行)。
> show create table cart;
CREATE TABLE `cart` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`user_id` int(11) DEFAULT NULL,
`completed` tinyint(1) NOT NULL DEFAULT '0' COMMENT 'флаг, указывающий на оформление заказа из данной корзины',
PRIMARY KEY (`id`),
KEY `user_id` (`user_id`)
) ENGINE=InnoDB AUTO_INCREMENT=6964 DEFAULT CHARSET=utf8
> show index from cart;
+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| cart | 0 | PRIMARY | 1 | id | A | 6386 | NULL | NULL | | BTREE | | |
| cart | 1 | user_id | 1 | user_id | A | 2128 | NULL | NULL | YES | BTREE | | |
+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
这里是来自 show profile all
的这个查询的摘录
| Status | Duration | CPU_user | CPU_system | Context_voluntary | Context_involuntary | Block_ops_in | Block_ops_out | Messages_sent | Messages_received | Page_faults_major | Page_faults_minor | Swaps | Source_function | Source_file | Source_line |
| query end | 2.502555 | 0.003000 | 0.000000 | 88 | 8 | 0| 136 | 0 | 0 | 0 | 0 | 0 | mysql_execute_command | sql_parse.cc | 5093 |
为什么block_ops_out如此不稳定,从0到400,耗时0ms~2500ms???如何找到高的根本原因?
服务器版本:10.0.17-MariaDB-1~wheezy。 VPS 根本没有任何明显的负载。
更新: 在查询后添加了状态变量:
MariaDB> flush status; UPDATE `cart` SET `user_id` = NULL, `completed` = 0 WHERE `id` = 6948; SHOW SESSION STATUS LIKE 'Handler%';
Query OK, 0 rows affected (0.54 sec)
^[[A^[[BQuery OK, 0 rows affected (3.88 sec)
Rows matched: 1 Changed: 0 Warnings: 0
+----------------------------+-------+
| Variable_name | Value |
+----------------------------+-------+
| Handler_commit | 2 |
| Handler_delete | 0 |
| Handler_discover | 0 |
| Handler_external_lock | 0 |
| Handler_icp_attempts | 0 |
| Handler_icp_match | 0 |
| Handler_mrr_init | 0 |
| Handler_mrr_key_refills | 0 |
| Handler_mrr_rowid_refills | 0 |
| Handler_prepare | 2 |
| Handler_read_first | 0 |
| Handler_read_key | 1 |
| Handler_read_last | 0 |
| Handler_read_next | 0 |
| Handler_read_prev | 0 |
| Handler_read_rnd | 0 |
| Handler_read_rnd_deleted | 0 |
| Handler_read_rnd_next | 0 |
| Handler_rollback | 0 |
| Handler_savepoint | 0 |
| Handler_savepoint_rollback | 0 |
| Handler_tmp_update | 0 |
| Handler_tmp_write | 0 |
| Handler_update | 1 |
| Handler_write | 0 |
+----------------------------+-------+
25 rows in set (0.00 sec)
我只能建议尝试将您的 table 和数据迁移到 Mysql MyIsam 引擎并执行相同的查询。也许您只是发现了 MariaDB 的弱点,或者配置错误或过度调整。
问题不在MySQL/MariaDB,而是在OpenVZ和服务器上的IO调度。迁移到更高效的磁盘后,问题消失了。
查询:
UPDATE `cart` SET `user_id` = NULL, `completed` = 0 WHERE `id` = 6948;
Query OK, 0 rows affected (1.21 sec)
Rows matched: 1 Changed: 0 Warnings: 0
0 行受影响,但耗时 1210 毫秒。 SELECT 这一行的 id 总是花费 0 毫秒。 Table 大小为(6,354 行)。
> show create table cart;
CREATE TABLE `cart` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`user_id` int(11) DEFAULT NULL,
`completed` tinyint(1) NOT NULL DEFAULT '0' COMMENT 'флаг, указывающий на оформление заказа из данной корзины',
PRIMARY KEY (`id`),
KEY `user_id` (`user_id`)
) ENGINE=InnoDB AUTO_INCREMENT=6964 DEFAULT CHARSET=utf8
> show index from cart;
+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| cart | 0 | PRIMARY | 1 | id | A | 6386 | NULL | NULL | | BTREE | | |
| cart | 1 | user_id | 1 | user_id | A | 2128 | NULL | NULL | YES | BTREE | | |
+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
这里是来自 show profile all
的这个查询的摘录
| Status | Duration | CPU_user | CPU_system | Context_voluntary | Context_involuntary | Block_ops_in | Block_ops_out | Messages_sent | Messages_received | Page_faults_major | Page_faults_minor | Swaps | Source_function | Source_file | Source_line |
| query end | 2.502555 | 0.003000 | 0.000000 | 88 | 8 | 0| 136 | 0 | 0 | 0 | 0 | 0 | mysql_execute_command | sql_parse.cc | 5093 |
为什么block_ops_out如此不稳定,从0到400,耗时0ms~2500ms???如何找到高的根本原因?
服务器版本:10.0.17-MariaDB-1~wheezy。 VPS 根本没有任何明显的负载。
更新: 在查询后添加了状态变量:
MariaDB> flush status; UPDATE `cart` SET `user_id` = NULL, `completed` = 0 WHERE `id` = 6948; SHOW SESSION STATUS LIKE 'Handler%';
Query OK, 0 rows affected (0.54 sec)
^[[A^[[BQuery OK, 0 rows affected (3.88 sec)
Rows matched: 1 Changed: 0 Warnings: 0
+----------------------------+-------+
| Variable_name | Value |
+----------------------------+-------+
| Handler_commit | 2 |
| Handler_delete | 0 |
| Handler_discover | 0 |
| Handler_external_lock | 0 |
| Handler_icp_attempts | 0 |
| Handler_icp_match | 0 |
| Handler_mrr_init | 0 |
| Handler_mrr_key_refills | 0 |
| Handler_mrr_rowid_refills | 0 |
| Handler_prepare | 2 |
| Handler_read_first | 0 |
| Handler_read_key | 1 |
| Handler_read_last | 0 |
| Handler_read_next | 0 |
| Handler_read_prev | 0 |
| Handler_read_rnd | 0 |
| Handler_read_rnd_deleted | 0 |
| Handler_read_rnd_next | 0 |
| Handler_rollback | 0 |
| Handler_savepoint | 0 |
| Handler_savepoint_rollback | 0 |
| Handler_tmp_update | 0 |
| Handler_tmp_write | 0 |
| Handler_update | 1 |
| Handler_write | 0 |
+----------------------------+-------+
25 rows in set (0.00 sec)
我只能建议尝试将您的 table 和数据迁移到 Mysql MyIsam 引擎并执行相同的查询。也许您只是发现了 MariaDB 的弱点,或者配置错误或过度调整。
问题不在MySQL/MariaDB,而是在OpenVZ和服务器上的IO调度。迁移到更高效的磁盘后,问题消失了。