Очередной баг в MySQL
Friday, December 25th, 2009
Еще одну прелестную новость подарил сегодняшний день.
В одной из хранимых процедур, после переезда на новый сервер запрос работал невероятно медленно. Космически медленно. Вместо тысяч insert/replace в секунду – один insert за 2-3 минуты. Начал копаться в show innodb status и обнаружил, что каждое текстовое значение принудительно конвертировалось в utf8
SELECT id INTO @vI FROM project.table1 WHERE project.table1.word = NAME_CONST('vD',_utf8'by word here' COLLATE 'utf8_general_ci') LIMIT 1;
Решить проблему удалось с 1й попытки – в начале процедуры поставил
SET NAMES ‘cp1251′ COLLATE ‘cp1251_general_ci’;
и объявил переменную как
DECLARE vD VARCHAR(67) CHARSET CP1251;
Как потом оказалось – достаточно было лишь объявить переменную.
Не сложно, но почему сама по себе операция сравнения project.table1.word с NAME_CONST(‘vD’,_utf8′by word here’ COLLATE ‘utf8_general_ci’)
занимала столько времени.
Чушь какая-то.
В новом проекте всё завязано на базе. Очень большие объемы информации нуждаются в тщательной проектировке и отладке. Впервые возникла необходимость в средстве визуальной проектировки БД. Выбор сделал в пользу dbForge Studio и, думаю, оказался прав. Софт писали люди, которые определенно им будут пользуются сами. Очень качественный продукт, всё продумано, стандартная привязка клавиш. Никаких сюрпризов – сел и начал работать. Руки сами знаю, что и где спрятано. Что особенно понравилось, так это отладка хранимых процедур, да и само создание процедур реализовано очень удобно. Короче – супер!
Loading ...