Глобальный select

К чему приводят запросы типа select * from <tablename>, если в таблице миллионы записей, кроме того, что выведет всю таблицу, это создаст нагрузку на сервер и он будет относительно догло дуплить?

Долгому исполнению запроса, невозможностью в это время использовать бд другими юзерами, возможны падения.

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

Эти неприятности начинаются уже на сотнях тысяч, про миллионы - молчу, в моей доверенности такого пока не было.

(Отредактировано автором: 28 Мая, 2012 - 16:42:27)

Будет так называемый хайлоад - т.е. большая нагрузка, поведение базы зависит от возможностей сервера, но в суровых реалях при миллионах записей база отвалится с вероятностью 99.99%.

======

Наврал хайлода не будет, просто все отвалится...

(Отредактировано автором: 28 Мая, 2012 - 16:46:56)

-----
просто ?: сложно

А откуда такая информация?

Это оффициальная инфа, в завизимости от типа mysql бд (myisam || innodb) блакируется или вся таблица или конкретные поля.

-----
просто ?: сложно

Можно ссылочку почитать?

http://www[dot]mysql[dot]ru/docs/mysql-m[dot][dot][dot]table-types[dot]html

-----
просто ?: сложно

Есть такой опыт, так как в распоряжении есть парочка баз в которых есть баблицы с 1-2 млн. записей.
Риск отказа СУБД велик при:
- некорректной архитектуре БД
- отсутствии оптимальности запросов к таблицам БД

Я еще со своей стороны узнал и в итоге имеет такое:

- нагрузка на сервек (или вообще крах, если оч все плохо);
- возможно, блокировка некоторых рядков, если это InnoDB;
- обновление кешей путем втуливания туда новой инфы с селекта;
- создание очереди запросов к данной таблице;

Ох. причёсываю толпу народа и неточностей.


Будет вычитывать всю таблицу. Является ли это проблемой - зависит от объёма данных. И необходимой скорости отклика.
Если памяти достаточно и есть в этом реальная необходимость (чего мне не придумать, работу с данными на базу вешать и надо) - можно читать. Запрос элементарен, данные вовсе линейным чтением поднимаются.
На моей убитой виртуалке 3 ляма записей (около 250мб) обходится в цикле за 15 секунд времени. Замедление других запросов незаметно.
На 4 лямах - кончилась клиентская память, запрос отвалился.


База отработает спокойно. А вот на клиенте память кончится.


Блокировки при изменении данных, для сохранения консистентности.
Параллельные 100% чтения - задача самая простая из работы планировщика СУБД.


Помним о том, что limit 100000, 200000 всё равно прочитает 200 тысяч записей?


Всего лишь?
Тестовое задание ко мне на работу требует нормальной работы на базе в 2 млн пользователей. Связанная тестовая таблица у меня вышла 50млн записей, суммарно 2гб объём. (кстати, Питер, открыта вакансия)


Очень сложно обрушить сервер таким запросом. Вот если попробовать переджойнить с чем-нибудь - то да, nested loop очень печален на таких объёмах.


Само собой. Если это постоянная нагрузка - повод подумать об отключении кэша запросов и увеличении памяти машине.

И ещё раз обращу внимание - сильно сомневаюсь, что вам нужен на клиенте (php то есть) весь этот массив данных. Наверняка же как-то группировать и агрегировать собрались.

-----
PostgreSQL DBA

Еще в добавок: есть такой "страшний" тип данных как BLOB. Извращенцы, например, могуг заливать в поля, добрые фотки или картинки в этом типе данных.

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