Форум пользователей MySQL

druri · 11.12.2014 22:08:03

Здравствуйте. Помогите советом пожалуйста

Есть таблицы

CREATE TABLE IF NOT EXISTS `objects` (

  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,

  /* ещё 30 полей */

  PRIMARY KEY (`id`),

  /* ещё индексы */

) ENGINE=MyISAM  DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=15680 ;

CREATE TABLE IF NOT EXISTS `objects_files` (

  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,

  `object` int(10) unsigned NOT NULL,

  `rank` tinyint(1) unsigned NOT NULL DEFAULT '0',

  `type` varchar(50) COLLATE utf8_unicode_ci DEFAULT NULL,

  /* ещё 10 полей */

  PRIMARY KEY (`id`),

  KEY `object` (`object`),

  KEY `type` (`type`),

  KEY `parent` (`parent`),

  KEY `rank` (`rank`)

) ENGINE=MyISAM  DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=1593577 ;

идет выборка в таблице objects ,которая джоинит таблицу файлов по полю object.Сам по себе выборка вопросов не вызывает пока

при добавлении новых файлов бывают запросы вида

UPDATE objects_files set rank=`n` where `type`='image' and (`id`='m' or `parent`='m')

иногда этот запрос может выполняться по 70 секунд.Slow queries log показывает,что при этом апдейте row examined все 700 тыс. строк.При этом таблица objects попадает под лок и все выборки ждут. Переменные и статус сервера,которые может быть вам скажут больше чем мне :

Table_locks_immediate 89.2 M
Table_locks_waited 698.1 k
Qcache_free_memory 12.3 M

query cache limit 8,388,608
query cache size 67,108,864

sql low priority updates OFF

Скажите пожалуйста,куда копать? К сожалению потерял статью,но где-то тут же ранее читал,что это может быть из-за проблем с файловой системой.Если это так,то каким утилитами и какие параметры ввода-вывода (или ещё чего) смотреть,чтобы действительно можно было сказать - вот тут зарыта собака. Поделитесь пожалуйста опытом решения подобных проблем или предоставьте ссылки на материалы,которые помогут разобраться.Заранее благодарен.

rgbeast · 17.12.2014 12:37:10

Создайте индекс KEY(parent,type) и разделите на два запроса, чтобы исключить OR.

klow · 17.12.2014 12:55:59

rgbeast написал:
разделите на два запроса, чтобы исключить OR.

Подробнее, пожалуйста. Индексы не работают если используется OR?

deadka · 17.12.2014 12:58:43

Могут и не работать, тут explain запроса смотреть надо. А в чем проблема разделить на два запроса?

klow · 17.12.2014 13:01:55

deadka написал:
Могут и не работать, тут explain запроса смотреть надо.

Можете сообщить в каких случаях могут не работать индексы если используется OR?

deadka написал:
А в чем проблема разделить на два запроса?

Любые действия должны быть обоснованы, логичны, а не потому, что это захотелось моей задней ноге.

druri · 17.12.2014 13:10:38

rgbeast написал:
Создайте индекс KEY(parent,type) и разделите на два запроса, чтобы исключить OR.

Спасибо,думаю ваше простое решение поможет.

EXPLAIN SELECT url
FROM `objects_files`
WHERE `type` = 'image'
AND (
`id` = 'm'
OR `parent` = 'm'
)

показывает type ALL , key NULL

Если же убрать id или parent , то EXPLAIN показывает,что выбирается либо primary индекс по id,либо индекс по parent.

Надо внимательнее читать доки...

rgbeast · 17.12.2014 13:13:31

Добавьте индекс и приведите результат EXPLAIN - это поможет обосновать удаление OR.

Индекс - аналог словаря, отсортированного определенным образом. У Вас OR по разным полям, то есть логически сначала нужно посмотреть в одном словаре, а затем в другом. Два запроса это выполнят оптимальным образом. Обычно MySQL использует только один индекс (использование нескольких индексов реализовано только в нескольких частных алгоритмах), поэтому он может просто махнуть рукой и начать перебирать все записи.

P.S. после написания увидел, что вы привели EXPLAIN и все именно так

Форум пользователей MySQL

#1 11.12.2014 22:08:03

Долгий UPDATE

#2 17.12.2014 12:37:10

Re: Долгий UPDATE

#3 17.12.2014 12:55:59

Re: Долгий UPDATE

rgbeast написал:

#4 17.12.2014 12:58:43

Re: Долгий UPDATE

#5 17.12.2014 13:01:55

Re: Долгий UPDATE

deadka написал:

deadka написал:

#6 17.12.2014 13:10:38

Re: Долгий UPDATE

rgbeast написал:

#7 17.12.2014 13:13:31

Re: Долгий UPDATE

Board footer