ОШИБКА 1206 (HY000): общее количество блокировок превышает размер таблицы блокировок

Question

У меня есть одна большая таблица, которая имеет около 80 миллионов строк. Я пытаюсь сгенерировать некоторую статистику и сохранить ее в другой таблице, используя следующий запрос -

insert into table2
select col1, col2,
STR_TO_DATE(date(col_timestamp), '%Y-%m-%d') as col_date,
sum(col4)/1000000 as total_size ,count(*) as total_count
from table1 group by col1,col2, col_date;

Намерение состоит в том, чтобы предварительно обработать некоторую статистику из основной таблицы, поскольку для получения простых подсчетов требуется 15 минут , Я получаю эту ошибку -

 The total number of locks exceeds the lock table size

Я пытался увеличить innodb_buffer_pool_size до 1G, как указано в Общее количество блокировок превышает размер таблицы блокировок и перезапускается mysql. Эффективное значение успешно увеличилось до

'innodb_buffer_pool_size', '1073741824'

, но ошибка остается той же. Итак, мой вопрос -

1. Должен ли я увеличить его до 2G, может быть?
2. Какая часть запроса вызывает эту проблему - это оператор выбора или оператор вставки?

Answer 1

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

Помимо этого, больше всего выделяется то, что ваш col_date поле создается во время SELECT, что означает, что вы создаете новый / неиндексированный столбец для запроса, который используется в GROUP BY, - таким образом, вы фактически создаете целый новый столбец строка за строкой для 80-метровых строк, а затем Таблица сканирования результатов на 80м строк, чтобы выяснить группировку. Я хотел бы подумать о добавлении нового столбца типа DATE в table1 и постоянном сохранении там ваших преобразованных данных временной метки. После этого ваш GROUP BY сможет работать более оптимально (с надлежащей индексацией для нового столбца DATE). Я бы также изменил table2 на тип DATE и вообще не стал бы конвертировать DATE в STRING - просто сделайте это с датой, если / когда вам нужно будет прочитать ее в другом формате из другой таблицы.

Если вы играете со своим оператором SELECT, я думаю, что если вы удалите col_date из SELECT / GROUP BY, остальная часть запроса должна выполняться довольно быстро, подтверждая вычисленный столбец как проблему. Если нет, я бы поиграл с добавлением / удалением разных столбцов из этого SELECT и поиграл с вашими индексами, чтобы выяснить, какие столбцы (ы) конкретно замедляют запрос. К сожалению, очень сложно для кого-то другого провести тестирование для вас, не создавая точную таблицу из схемы, а затем имея 80-метровые строки образцов данных для тестирования с

ДОПОЛНИТЕЛЬНАЯ ИНФОРМАЦИЯ: Хотя первоначально опубликованный вопрос касался увеличения БД ресурсы, это не совсем правильное решение здесь, на мой взгляд. Если у вас есть запрос, который занимает 15 минут, и он не может быть выполнен, потому что он использует все ресурсы БД, увеличение этих ресурсов на самом деле является просто решением проблемы. Таблица будет по-прежнему увеличиваться, снова потребуются дополнительные ресурсы, это не постоянное исправление.

Любой запрос, который выполняется так долго и использует столько ресурсов, должен быть оптимизирован. Я не вижу ничего о том, что вы пытаетесь сделать, это не должно занять несколько секунд, если данные и индексы оптимизированы, чтобы БД могла выполнять свою работу должным образом - базы данных созданы для такого рода вещей. вверх, и я видел, как более сложные запросы выполняются для гораздо больших наборов данных, не имея проблем, которые у вас возникают (после оптимизации).

ТАКЖЕ, если у вас есть столбец DATE в таблице table1, можно мы предполагаем, что записи никогда не добавляются со старыми временными метками? Если это так, вам даже не нужно каждый раз выполнять запрос по всей таблице, вам действительно нужно только повторять запрос каждый день для новых данных, статистика исторических данных останется постоянной после расчета. Или вы можете разбить запрос на многократный запуск для разных диапазонов дат, снова сократив количество используемых ресурсов - есть много способов оптимизировать этот сценарий.