Подтвердить что ты не робот

MySQL: Почему заказ по идентификатору работает намного медленнее, чем Order by other Columns?

Я использую MySQL версии 5.5.14 для запуска следующего запроса QUERY 1 из таблицы из 5 миллионов строк:

SELECT P.ID, P.Type, P.Name, P.cty
     , X(P.latlng) as 'lat', Y(P.latlng) as 'lng'
     , P.cur, P.ak, P.tn, P.St, P.Tm, P.flA, P.ldA, P.flN
     , P.lv, P.bd, P.bt, P.nb
     , P.ak * E.usD as 'usP' 
FROM PIG P 
  INNER JOIN EEL E 
    ON E.cur = P.cur 
WHERE act='1' 
  AND flA >= '1615' 
  AND ldA >= '0' 
  AND yr >= (YEAR(NOW()) - 100) 
  AND lv >= '0' 
  AND bd >= '3' 
  AND bt >= '2' 
  AND nb <= '5' 
  AND cDate >= NOW() 
  AND MBRContains(LineString( Point(39.9097, -2.1973)
                            , Point(65.5130, 41.7480)
                            ), latlng) 
  AND Type = 'g' 
  AND tn = 'l' 
  AND St + Tm - YEAR(NOW()) >= '30' 
HAVING usP BETWEEN 300/2 AND 300 
ORDER BY ak
LIMIT 100;

Используя Index (Тип, tn, act, flA), я могу получить результаты в пределах 800 мс. В QUERY 2 я изменил предложение ORDER BY на lv, я также смог получить результаты в течение аналогичных таймингов. В QUERY 3 я изменил предложение ORDER BY на ID, и время запроса резко снизилось до полного 20s в среднем по 10 проб.

Запуск инструкции EXPLAIN SELECT создает точно такой же план выполнения запросов:

*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: P
         type: range
possible_keys: Index
          key: Index
      key_len: 6
          ref: NULL
         rows: 132478
        Extra: Using where; Using filesort
*************************** 2. row ***************************
           id: 1
  select_type: SIMPLE
        table: E
         type: eq_ref
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 3
          ref: BS.P.cur
         rows: 1
        Extra: 

Мой вопрос: почему упорядочение по ID в QUERY 3 работает так медленно по сравнению с остальными?

Определение частичной таблицы таково:

CREATE TABLE `PIG` (
  `ID` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `lv` smallint(3) unsigned NOT NULL DEFAULT '0',
  `ak` int(10) unsigned NOT NULL DEFAULT '0',

  PRIMARY KEY (`ID`),
  KEY `id_ca` (`cty`,`ak`),
  KEY `Index` (`Type`, `tn`, `act`, `flA`),
) ENGINE=MyISAM AUTO_INCREMENT=5000001 DEFAULT CHARSET=latin1

CREATE TABLE `EEL` (
  `cur` char(3) NOT NULL,
  `usD` decimal(11,10) NOT NULL,
  PRIMARY KEY (`cur`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1

ОБНОВЛЕНИЕ: после тщательного тестирования различных параметров ORDER BY я подтвердил, что столбец идентификатора, который является основным ключом, является единственным, вызывающим медленное время запроса.

4b9b3361

Ответ 1

Из документации MySQL на http://dev.mysql.com/doc/refman/5.6/en/order-by-optimization.html

В некоторых случаях MySQL не может использовать индексы для разрешения ORDER BY, хотя он по-прежнему использует индексы для поиска строк, которые соответствуют предложению WHERE. Эти случаи включают следующее:

.,.

Ключ, используемый для извлечения строк, не совпадает с ключом, используемым в ORDER BY:

`SELECT * FROM t1 WHERE key2=constant ORDER BY key1;`

Это, вероятно, не поможет, но что произойдет, если вы добавите AND ID > 0 в предложение WHERE? Из-за этого MySQL может использовать первичный ключ для сортировки? Пожалуй, стоит попробовать.

(Кажется странным, что упорядочение с помощью ak эффективно, так как ak даже не имеет индекса, но это может быть связано с меньшим количеством значений для ak?)

Ответ 2

вы можете использовать force index(PRIMARY) попробуйте, и вы увидите в объяснении, что mysql теперь будет использовать индекс первичного ключа, когда "order by"

Ответ 3

Если условие в предложении WHERE отличается от условия в ORDER BY или оно не является частью составного индекса, то сортировка не выполняется в модуле хранения, а скорее на уровне сервера MySQL, который намного медленнее, Короче говоря, вы должны перестроить свои индексы, чтобы удовлетворить как фильтрацию строк, так и сортировку.