Запрос на обновление MariaDB занимает много времени

В настоящее время у меня проблемы с репликацией mysql. Мы используем настройку мастер-мастер для аварийного переключения.

Сама репликация работает, и я считаю, что все правильно. Но у нас возникают проблемы с некоторыми запросами, выполнение которых занимает уйму времени.

Пример:

| 166 | database | Connect | 35 | updating | update xx set xx = 'xx' where xx = 'xx' and xx = 'xx' | 0.000 |

Эти запросы на обновление иногда занимают более 20-30 секунд, и из-за этого репликация начинает отставать, и в течение дня она будет отставать на пару часов. Странно то, что со временем он догонит другого хозяина.

Размер таблицы составляет около 100 мм строк и около 70 ГБ. На мастере, где выполняются запросы, они занимают меньше секунды.

Обе конфигурации, mysql и server, почти идентичны, и мы пытались оптимизировать таблицу и запросы, но пока безуспешно.

Какие-нибудь рекомендации, которые мы могли бы попробовать решить? Дайте мне знать, если я могу предоставить вам дополнительную информацию.

С использованием:

MariaDB 10.1.35 - CentOS 7.5.1804

Стоит ли изучать PHP в 2023-2024 годах?
Стоит ли изучать PHP в 2023-2024 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
0
0
743
1

Ответы 1

Ключевым аспектом этого является то, сколько строк вы обновляете:

  • Если процент низкий (менее 5% строк), тогда может помочь индекс.

  • В противном случае, если вы обновляете большое количество строк (более 5%), полное сканирование таблицы будет оптимальным. Если у вас есть миллионы строк, это будет медленным. Возможно, разделение таблицы может помочь, но я бы сказал, что у вас мало шансов улучшить ее.

Я предполагаю, что вы обновляете небольшой процент строк, поэтому вы можете использовать индекс. Посмотрите на условие в заявлении WHERE. Если это выглядит так:

WHERE col1 = 'xx' and col2 = 'yy'

Затем индекс по этим столбцам ускорит ваш запрос. Конкретно:

create index ix1 on my_table (col1, col2);

В зависимости от избирательности ваших столбцов перевернутый индекс может быть быстрее:

create index ix2 on my_table (col2, col1);

Вам нужно будет попробовать, какой из них лучше для вашего конкретного случая.

При использовании обоих столбцов их относительная избирательность нет влияет на порядок определения индекса.

Rick James 02.10.2018 18:11

Другие вопросы по теме