Медленный выбор при вставке больших объемов данных (MYSQL)

Question

У меня есть процесс, который импортирует много данных (950 тыс. Строк), используя вставки, которые вставляют 500 строк одновременно. Процесс обычно занимает около 12 часов, что не так уж плохо. Обычно выполнение запроса к таблице выполняется довольно быстро (менее 1 секунды), поскольку я установил (как мне кажется) правильные индексы на месте. Проблема, которую я имею, пытается запустить запрос, когда процесс импорта работает. Это делает запрос занимает почти 2 минуты! Что я могу сделать, чтобы эти две вещи не конкурировали за ресурсы (или что-то еще)? Я посмотрел "вставка отложена", но не уверен, что хочу изменить таблицу на MyISAM.

Спасибо за любую помощь!

Answer 1

Итак, я наконец нашел замедление при поиске во время импорта моих данных. У меня был один запрос, подобный этому:

SELECT * FROM `properties` WHERE (state like 'Florida%') and (county like 'Hillsborough%') ORDER BY created_at desc LIMIT 0, 50

и когда я запустил на нем EXPLAIN, я обнаружил, что он сканирует около 215 000 строк (даже с соответствующими индексами по штатам и округам). Затем я запустил EXPLAIN по следующему запросу:

SELECT * FROM `properties` WHERE (state = 'Florida') and (county = 'Hillsborough') ORDER BY created_at desc LIMIT 0, 50

и увидел, что нужно было только сканировать 500 строк. Учитывая, что фактический набор результатов был что-то вроде 350, я думаю, что я определил замедление.

Я перешел к тому, чтобы не использовать "лайк" в своих запросах, и очень доволен более резкими результатами.

Спасибо всем за помощь и предложения. Они очень ценятся!

Answer 2

Вы пробовали использовать приоритетные подсказки?

SELECT HIGH_PRIORITY ... и INSERT LOW_PRIORITY ...

Answer 3

12 часов для вставки 950 тыс. Строк - довольно тяжелый режим работы. Насколько велики эти ряды? Что за индексы на них? Даже если фактическая вставка данных происходит быстро, постоянное обновление индексов определенно приведет к снижению производительности для всего, что использует эти таблицы в данный момент.

Выполняете ли вы этот импорт с помощью синтаксиса групповой вставки (вставьте в таб (x) значения (a), (b), (c) и т. Д.) Или по одной вставке на строку? Выполнение массовой вставки потребует более длительного периода обновления индекса (так как он должен генерировать данные индекса для 500 строк), чем выполнение этой операции для одной строки. Без сомнения, во время обновления данных будет установлена ​​какая-то внутренняя блокировка индексов, и в этом случае вы будете бороться как минимум с 950k / 500 = 1900 сеансов блокировки.

Я обнаружил, что в некоторых из моих сценариев массовой вставки (анализатор журнала http для некоторых пользовательских интеллектуальных данных) было быстрее ОТКЛЮЧИТЬ индексы для соответствующих таблиц, а затем повторно включать / восстанавливать их после сброс данных завершен. Если я правильно помню, это было около 37 минут, чтобы вставить 200 000 строк данных попаданий с включенными ключами, и около 3 минут без индексации.

Answer 4

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