если это имеет значение (в чем я сомневаюсь) то разговор пойдет про mySQL....
Вобщем пытался я оптимизировать один запросец (вернее их там несколько, но это не важно) и подумалось мне что LIMIT на скорость его выполнения никак не влияет, во всяком случае если в запросе присутствует ORDER BY, а влияет только на обьём памяти занимаемый результатом....
Прав я или нет?
Вопрос с одной стороны вроде простой, но с другой не понятно где искать ответ, во всяком случае в моей книжке про это ничего не сказано....
И еще вопрос — на сколько гадко для перформанса использование LIKE "some_text%" на MEDIUMTEXT поле?
У меня есть выбор — либо делать LIKE "some_text%", либо добавлять в запрос еще один LEFT JOIN (причем на ту же таблицу что стоит во FROM). Что менее гадко?
Здравствуйте, BugMan, Вы писали:
BM>если это имеет значение (в чем я сомневаюсь) то разговор пойдет про mySQL....
BM>Вобщем пытался я оптимизировать один запросец (вернее их там несколько, но это не важно) и подумалось мне что LIMIT на скорость его выполнения никак не влияет, во всяком случае если в запросе присутствует ORDER BY, а влияет только на обьём памяти занимаемый результатом....
BM>Прав я или нет?
BM>Вопрос с одной стороны вроде простой, но с другой не понятно где искать ответ, во всяком случае в моей книжке про это ничего не сказано....
если нет в книжке, ищи в онлайне..
если и там нет, сверься с английским вариантом..
вот в частности по твоей проблеме:
http://dev.mysql.com/doc/mysql/ru/LIMIT_optimisation.html
В некоторых случаях, когда используется LIMIT # и не используется HAVING, MySQL будет выполнять запрос несколько иначе:
Если при помощи LIMIT выбираются только несколько строк, MySQL будет использовать индексы в тех некоторых случаях, когда он обычно предпочел бы делать полное сканирование таблицы.
Если LIMIT # используется с ORDER BY, MySQL закончит сортировку, как только найдет первые # строк, вместо того, чтобы сортировать всю таблицу.
При сочетании LIMIT # с DISTINCT MySQL остановится, как только найдет # уникальных строк.
В некоторых случаях группировка GROUP BY может быть выполнена путем упорядоченного считывания ключа (или путем выполнения сортировки по ключу) и последующего вычисления итогового результата пока не изменится значение ключа. В этом случае LIMIT # не будет вычислять какие-либо ненужные предложения GROUP BY.
После того как MySQL пошлет первые # строк клиенту, он прервет выполнение запроса (если не используется SQL_CALC_FOUND_ROWS).
LIMIT 0 всегда будет быстро возвращать пустую выборку. Эта команда полезна для проверки запроса и получения типов столбцов результата.
Если сервер для выполнения запроса использует временные таблицы, LIMIT # применяется для вычисления того, сколько для них потребуется места.
Надеюсь, исчерпываеюще, но на всякий случай английский:
http://dev.mysql.com/doc/mysql/en/LIMIT_optimisation.html
BM>И еще вопрос — на сколько гадко для перформанса использование LIKE "some_text%" на MEDIUMTEXT поле?
BM>У меня есть выбор — либо делать LIKE "some_text%", либо добавлять в запрос еще один LEFT JOIN (причем на ту же таблицу что стоит во FROM).
аналогично, все есть в стандартной документации
http://dev.mysql.com/doc/mysql/ru/MySQL_indexes.html
MySQL применяет индексы также для сравнений LIKE, если аргумент в выражении LIKE представляет собой постоянную строку, не начинающуюся с символа-шаблона. Например, следующие команды SELECT используют индексы:
mysql> SELECT * FROM tbl_name WHERE key_col LIKE "Patrick%";
mysql> SELECT * FROM tbl_name WHERE key_col LIKE "Pat%_ck%";
В первой команде рассматриваются только строки с "Patrick" <= key_col < "Patricl", а во второй — только строки с "Pat" <= key_col < "Pau".
Следующие команды SELECT не будут использовать индексы:
mysql> SELECT * FROM tbl_name WHERE key_col LIKE "%Patrick%";
mysql> SELECT * FROM tbl_name WHERE key_col LIKE other_col;
В первой команде величина LIKE начинается с шаблонного символа. Во второй команде величина LIKE не является константой.
В версии MySQL 4.0 производится другая оптимизация на выражении LIKE. Если используется выражение ... LIKE "%string%" и длина строки (string) больше, чем 3 символа, то MySQL будет применять алгоритм Турбо Бойера-Мура для инициализации шаблона для строки и затем использовать этот шаблон, чтобы выполнить поиск быстрее.
или тут:
http://dev.mysql.com/doc/mysql/en/MySQL_indexes.html
BM>Что менее гадко?
как замерять "что менее гадко" в каждом конкретном случае, читай тут:
http://dev.mysql.com/doc/mysql/ru/Custom_Benchmarks.html
http://dev.mysql.com/doc/mysql/ru/Query_Speed.html
Здравствуйте, vvaizh, Вы писали:
V>Здравствуйте, BugMan, Вы писали:
BM>>если это имеет значение (в чем я сомневаюсь) то разговор пойдет про mySQL....
BM>>Вобщем пытался я оптимизировать один запросец (вернее их там несколько, но это не важно) и подумалось мне что LIMIT на скорость его выполнения никак не влияет, во всяком случае если в запросе присутствует ORDER BY, а влияет только на обьём памяти занимаемый результатом....
BM>>Прав я или нет?
BM>>Вопрос с одной стороны вроде простой, но с другой не понятно где искать ответ, во всяком случае в моей книжке про это ничего не сказано....
V>если нет в книжке, ищи в онлайне..
V>если и там нет, сверься с английским вариантом..
V>вот в частности по твоей проблеме:
V>http://dev.mysql.com/doc/mysql/ru/LIMIT_optimisation.html
V>V>В некоторых случаях, когда используется LIMIT # и не используется HAVING, MySQL будет выполнять запрос несколько иначе:
V>Если при помощи LIMIT выбираются только несколько строк, MySQL будет использовать индексы в тех некоторых случаях, когда он обычно предпочел бы делать полное сканирование таблицы.
V>Если LIMIT # используется с ORDER BY, MySQL закончит сортировку, как только найдет первые # строк, вместо того, чтобы сортировать всю таблицу.
V>При сочетании LIMIT # с DISTINCT MySQL остановится, как только найдет # уникальных строк.
Надо ли это понимать что результат использования ORDER BY + LIMIT непредсказуем?
Не совсем понятно какой смысл может иметь выборка скажем первых 30 записей и последующая их сортировка... хотя может и имеет, но это точно не то что мне нужно. Т.к. мне требуется взять первые 30 записей уже отсортированной таблицы.
Видимо придется избавиться от LIMIT и контролировать кол-ло обрабатываемых записей в ручную, так?
За остальное спасибо.
