Короче говоря, нецелесообразно загружать ресурсы на общем сервере.
В принципе, если вы уделяете достаточно времени другим процессам, это неплохо. Однако пикирование процессора, о котором вы говорите, - это плохо и плохо для других пользователей системы. У вас должен быть механизм yield в главном цикле (например, usleep(100)
) и запустить команду с большим nice
числом, например 19.
Кроме того, похоже, что вы выполняете отдельные вызовы вставки / обновления / и т. Д. В сценарии пакетной обработки. С mysql намного лучше делать пакетные вставки, когда это возможно (очень быстро по сравнению с отдельными). Однако, в зависимости от того, как вы это сделаете, это может быть компромиссом оперативной памяти с временем ЦП (например, если вы сохраняете все значения вставки в строке до тех пор, пока они не будут готовы для вставки с помощью одного оператора вставки, то это может добавить до много оперативки). Если проблема с ОЗУ, вы всегда можете создать временный файл SQL, а затем импортировать все это в конце процесса.
Пакетная вставка выглядит примерно так (для таблицы с двумя столбцами varchar):
INSERT INTO `mytable` VALUES ('Field 1-Row 1', 'Field 2-Row 1'), ('Field 1-Row 2', 'Field 2-Row 2');
Это вставит две строки одновременно за долю времени.
Но опять же, основываясь на том, что вы описываете как цель сценария, вы, вероятно, не делаете много вставок для начала. Но, может быть, вы все еще можете собрать все (или многие) из ваших обновлений / вставок / удалений в БД в финальный скрипт, вызываемый в конце?
Кроме того, если вы уверены, что можете сохранять внешние ключи в правильном порядке при импорте, отключение проверки внешних ключей также может значительно повысить скорость.
Все другие возможные предложения будут основаны на конкретной оптимизации вашего кода и схемы БД (оптимизация циклов, поисков, индексов и т. Д.).
То, что я категорически намекаю , заключается в том, что вы можете сделать что-то подобное в разделяемом хостинге, не перегружая ресурсы, но ваша структура БД, операторы SQL и алгоритмы (циклы и т. Д.) Должны быть высоко оптимизированы. , Если вы сделаете это, дополнительным преимуществом будет то, что ваш процесс также завершится очень быстро. Существует распространенное заблуждение, что php + mysql = slow / cpu hog, но в 99% случаев это проблема программирования или дизайна БД. Они должны легко справиться с таким количеством записей.