|
Задавайте вопросы, мы ответим
Вы не зашли.
Страниц: 1
Помогите разобраться с такой аномалью:
Есть достаточно сложный запрос. На первом сервере (менее мощном, диски SATA, програмный RAID1) он выполняется примерно за 2 секунды максимум. На втором, новом, более мощном (SAS диски в аппартном RAID10) он же на этих же базах выполняется более 6 секунд. Смотрю profile на втором, наибольшее время это "Sending data" 5,5 сек. (уже стоит limit 2) при этом еще создается временная таблица. На первом сервере в profile нет упоминания временной таблицы и sending data 0.0005960. my.cnf копировал с первого на второй. Отличия только железе, файловой системе, путям к базам, и версии: на первом версия 5.1.57, на втором (новом) 5.1.58.
Если провожу тесты sysbench для mysql, то второй сервер выигрывает в несколько раз.
Неактивен
Нужно проверить сначала зависимость от версии - где-нибудь на одном сервере поставить обе версии mysql и проверить.
Неактивен
Сначала на новом сервере не обновил порты и поставил 5.1.56, потом заметил глюк, заметил разность версий, обновил порты и переставил MySQL, стало 5.1.58. Есть еще теория, что на старом сервере MySQL был скомпилирован с какими то опциями. Не подскажете как можно посмотреть эти опции?
Вот еще отличия (только отличия) в explain на двух разных серверах:
На старом (где быстро работает):
1 PRIMARY contractor const PRIMARY,cst_id PRIMARY 4 const 1 Using index
1 PRIMARY stock_managers eq_ref PRIMARY PRIMARY 4 aXXX.customers.cst_stm_id 1 Using where
1 PRIMARY documents range PRIMARY,dcm_cst_id,dcm_contractor_cst_id,dcm_registered,dcm_datetime,dcm_id dcm_datetime 4 7986 Using where
На новом (где тормозит):
1 PRIMARY contractor const PRIMARY,cst_id PRIMARY 4 const 1 Using index; Using temporary; Using filesort
1 PRIMARY documents range PRIMARY,dcm_cst_id,dcm_contractor_cst_id,dcm_registered,dcm_datetime,dcm_id dcm_datetime 4 7938 Using where; Using join buffer
1 PRIMARY stock_managers ALL PRIMARY 23
Отредактированно vova-c (26.10.2011 11:05:28)
Неактивен
Может чудо, может нет. Обновил базу на новом со старого (старый сервак рабочий, онлайн). И тормоза пропали. Т.е. получается, что за некоторое время пользователем над базой были произведены действия, которые изменили profile и explain одного и того же запроса. По количеству строк в таблицах изменения в десятки штук (т.е. в пределах пары процентов).
Неактивен
Видно, что изменился порядок JOIN. Может быть изменилась статистика, на основании которой оптимизатор выбирает план исполнения запроса. Попробуйте использовать OPTIMIZE TABLE для обновления статистики индексов, а также STRAIGHT_JOIN для фиксации порядка JOIN. Убедитесь, что индексы идентичны в двух базах.
Неактивен
Страниц: 1
