Comments 19
Таблицы типа InnoDB размещаются в едином табличном пространстве. При добавлении индексов дисковое пространство, отведенное под табличное пространство, будет исчерпано быстрее.
Вам рассказать про опцию innodb_table_per_file? :]
в ходе выполнения запроса используются вычисленные на предыдущих шагах и занесенные в пользовательские переменные значения.
Если такое происходит надо использовать хранимые процедуры, а никак не пользовательские переменные.
Про innodb_table_per_file почитаю, спасибо.
Насчет хранимых процедур — ими тоже можно, но.
Насчет хранимых процедур — ими тоже можно, но.
>> Вам рассказать про опцию innodb_table_per_file? :]
А с индексами что делать в этом случае?
А с индексами что делать в этом случае?
В T-SQL переменные в запросе для ваших целей используются редко, там есть замечательнейшая штука ROW_NUMBER.
вообще-то кросс-постить тут нельзя: webew.ru/articles/3923.webew
> Сложная переносимость на другие СУБД
> Поведение пользовательских переменных будет зависеть от порядка выполнения сложного запроса
Хранимая процедура с курсором + запоминание последних данных на уровне приложения?
> Поведение пользовательских переменных будет зависеть от порядка выполнения сложного запроса
Хранимая процедура с курсором + запоминание последних данных на уровне приложения?
У вас уже есть подготовленные данные — можете заодно пргогнать тесты для такого варианта реляционного запроса для первой задачи?
SELECT MAX((SELECT dst FROM t t2 WHERE t2.t>t1.t ORDER BY t2.t LIMIT 1) - t1.dst) FROM t t1;
Я конечно дико извиняюсь перед автором, ибо статья хорошая, но не могу не добавить 5 копеек, для во избежании граблей:
— прежде чем давать такие советы — попробуйте отмасштабировать ваши запросы с сессионными переменными на несколько пользователей, в вашей статье вы привели примеры неоптимально выбранных решений для конкретной реализации имеющихся у вас задач, да запросы работают быстрее, но вы все равно сканируете все данные и вам просто несказанно везет, что все ваши строки сканируемых таблиц помешаются в кэш, в промышленной реализации сканирование 500000 строк просто недопустимо, решайте задачу не костылями в виде сессионных переменных, а изменением архитектуры
— надеюсь вы читали статью? советую на всякий случай ознакомится, ибо в документации по MySQL четко сказано, что работа с сессионными переменными в резалтсете содержащим более одной записи — неопределена, т.е. вы не можете на 100% быть уверенным что завтра ваши запросы не перестанут работать
— я сам очень активно использую сессионные переменных, так как раньше работал с Oracle, и мне очень не хватет его аналитических функций, а сессинные переменные позволяют организовать хоть какую-то их замену, вы даже не представляете СКОЛЬКО раз я наталкивался на то, что сегодня сложный запрос с сессионными переменными возвращает верные данные, а на завтра данные вдруг получаются иными — и не спасают ни явные многократные сортировкив подзапросах ни указание порядка соединения таблиц — ничего.
Посему сугубо ИМХО, тема интересная, но слепо полагаться на неё к примеру в финансовой отчетности — я бы посоветовал только врагу, а совет используйте сессионные переменные вместо индексов, потому что они занимают место на диске и тормозят вставку, я вообще считаю неадекватным, считайте нужные агрегаты на лету — с использованием буферных таблиц в фоне и сохраняйте только их.
Так же для понимая всей мощи данного инструмента советую читателям посмотреть тут показано как делать не просто тривиальные запросы, но и такие вещи как оконные функции с партиционированием, это позволит вам лишний раз не пользоваться подзапросами копируя тысячи строк во временные таблицы.
— прежде чем давать такие советы — попробуйте отмасштабировать ваши запросы с сессионными переменными на несколько пользователей, в вашей статье вы привели примеры неоптимально выбранных решений для конкретной реализации имеющихся у вас задач, да запросы работают быстрее, но вы все равно сканируете все данные и вам просто несказанно везет, что все ваши строки сканируемых таблиц помешаются в кэш, в промышленной реализации сканирование 500000 строк просто недопустимо, решайте задачу не костылями в виде сессионных переменных, а изменением архитектуры
— надеюсь вы читали статью? советую на всякий случай ознакомится, ибо в документации по MySQL четко сказано, что работа с сессионными переменными в резалтсете содержащим более одной записи — неопределена, т.е. вы не можете на 100% быть уверенным что завтра ваши запросы не перестанут работать
— я сам очень активно использую сессионные переменных, так как раньше работал с Oracle, и мне очень не хватет его аналитических функций, а сессинные переменные позволяют организовать хоть какую-то их замену, вы даже не представляете СКОЛЬКО раз я наталкивался на то, что сегодня сложный запрос с сессионными переменными возвращает верные данные, а на завтра данные вдруг получаются иными — и не спасают ни явные многократные сортировкив подзапросах ни указание порядка соединения таблиц — ничего.
Посему сугубо ИМХО, тема интересная, но слепо полагаться на неё к примеру в финансовой отчетности — я бы посоветовал только врагу, а совет используйте сессионные переменные вместо индексов, потому что они занимают место на диске и тормозят вставку, я вообще считаю неадекватным, считайте нужные агрегаты на лету — с использованием буферных таблиц в фоне и сохраняйте только их.
Так же для понимая всей мощи данного инструмента советую читателям посмотреть тут показано как делать не просто тривиальные запросы, но и такие вещи как оконные функции с партиционированием, это позволит вам лишний раз не пользоваться подзапросами копируя тысячи строк во временные таблицы.
Одному только мне некомфортно читать выражение SELECT t, @v prev, @v:=d d вместо SELECT t, @v AS prev, @v:=d AS d?
Sign up to leave a comment.
Оптимизация запросов MySQL с использованием пользовательских переменных