Производительность хранимой процедуры MySQL Normalization
Я записал хранимую процедуру в MySQL, чтобы в настоящее время принимать значения в таблице и "Нормализовать" их. Это означает, что для каждого значения передал хранимой процедуре, оно проверяет, является ли значение уже в таблице. Если это, то это хранит идентификатор той строки в переменной. Если значение не находится в таблице, оно хранит идентификатор недавно вставленного значения. Хранимая процедура затем берет идентификатор и вставляет их в таблицу, которая является переводной исходной de-normailized таблице, но эта таблица полностью нормализована и состоит из главным образом внешних ключей.
Моя проблема с этим дизайном состоит в том, что хранимая процедура берет приблизительно приблизительно 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();
"НА ДУБЛИРУЮЩЕМСЯ КЛЮЧЕВОМ ОБНОВЛЕНИИ" определенный взлом, вследствие того, что на дублирующемся ключе я не хочу обновлять что-либо, но скорее просто возвращать значение идентификатора строки. Если Вы пропускаете этот шаг, хотя, LAST_INSERT_ID () функция возвращает неправильное значение, когда Вы пытаетесь выполнить оператор "SET...".
Кто-либо знает о лучшем способе сделать это в MySQL?
2 ответа
Я вернулся назад и создал функцию для обработки этого случая:
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). Кроме того, после сравнительного анализа всех частей моего приложения я обнаружил, что проблемы с производительностью, которые вызывала эта функция, были лишь незначительной частью общего узкого места в производительности.
Если у вас уже есть уникальный идентификатор, нужен ли первичный ключ с автоинкрементом?