После обновления с MySQL 5.5 до 5.7 запросы чаще сталкиваются с тупиком - PullRequest
Новая
       62

После обновления с MySQL 5.5 до 5.7 запросы чаще сталкиваются с тупиком

1 голос
/ 30 октября 2019

Недавно мы перенесли нашу производственную базу данных в Amazon RDS с обновлением версии с 5.5 до 5.7 с помощью сервиса AWS DMS. После этого у нас часто возникают проблемы взаимоблокировки для нашей вставки ... при повторных запросах на обновление ключей и запросах на обновление. Тогда как в MySQL 5.5 он был очень минимальным.

Например, скажем, одна из наших структур таблиц выглядит следующим образом. 

CREATE TABLE `job_notification` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `uid` int(11) NOT NULL,
  `job_id` int(11) NOT NULL,
  `created_time` int(11) NOT NULL,
  `updated_time` int(11) NOT NULL,
  `notify_status` tinyint(3) DEFAULT '0'
  PRIMARY KEY (`id`),
  UNIQUE KEY `uid` (`uid`,`job_id`),
) ENGINE=InnoDB AUTO_INCREMENT=58303732 DEFAULT CHARSET=utf8 COLLATE=utf8_bin

Наш запрос на вставку выглядит следующим образом ... 

    INSERT INTO job_notification (uid, notify_status, updated_time, created_time, job_id) VALUES
('24832194',1,1571900253,1571900253,'734749'),
('24832194',1,1571900254,1571900254,'729161'),
('24832194',1,1571900255,1571900255,'713225'),
('24832194',1,1571900256,1571900256,'701897'),
('24832194',1,1571900257,1571900257,'682155'),
('24832194',1,1571900258,1571900258,'730817'),
('24832194',1,1571900259,1571900259,'717162'),
('24832194',1,1571900260,1571900260,'712884'),
('24832194',1,1571900261,1571900261,'708267'),
('24832194',1,1571900262,1571900262,'701855'),
('24832194',1,1571900263,1571900263,'702129'),
('24832194',1,1571900264,1571900264,'726738'),
('24832194',1,1571900265,1571900265,'725105'),
('24832194',1,1571900266,1571900266,'709306'),
('24832194',1,1571900267,1571900267,'702218'),
('24832194',1,1571900268,1571900268,'700966'),
('24832194',1,1571900269,1571900269,'693848'),
('24832194',1,1571900270,1571900270,'730793'),
('24832194',1,1571900271,1571900271,'729352'),
('24832194',1,1571900272,1571900272,'729043'),
('24832194',1,1571900273,1571900273,'724631'),
('24832194',1,1571900274,1571900274,'718394'),
('24832194',1,1571900275,1571900275,'711702'),
('24832194',1,1571900276,1571900276,'707765'),
('24832194',1,1571900277,1571900277,'692288'),
('24832194',1,1571900278,1571900278,'735549'),
('24832194',1,1571900279,1571900279,'730786'),
('24832194',1,1571900280,1571900280,'706814'),
('24832194',1,1571900281,1571900281,'688999'),
('24832194',1,1571900282,1571900282,'685079'),
('24832194',1,1571900283,1571900283,'686661'),
('24832194',1,1571900284,1571900284,'722110'),
('24832194',1,1571900285,1571900285,'715277'),
('24832194',1,1571900286,1571900286,'701846'),
('24832194',1,1571900287,1571900287,'730105'),
('24832194',1,1571900288,1571900288,'725579')
 ON DUPLICATE KEY UPDATE notify_status=VALUES(notify_status), updated_time=VALUES(updated_time)

Наш запрос на обновление выглядит следующим образом ... 

update job_notification set notify_status = 3 where uid = 51032194 and job_id in (616661, 656221, 386760, 189461, 944509, 591552, 154153, 538703, 971923, 125080, 722110, 715277, 701846, 725579, 686661, 685079)

Эти запросы прекрасно работали в MySQL 5.5 с тем же размером пакета данных и индекса, но после миграции часто возникали взаимные блокировкиэтот тип запросов ...

NB. Наша система - это высокоуровневая параллельная система. innodb_deadlock_detect отключен. innodb_lock_wait_timeout равно 50.

innodb_buffer_pool_size равно 50465865728

Когда мы объяснили запросы, это дало лучший план выполнения. Тем не менее, мы получаем частые взаимоблокировки, и из-за этого другие запросы также замедляются.

Оба запроса выполняются как разные потоки API (разные соединения) с использованием пакета python Mysqldb с включенной автоматической фиксацией в БД MySQL.

Объяснить вывод 

explain update job_notification SET notify_status = 3 where uid = 51032194 and job_id in (616661, 656221, 386760, 189461, 944509, 591552, 154153, 538703, 971923, 125080, 722110, 715277, 701846, 725579, 686661, 685079);
+----+--------+------------+------------+-------+---------------+------+-----+-------+------+----------+--------+
| id | select_type | table                    | partitions | type  | possible_keys | key  | key_len | ref         | rows | filtered |Extra       |
+----+----------+------------+------------+-------+---------------+------+---------+-------------+------+----------+----------+
|  1 | UPDATE      | job_notification | NULL       | range | uid           | uid  | 8       | const,const |   27 |   100.00 | Using where |
+----+-------------+--------------------------+------------+-------+---------------+------+---------+-------------+--------+-------------+

1 Ответ

0 голосов
/ 04 ноября 2019

Если это в первую очередь таблица сопоставления «многие ко многим», избавьтесь, если id, и следуйте остальным советам в http://mysql.rjweb.org/doc.php/index_cookbook_mysql#many_to_many_mapping_table

. Это ускорит выполнение запросов в обеих системах. Быстрее = меньше шансов на тупик.

Посмотрим на тупик;могут быть и другие вещи. Используйте SHOW ENGINE INNODB STATUS; сразу после возникновения тупика.

...