Лучший подход для проверки и вставки записей

Почему бы не обновить сервер MySQL до версии 5.0 (или 5.1), а затем использовать триггер, чтобы он всегда был актуальным (нет необходимости в ежемесячном скрипте)?

DELIMITER //
CREATE TRIGGER insert_into_a AFTER INSERT ON source_table
FOR EACH ROW 
BEGIN
    IF NEW.foo > 1 THEN
        SELECT id AS @testvar FROM a WHERE a.id = NEW.id;
        IF @testvar != NEW.id THEN
            INSERT INTO a (col1, col2) VALUES (NEW.col1, NEW.col2);
            INSERT INTO b (col1, col2) VALUES (NEW.col1, NEW.col2);
        END IF
    END IF
END //
DELIMITER ;

Затем вы даже можете настроить триггеры обновления и удаления, чтобы таблицы всегда синхронизировались (если исходная таблица col1 обновляется, она автоматически распространяется на a и b)...

Вот мои мысли о вашем служебном скрипте ...

1) В любом случае это просто хорошая практика, я бы сделал это, несмотря ни на что.

2) Может значительно сэкономить время выполнения. Если вы можете решить проблему в прямом SQL без использования итераций в C-программе, это может сэкономить изрядное количество времени. Сначала вам нужно профилировать его, чтобы убедиться, что он действительно работает в тестовой среде.

3) ЗАГРУЗИТЬ ДАННЫЕ INFILE - это тактика, которую нужно использовать при вставке большого количества данных. Если у вас есть много записей для вставки (я бы написал запрос, чтобы провести анализ, чтобы выяснить, сколько записей вам нужно будет вставить в таблицу B), то, возможно, вам стоит загрузить их таким образом.

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

Хотя ... почему вообще не все записи в таблице B? Вы не упомянули, как работает обработка, но я думаю, было бы полезно обеспечить (в вашем приложении), чтобы записи попадали туда без вмешательства вашего служебного сценария. Конечно, вы понимаете свою ситуацию лучше, чем я, поэтому игнорируйте этот абзац, если он не соответствует действительности. По опыту я знаю, что существует множество причин, по которым должны существовать сценарии очистки служебных программ.

РЕДАКТИРОВАТЬ: После прочтения отредактированного сообщения ваша проблемная область изменилась: у вас есть набор записей в (доступном для поиска?) Плоском файле, который вам нужно загрузить в базу данных на основе определенных критериев.Я думаю, что уловка, чтобы сделать это как можно быстрее, состоит в том, чтобы определить, где приложение C на самом деле является самым медленным и тратит больше всего времени на вращение своих пресловутых колес:

• Если оно читает с диска, вы застряли, вы можете » Ничего не делайте с этим, если только вы не получите более быстрый диск.
• Если он выполняет операцию вставки SQL-запроса, вы можете попробовать его оптимизировать, но вы выполняете сравнение двух баз данных (плоского файла и базы данных MySQL).

Быстрая мысль: выполняя ЗАГРУЗКУ Массовая вставка DATA INFILE для очень быстрого заполнения временной таблицы (возможно, даже таблицы в памяти, если MySQL позволяет это), а затем выполнение INSERT IF NOT EXISTS может быть быстрее, чем то, что вы делаете сейчас.

Короче говоря, проведите профилирование и выясните, где замедление. Помимо этого, поговорите с опытным администратором баз данных, чтобы узнать, как это сделать правильно.