Работа с алгоритмом MySQL Temp Table для представлений - PullRequest
Новая
       24

Работа с алгоритмом MySQL Temp Table для представлений

5 голосов
/ 28 мая 2010

Было бы хорошо, если бы алгоритм Temp Table был переименован в Unscalable алгоритм. Возможно, тогда это даст больше предупреждений разработчикам, когда они увидят это в определении представления - аналогично, когда в результатах объяснения будет сказано использование временной таблицы. По большей части это просто насмешливый запрос, но на самом деле он может быть катастрофическим для незнающего.

Проблема в том, что если вы сделаете определенные вещи в своем определении представления, оно переключится с алгоритма нормального слияния на безнадежно неэффективный алгоритм временных таблиц. Это не страшно, если данные небольшие. Но это одна из тех вещей, которая убивает вашу производительность по мере роста ваших данных.

Как лучше всего с этим справиться? Это было проблемой, так как представления были реализованы более 5 лет назад, и я не знаю никаких попыток исправить это. Существует ли такая проблема в других популярных системах баз данных?

Прокрутите вниз по ссылке ниже, где обсуждается, когда нельзя использовать алгоритм слияния, чтобы увидеть, что заставляет MySQL вырождаться в использование ужасного алгоритма Temp Table: http://mysql2.mirrors -r-us.net / DOC / RefMan / 5,1 / ен / создать-view.html

Что в этом плохого? Алгоритм временных таблиц работает так:

  1. Запустите представление «КАК ЕСТЬ» в определении представления, не объединяя в нем критерии предложения where.
  2. Сброс полученных данных во временную таблицу.
  3. Фильтрация данных во временной таблице на основе критериев предложения where - здесь тоже нет индексов.

Таким образом, вы можете вообразить, что здесь происходит, когда у вас есть таблица строк на 50 миллионов с определением вида, как - глупый пример, но вы понимаете: 

create view last_order_date as 
    select max(order_date) last_date, username from orders group by username;

Пользователь может написать: 

select * from last_order_date where username = 'joejoe22'

2 часа спустя результат возвращается ...

Так, как лучше всего справиться с этой ситуацией?

1 Ответ

3 голосов
/ 15 апреля 2011

Напишите хранимую процедуру, которая возвращает набор результатов. 

DELIMITER $$

CREATE PROCEDURE DoViewMyData(Param1 INT)
BEGIN
  SELECT 
    field1 as x
    ,field2 as y
    FROM table
    WHERE field1 = Param1;
END$$

DELIMITER ;

Теперь вызовите процедуру, она вернет набор результатов оператора выбора в пределах. 

CALL DoViewMyData(1);

OUTPUT:
+------+-------------------+
| x    | y                 |
+------+-------------------+
| 1    | balabablabla      |
+------+-------------------+

Просто сделай CALL, не делай так SELECT CALL, что не работает.
Вы также можете не использовать CALL внутри другого оператора SELECT.
Вы, конечно, можете поручить хранимой процедуре поместить вывод во временную таблицу, а затем использовать ее в другом SELECT.

Хранимая процедура будет использовать правильные индексы, и ваш оператор выбора уже подготовлен.
Кроме того, вы можете подготовить материал в предыдущих выражениях, что ускорит ваш срочный запрос.

Вы правы, хотя: MySQL Views наверняка сосут

...