Какие запросы к бд mysql можно считать быстрыми и какие медленными?

Question

[Рома]

Всем добра!
В моей бд есть две таблицы категорий и подкатегорий.
Категорий 255 записей. У каждой категории по 30 подкатегорий. Подкатегорий 7650.
Подкатегории связанны с категориями внешним ключом.

Выполняю следующий запрос:
select * from `categories`, `subcategories` where `categories`.`id` = `subcategories`.`category_id`;
Время выполнения:
7650 rows in set (0.06 sec)
В логе время такое:
Query_time: 0.056264 Lock_time: 0.000085 Rows_sent: 7650 Rows_examined: 7905

Меня терзают смутные сомнения по поводу этой (0.06 sec) информации.
Когда в консоли показывает 0.06 сек - это 6 сотых секунды или 6 секунд?

И второй вопрос: Какие запросы можно считать нормальными по времени и какие недопустимо медленными для вебсайта?

Answer 1

[Дмитрий Дарт]

1. Это 6 сотых секунды
2. В целом всё что меньше 0,1 это ок, дальше можно волноваться, но если у вас в базе миллионы записей то и 0,5 может быть ок

Есть возможность в настройках mysql включить лог медленных запросов, установить лимит времени, например 1 секунда и все запросы, выполняющиеся дольше этого значения попадут в лог.

Comments

[Рома]

Когда я запускаю запрос в консоли я также на своем смарте запустил секундомер.
Когда консоль показывает 0.06 сек. на смартфоне показывает около 6 секунд.

По факту запрос в консоли проходит за 6 сек.
Почему консоль показывает 6 сотую секунды?

Или я что-то не понимаю во внутреннем устройстве работы mysql?

В логах я установил long_query_time = 0.01 чтоб на первых порах видеть все запросы.

[InoMono]

но если у вас в базе миллионы записей то и 0,5 может быть ок

В нормально структуированой БД, с нормальными индексами и нормальными грамотными запросами - неважно сколько у вас записей 10 000 или 10 000 000.

Отбираться результат запроса будет одинаково быстро (не путать "отбирать" и "отдавать/отправлять/извлекать" сами данные)

Когда речь идет о десятках миллиардов - уже могут возникнуть притормаживания.

[Дмитрий Дарт]

Лентюй, InoMono, ну естественно я имел ввиду не простую страницу или выборку по 1 столбцу на 10 млн, а что-то типа CRM где все клиенты с детьми и суммой платежей > N за последние 3 года

[InoMono]

Лентюй,

но да. в общем случае тратится еще время на парсинг текста запроса, построения плана его выполнения

Откройте для себя PREPARE

[InoMono]

Дмитрий,

ну естественно я имел ввиду не простую страницу или выборку по 1 столбцу на 10 млн, а что-то типа CRM где все клиенты с детьми и суммой платежей > N за последние 3 года

Тут большая часть времени уйдет на передачу полученных данных.
А вовсе не на их отбор.

И опять же вопрос в целесообразности получения десятков тысяч строк, когда пользователь все равно больше 100 не просмотрит.

[InoMono]

Лентюй,

ого, какой вы умный. а если у вас 10 разных запросов на странице, какая разница будет между (10 prepare + 10 queries) vs 10 simple queries по времени? по шагам давайте

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

сколько это будет в вашем конкретном случае - вы и сами можете легко проверить. правда я не стал бы проверять их по 10, хотя бы по 1000.

да и это не обязательно.
не уверен насчет MySQL - но в PostgreSQL есть специальный кэш, где лежат подготовленные уже запросы. и если вы будете отправлять на сервер одинаковые запросы - они не будут разбираться какждый раз заново - а будут просто браться из кэша (именно подготовленные запросы, а не содержимое ответов). то есть и PREPARE не понадобится.

[InoMono]

Лентюй, я не пишу на PHP, следовательно, не использую pdo. Потому не имею представления кто так что и зачем сует.
Защиту от инъекций мне делать не нужно, доступ к БД слишком далеко зарыт в моих сервисах, ни при каких обстоятельствах снаружи нельзя выполнить запрос чисто архитектурно.

я то знаю зачем нужен prepare и как он работает

Расскажите нам, не скрывайте.
Я думаю - всем будет интересно.

Answer 2

[Melkij]

Какие запросы к бд mysql можно считать быстрыми и какие медленными?

Быстрые это те, время обработки которых не мешает пользователю/бизнесу/всем_причастным.
Медленные - это соответственно те, которые мешают.

0.06 sec в консоли - это 6 сотых секунды, конечно.

Для веба значение имеет время рендеринга страницы пользователю. Хороший результат для backend'а - это 0,2 секунды на генерацию страницы. Это включая всё время обращений к кешам, базам данных и прочую логику построения страницы.

Answer 3

[InoMono]

При грамотно построенной структуре БД, грамотных индексах и грамотном запросе - собственно выполнение запроса осуществляется за доли секунды, да.

А вот получение отобранных данных, а тем более отправка этих данных, в например, браузер на другом конце света - долго.

Поэтому в вашем конкретном запрос - есть еще много чего для оптимизации по скорости.

Ну вот скажите мне, пожалуйста, зачем вам СЕМЬ ТЫСЯЧ строк?
Ведь скорее всего это какое-то интерактивное взаимодействие с пользователем, типа веб-сайта.
Он никогда не будет листать эти 7000. Хорошо еще, если первые 50 просмотрит.
Даже если вы хотите угодить дотошному пользователю, который долистывает до последней страницы - вряд ли целесообразно извлекать из БД более 200-1500 записей.
Так зачем вам мучать сервер данными, которые никому никогда не покажите.

Comments

[Рома]

Это мое первое проектирование бд ) хочу создать для себя блог на YII.
У блога будет боковое меню. В меню будут категории и в каждой категории будут подкатегории.
Категорий и подкатегорий в реале конечно будет меньше. Это я так просто по максимуму заполнил таблицы для тестирования.

В этом боковом меню нужно будет показать все категории и все подкатегории поэтому производится выборка всех записей в этих таблицах.

Подозреваю что я делаю что-то не так.

Есть ли у вас готовая бд для блога как пример? Поделитесь пожалуйста.
Чтоб там были категории, подкатегории, посты, пользователи, комментарии.
Буду рад любой помощи

[Andrey Tsvetkov]

Вываливать такой объём данных для менюшки это конечно же не правильно. Возможно стоит изначально выгрузить лишь категории, а далее, при интересе пользователя к какой-то конкретной категории дозагружать аяксом подкатегории.

[InoMono]

Рома, конкретно эту задачу я бы делал вообще без БД, уже без SQL точно.
Обошелся бы статическим генератором, скорее всего: https://gohugo.io/
А БД если и нужна, то только для поиск - и это специализированная БД для полнотекстового поиска. Скорее всего SphinxSearch

[Рома]

Это задача одна из многих. Таблица Категорий и Подкатегорий мне необходимы и для других задач, не только для формирования бокового меню.
Будет еще таблица Посты, в которой каждый пост будет иметь внешний ключ на подкатегорию. И по запросу /category/subcategory будут выдаваться список постов с постраничной навигацией.

Скорей всего категорий у меня будет около 10 подкатегорий в каждой около 15. Получает будет около 150 записей для выборки. Можно закэшировать html код бокового меню и не обращаться к бд каждый раз. Благо обновляться эти таблицу будет редко.

[InoMono]

Рома, еще раз - для 10-15 и даже 150 категорий - слишком роскошно использовать СУБД.
Это хорошо для общности разработки, для экономии времени разработчика.
Но никак не для является необходимым.
Да и для хороших нагрузок и сложных систем - не лучший выбор.

Но для тренировки - вполне годится задача.

[Рома]

Andrey Tsvetkov, Как я знаю, подгружаемый ajax'ом контент не обрабатывается роботом поисковых систем. Если подгружать подменю ajax'ом не отразится ли это на сео?

[InoMono]

Рома, давно уже обрабатывается.
Ведущими поисковиками - точно.

[Andrey Tsvetkov]

Поисковику можно и даже нужно скармливать sitemap.xml