оптимизация процедуры MySQL

[IliaIT]

понадобилось создать процедуру на сервере для более быстрого выполнения алгоритма обновления и добавления. прошу посмотреть код на предмет его оптимальности вообще правильности. код работает. из дельфи-программы процедура эта выполняется.

-- --------------------------------------------------------------------------------
-- Routine DDL
-- Note: comments before and after the routine body will not be stored by the server
-- --------------------------------------------------------------------------------
DELIMITER $$

CREATE DEFINER=`Ap_date`@`192.168.0.11` PROCEDURE `update_A_par`(IN S_base varchar(30),IN S1 float(12,2), IN s2 varchar(20),IN s3 varchar(10), IN S4 int(3),IN S5 int(3), IN S6 int(3), IN S9 int(1), in S2_d date,in S2_t time)
BEGIN
    declare ResString int;
    SET ResString =(SELECT COUNT(lab)  FROM `ur`.`par` 
    WHERE kod=S4 and Unitnum=S5 and lab=S3 and id_param=s6 and time<>S2);
    IF ResString > 0 then
        UPDATE ur.par SET val= s1, time=s2, metka=s9 
        WHERE lab=s3 and kod=s4 and unitnum=s5 AND id_param=s6;
        SET @Res_base1 =CONCAT("INSERT INTO `ah`.",S_base," (`kod`, `unitnum`, `id_param`, `data`,`time`, `val`) VALUES (",s4,",",s5,",",s6,",'",S2_d,"','",S2_t,"', ",S1,")");
        PREPARE ins_pas FROM @Res_base1;
        EXECUTE ins_pas ;
    END IF;
END

[Аватар]

С MySQL не работаю, поэтому не помогу. Но есть вопросы на засыпку.

1. Во WHERE SELECT-а есть time<>S2, а во WHERE UPDATE нет этого условия. Почему? UPDATE охватит больший диапазон записей, чем SELECT.
2. Может лучше вообще без SELECT-а UPDATE сделать? Наверно есть после этого возможность узнать (может какая-то @@-переменная по аналогии с MSSQL) - а были ли вообще обновлены записи. И если были - выполнить INSERT
3. Почему для UPDATE PREPARE не используетя, а для INSERT-а используется? Есть какие-то особенности? Хотя снимаю этот вопрос, особенность увидел
4. И как насчет индексов по полям упомянутых во WHERE?

[IliaIT]

логика запросов такая, по полям kod, Unitnum, lab, id_param определяется запись так как их комбинация уникальна. далее проверяется изменился ли параметр со времени предыдущего сравнения (time<>S2).
если изменился то обновляем у записи val, time, metka (значение время и метку), а так же добавляем в архивную базу значение параметра.

1. добавлю тогда в апдейт "and time<>S2" вроде не сыграет это погоды ни для времени исполнения запроса ни для увеличения охвата изменений.
2. вот тут не знаю, так как разбираться начал недавно и по книжке, может даже и функция какая есть в MySQL, буду искать. просто подразумевается что часть данных в любом случае меняется в базе и задача процедуры определить есть ли изменения.
3. вообще это задумано из за того что необходимо указывать имя архивной базы потому и INSERT в 3 строки сделан. по другому не нашёл, а этот алгоритм был в книжке как пример.
4. kod, unitnum, id_param (составной индекс), хотя это в данный момент наверное не критично так как таблица подразумевает небольшое количество записей где то не более 3 000

и ещё повторюсь, смысл всей этой процедуры был задуман для оптимизации в программе самопальной на дельфи(что бы было в 1 запрос для 1 записи , ибо это самое долгое место для программы обновления.) которая собирает данные из различных таблиц и складывает в одну кучу записи и создаёт архив для удобного анализа параметров.