기본 키의 MySQL/MariaDB 느린 업데이트
쿼리:
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개의 행이 영향을 받지만 1210ms가 걸렸습니다.ID로 이 행을 선택하는 데 항상 0ms가 걸렸습니다.테이블 크기는 (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 사이에서 일관성이 없는 이유는 무엇입니까? 0 ~ 2500ms?그것이 높은 근본 원인을 찾는 방법은 무엇입니까?
서버 버전: 10.0.17-MariaDB-1~wheezy.VPS에는 눈에 띄는 부하가 전혀 없습니다.
UPD: 쿼리 뒤에 상태 변수 추가:
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)
제가 제안할 수 있는 것은 당신의 테이블과 데이터를 Mysql MyIsam 엔진으로 마이그레이션하고 동일한 쿼리를 실행하는 것입니다.MariaDB의 약점을 발견했거나 구성이 잘못되었거나 과도하게 조정되었을 수 있습니다.
문제는 MySQL/MariaDB가 아니라 OpenVZ와 서버의 IO 스케줄링에 있었습니다.더 생산적인 디스크로 마이그레이션한 후 문제가 사라졌습니다.
언급URL : https://stackoverflow.com/questions/29060379/mysql-mariadb-slow-update-on-primary-key
'programing' 카테고리의 다른 글
MariaDB 데이터베이스에 대한 쿼리 동기화 (0) | 2023.09.01 |
---|---|
해시방 URL로 페이스북 공유/좋아요를 처리하는 방법은 무엇입니까? (0) | 2023.09.01 |
이미지를 이미지 보기에 맞추고 가로 세로 비율을 유지한 다음 이미지 보기 크기를 이미지 크기에 맞게 조정하시겠습니까? (0) | 2023.09.01 |
UI 스택 보기 보기 숨기기 애니메이션 (0) | 2023.09.01 |
VBA Excel 매크로에서 유닛 테스트를 설정하는 방법은 무엇입니까? (0) | 2023.09.01 |