Медленные MySQL InnoDB Вставки и Обновления - PullRequest
Новая
       4

Медленные MySQL InnoDB Вставки и Обновления

3 голосов
/ 10 февраля 2012

Я использую magento и у меня много медлительности на сайте.На сервере очень и очень низкая нагрузка.Я проверил, что процессор, дисковый ввод-вывод и память всегда доступны менее чем на 30%.Кэширование APC включено - я использую новую реликвию для мониторинга сервера, и проблема очень четко вставлена ​​/ обновлена.

Я выделил медлительность для всех операторов вставки и обновления.ВЫБРАТЬ быстро.Очень простая вставка / обновление таблиц занимает 2-3 секунды, независимо от того, запускается ли это из моего приложения или из командной строки mysql.

Пример: 

UPDATE `index_process` SET `status` = 'working', `started_at` = '2012-02-10 19:08:31' WHERE (process_id='8');

В этой таблице 9 строк, первичный ключ,и 1 индекс на нем.

Замедление происходит со всеми вставками / обновлениями.Я запустил mysqltuner и все выглядит хорошо.Кроме того, innodb_flush_log_at_trx_commit изменилось на 2.

Активность на этом сервере очень мала - это dv-бокс с 1 ГБ оперативной памяти.У меня есть установки magento, которые работают в 100 раз лучше при 5-кратной загрузке на аналогичной установке.

Я начал регистрировать все запросы в течение 2 секунд, и, похоже, все вставки и полнотекстовый поиск.

Любойесть предложения?

Вот структура таблицы: 

CREATE TABLE IF NOT EXISTS `index_process` (  
  `process_id` int(10) unsigned NOT NULL AUTO_INCREMENT,  
  `indexer_code` varchar(32) NOT NULL,  
   `status` enum('pending','working','require_reindex') NOT NULL DEFAULT 'pending',  
  `started_at` datetime DEFAULT NULL,  
  `ended_at` datetime DEFAULT NULL,  
  `mode` enum('real_time','manual') NOT NULL DEFAULT 'real_time',  
  PRIMARY KEY (`process_id`),  
  UNIQUE KEY `IDX_CODE` (`indexer_code`)  
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 AUTO_INCREMENT=10 ;

1 Ответ

0 голосов
/ 14 июня 2013

Первое: (process_id='8') - '8' - это char/varchar, а не int, поэтому mysql сначала преобразует значение.

В моей системе у меня было много времени (больше одной секунды) для обновления users.last_active_time.

Причина заключалась в том, что мне нужно было выполнить несколько запросов. Как я присоединился к ним для таблицы пользователей. Это привело к блокировке таблицы для чтения. Блокировка смерти от SELECT.

Я переписал запрос от: ПРИСОЕДИНЯЙТЕСЬ к: подзапросам и пропущенной проблеме.

...