Как стать автором
Обновить

Комментарии 32

Все можно было сделать гораздо быстрее, использовав вместо перебора двоичным поиском, метод с выводом результата запроса прямо в текст ошибки: rdot.org/forum/showpost.php?p=1913&postcount=8
Очень интересный способ, спасибо. Тем не менее на указанном моим знакомым сайте получаю «The used SELECT statements have a different number of columns»

Или я что-то не понимаю, или в 4.1.21 не работает так
Странно, ни один не сработал. Хотя я понимаю, что должны работать. Давайте в личку скину сайт? Может это я что-то не так делаю просто?
Все работает, это просто я спать хочу уже
я не могу вникнуть почему значение поля выводится, объясните?
все из-за этого: bugs.mysql.com/bug.php?id=8652
This problem happens because in a GROUP BY query a RAND expression can be evaluated
several times for the same row, every time returning a new result.
> Уважаемые разработчики, не делайте 2 запроса, там где можно сделать один!
> В этом случае можно было вместо SELECT count(*) проверить количество записей
> возвращенных запросом SELECT *

Меня это дело тоже всегда бесило — то, что надо посылать два запроса. Но иначе-то нельзя (в типовых базах данных, с которыми я работал), так как нельзя вытаскивать все 100500 записей — сервер не резиновый — нужно вытаскивать по-странично. А знать общее количество нужно — чтобы прокрутку или страничную навигацию правильно проинициализировать.
А как же SQL_CALC_FOUND_ROWS?
Это вызывает фактически выборку всех строк, включая все сложные join'ы мержи и прочие радости.
Тогда как count(*) можно сделать с сильно упрощенным вариантом запроса.
Ну в этом случае тоже надо постоянно следить чтобы данные упрощённого запроса совпадали, в общем, везде свои нюансы. Просто «андреич» так категорично заявил… неверно это…
как минимум — выкинуть сортировку. Уже улучшает.
Согласен, да я тут сам проверил поподробнее, COUNT(*) — лучше, так как оформлять результаты тестов было лень, нашёл статью где человек всё выложил красиво. Ниже выложил.
Но ведь и SELECT FOUND_ROWS() придется сделать, или не так?
хах, и то верно
Если мне не изменяет память, этот запрос обрабатывается libmysqlclient без пинания сервера.
Не беру ваши слова под сомнение, но все же можно источник инфы?
Источник инфы — исходники MySQL, а именно файл include/mysql.h с описанием клиентской структуры подключения к серверу, в которой есть поле my_ulonglong affected_rows, используемое функцией mysql_affected_rows.
А какое отношение к SELECT'у имеет функция, возвращающая количество рядов для INSERT/UPDATE/REPLACE/DELETE и, если уж брать более подходящую mysql_num_rows, разве она вернет количество записей «без лимита»?
Тьфу, не то сейчас смотрел. Где-то я нечто подобное видел, но уже точно не упомню, где именно.
Нет там ничего, в свое время все перерыл. Лучше Count(*) ничего нет (
Дык это в мускуле. А в постгресе? А еще в какой базе?
Статья про мускул, при чём тут другие базы?
а смысл для одной таблицы? Запросов все равно 2, а также интересные сравнения.
Ваша ссылка ни о чём, но я тут сам попробовал и пришёл к выводу который хорошо описан здесь

P.S. Кому лень читать: COUNT(*) работает быстрее из-за того что результаты этого запроса кешируются
habrahabr.ru/blogs/mysql/64655/ — тут тоже тестили и также пришли к выводу что обычный COUNT работает или быстрее (когда закеширован или когда есть индексы), или примерно столько же времени (когда нет кеша и индексов), поэтому использование SQL_CALC_FOUND_ROWS видится нецелесобразным
Процедуры, не?
Ну я имел в виду конкретный случай — выборка одной записи по primary key. Зачем делать count(*) если точно знаешь, что запись либо одна, либо ни одной.
Ребята! А зачем постить здесь то, что на antichat.ru постили 5 лет назад? Вы уж проститет за занудство.
Все хорошо
Можно было бы воспользоваться функцией ascii и получать в количестве ascii код побуквенно
НЛО прилетело и опубликовало эту надпись здесь
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.