Как убрать ограничение на количество запросов к MySQL или оптимизировать работу скрипта?

Question

[Chernichko]

есть скрипт, которых обрабатывает csv файл по строчно. В процессе обработки он вносит изменения в 3 разные таблицы базы.
Раньше все хорошо работало и обновлялось. Теперь в файле почти 100000 записей, а в скрипте по 7-10 запросов у каждой строки данных и база не обновляется.

слишком много запросов.
Как решить проблему?

Answer 1

[Макс]

не изобретайте "валасипед" - качните CSV встроенной функцией во временную таблицу, потом уже из нее рапихайте данные в три.
у меня так логи импортируются. 2 гига, несколько миллионов строк - 5-6 минут.

Comments

[Chernichko]

чем это отличается от "велосипедного" считывания файла? нужно сначала отправить все во временную таблицу, потом select'нуть данные таблицы, потом я беру сроку проверяю наличие нужного айди, если айди есть обновляю инфу 1й таблицы где нужный айди, есди нет, добавляю туда запись, возвращаю айди записи....
или я что то не понимаю? О.о
там будет столько же запросов, потому что некоторые запросы выполняются после проверки на наличие нужной инфы.

[vovik0134]

Chernichko: Используйте LOAD DATA INFILE ... Этот инструмент специально разработан для массовой загрузки данных. Подробнее о преимуществах над insert можно почитать здесь: dba.stackexchange.com/questions/16809/why-is-load-...

[Макс]

Chernichko: 1. потому что загрузится это на пару порядков быстрее.
2. потому что UPDATE таблицы данными можно сделать одним запросом. 1 запрос - 1 план исполнения.
3. потому что ничего не мешает временную табличку сделать в движке MEMORY.
в общем - аргументов ЗА навалом.
и уж точно Ваши 100 000 строк загрузятся. И 1 000 000, и 10 000 000
я вот только-что импортнул файл логов прокси за вчера. чуть меньше 5 млн. строк. загрузка, чистка от "лишнего", группировка - все вместе что-то около 12 минут. Далеко не самый быстрый комп, временная таблица на винте (памяти не хватает).

[Chernichko]

Макс: спасибо) только вот вопрос: если я в текущей Бд mysql буду каждый раз создавать, а потом удалять временную таблицу, не случится ли какой нибудь нежелательной нагрузки, которая может сделать беду?)
я спрашиваю, потому что уже как то наделала таких бед. для уверенности, так сказать)))

[Макс]

Chernichko: загрузка данных через временную таблицу - вполне распространенный процесс. Можно сказать устоявшаяся практика. Единственный известный мне тонкий момент - не стоит включать при этом полный лог. В остальном все работает отлично.

Answer 2

[lyeskin]

Обновлять батчем, а не по одной.

Comments

[Chernichko]

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

Answer 3

[EvgeniyKonstantinov]

В my.cnf (/etc/my.cnf или /etc/mysql/my.cnf - зависит от дистрибутива):

max_user_connections=0

Установка значения в ноль снимает ограничение.

Кроме того можно выполнить следующий SQL от рута (пользователя подставить своего, цифры увеличить по необходимости):

GRANT ALL ON *.* TO 'username'@'localhost'
WITH MAX_QUERIES_PER_HOUR 1000
MAX_UPDATES_PER_HOUR 1000
MAX_CONNECTIONS_PER_HOUR 1000
MAX_USER_CONNECTIONS 1000;

Answer 4

[AlikDex]

пакетно обрабатывай, тыщи по 2-3 записи за 1 заход.