Производительность хранимых процедур 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 KEY UPDATE DUPLICATE» немного рубить, из-за того, что на дубликат ключа я не хочу, чтобы обновить что-нибудь, а просто возвращает значение идентификатора строки. Если вы пропустите этот шаг, функция 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

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