Производительность хранимых процедур нормализации MySQL

Question

Я написал хранимую процедуру в MySQL, чтобы принимать значения в настоящее время в таблице и "нормализовать" их.Это означает, что для каждого значения, переданного хранимой процедуре, он проверяет, находится ли значение уже в таблице.Если это так, то он хранит идентификатор этой строки в переменной.Если значение отсутствует в таблице, в нем хранится идентификатор вновь вставленного значения.Затем хранимая процедура берет идентификаторы и вставляет их в таблицу, которая эквивалентна исходной ненормализованной таблице, но эта таблица полностью нормализована и состоит в основном из внешних ключей.

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

INSERT INTO TableA 
 (first_value) 
VALUES 
 (argument_from_sp) ON DUPLICATE KEY UPDATE id=LAST_INSERT_ID(id);

SET @TableAId = LAST_INSERT_ID();

«ON DUPLICATE KEY UPDATE» - это что-то вроде хака, потому что на дублирующем ключе я не хочу ничего обновлять, а просто возвращаю значение idстрока.Если вы пропустите этот шаг, функция LAST_INSERT_ID () возвращает неправильное значение, когда вы пытаетесь выполнить инструкцию «SET ...».

Кто-нибудь знает, как лучше сделать это в MySQL??

Answer 1

Я вернулся и создал функцию для обработки этого случая:

CREATE DEFINER=`root`@`%` FUNCTION `value_update`(inValue VARCHAR(255)) RETURNS int(11)
BEGIN
        DECLARE outId INT;
        SELECT valueId INTO outId FROM ValuesTable WHERE value = inValue;

        IF outId IS NULL THEN
                INSERT INTO ValuesTable (value) VALUES (inValue);
                SELECT LAST_INSERT_ID() INTO outId;
        END IF;

        RETURN outId;
END

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

Answer 2

Если у вас уже есть уникальный идентификатор, есть ли необходимость в автоинкрементном первичном ключе?