Здравствуйте, 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