То есть, ты хочешь получить все данные из БД? Только не говори, что это не так Ты же не знаешь заранее, что именно захочет получить юзер. Поэтому ты или делаешь запрос сообразно его требованиям, что противоречит описанному тобой пожеланию, или гружишь из БД все данные, в надежде, что они понадобятся юзеру.
А вот представь, что у тебя 200 ГБ (Двести Гига Байт) данных, и то, не считая индексов. И чё? Ты их будешь грузить в скрипт? А нафига тогда вообще было создано такое понятие, как БД и всякие запросы к ней?

Это не так:) Я хочу получить из БД только те данные, которые мне нужны для данной страницы. Одним большим запросом, с вложенными селектами и тд.

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

ЗЫ: 200 Гб таскать мускулем? Знаете толк в извращениях. Для таких объемов уже свои решения, таже касандра например.

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

Были ли исследования по данному вопросу или это из личного опыта. Если из опыта, то можете в паре слов описать, когда выгодней 2 запроса.

Пример из реальной практики движка этого форума.
При отображении списка тем форума требуется пометить темы, содержащие сообщения того, кто просматривает страницу.
Если заджойнить к таблице топиков таблицу постов, можно получить все данные в один запрос, время выполнения примерно 0.05 секунды.
Если забрать только таблицу топиков и в цикле по топикам гонять запросы к таблице постов, получается 51 запрос, но суммарное время этих запросов меньше 0.01 секунды.

Я как раз по столько не таскаю Да и БД - Постгре.
Я выбираю только те данные, что мне нужны. Вот только фенька в том, что в начале страницы может быть неизвестно, что же именно надо будет вытащить! Это определяется в процессе обработки данных. В зависимости от каких-то условий подключаются те или иные скрипты, в которых могут делаться еще какие-то выборки.
Поэтому я и говорю, что либо данные будут выбираться по мере необходимости в несколько запросов, либо надо загрузить всё, и уже в ПХП-скрипте выбирать, что же нужно.
И еще - скорость выполнения запросов (в первую очередь для сложных запросов) зависит также и от того, насколько правильно прописаны индексы. И насколько правильно построен сам сложный запрос. Разница может быть в десятки-сотни-тысячи раз.

Не знаю.
Была ситуация, когда чат валил sql-сервер в перезагрузки. Переписал движок чата, посадил все запросы на один connection_id, падения прекратились. Может совпало, другого опыта не было.

Совпало. Если не указывать явно идентификатор соединения, то будет использоваться последний использованный (:

Не так. Too many connections появляется, когда количество одновременных соединений с бд превышает параметр max_connections. Из доков. Именно поэтому всем советую коннектиться к бд не в самом начале скрипта, а когда это действительно нужно. Mysql_connect в __construct() не есть гуд, как и игнорирование mysql_close(). А уж если wait_timeout и connect_timeout имеют большое значение, то too many connections долго ждать не приходится - очень неприятная ошибка, т.к. появляется неожиданно, когда в раскрутку начинают вкладываться, соответственно деньги просто вылетают в трубу.

А если у меня одновременно сотни посетителей? обычная нагрузка в вечернее время составляет 2500 генераций страниц в минуту; это больше 40 в секунду.
Мне кажется, что запросы от разных генераций страниц разными посетителями будут или пересекаться, или сваливаться в один айдишник.

Ни разу не видел такого от MySQL, нверное с хостерами везло, но и сам не усердствовал в "оптмизациях". Если в апаче не переусердствовать, то он первым даст отлуп, не заваливая MySQL-сервер.

Вам кажется. Такое ощущение, что вы от пятницы ещё не отошли )) Идентификатор запроса - это ресурс, а не какой-то псевдослучайный числовой идентификатор. Он не повторяется, т.к. выдаётся конкретному потоку веб-сервера b убивается сборщиком мусора. Повторяться он не может, т.к. выдаётся в рамках вебсервера и в этих рамках он уникален независимо от количества одновременных потоков. Если мне не изменяет память (а она у меня верная), после отправки запроса к серверу бд не происходит разрыва соединения, а оно висит, пока не будут возвращены данные. Отсюда очевидно, что пересекаться там нечему. Если же соединение с клиентом потеряно, то результат запроса не передаётся никуда вообще. Не может быть такой ситуации, что один отправил запрос и отвалился, а другой подключился и принял ответ - вновь подключённый будет новым клиентом для бд, даже если это тот же поток и скрипт подключается снова. Единственное, что не могу объяснить: как связка: php-mysql будет себя вести на одновременных запросах одного скрипта при использовании одновременных потоков и одного соединения с бд, но уверен, что там всё схвачено )

Увеличиваете указанные ранее параметры, уменьшаете max_connections и вуаля.

Когда разбирались с обвалами SQL-сервера, логировали его работу в файл.
Файл был такого вида:

[99]SELECT .....
[91]SELECT.....
[97]SELECT.....
[99]SELECT .....

В квадратных скобках - идентификатор сессии.
Я еще программку писал для разбора этих логов, чтобы посмотреть последовательность запросов именно той сессии, на которой произошло падение сервера, и посмотреть прошлые запросы в этой сессии.
Оказалось, что в самих запросах не было ничего криминального, падения происходили при накоплении сессий, не завершившихся командой mysql_close

Эмм.. Я как-то по-другому сказал? Число 100 я взял для примера (хотя до MySQL 5.1.15 max_connections по дефолту было именно 100).

Эм...
У меня сейчас в httpd.conf установлено

MaxClients 15

- это втрое выше дефолтных "5".
Если скрипт 20 секунд ждет курла, 15 клиентов будут наблюдать страницу с ожиданием ответа, а 16-й просто получит 502-ю страницу. Или не так?

Ох, подозреваю, что над одной проблемой маемся, только с разными ее проявлениями.
Я сейчас ковыряюсь с проблемой "холодных стартов": например, не было вообще посетителей, захожу на сайт, и... 10-15 секунд ожидания.
При этом дебагер показывает время генерации страницы php несчастные 0,03-0,05 секунды. Обновляю страницу, и получаю с теми же цифрами на дебаггере, но ответ моментально.
И время задержки "холодного старта" растет прямо пропорционально размеру одной из таблиц в БД...
Думал, что может всю таблицу считывает с харда и в оперативу грузит; проверил в локалке на денвере, вроде ни фига, таблица хорошо за сотню Мб, а прирост потребления оперативы виндой составляет всего пару мегабайт...

500 человек онлайн - это сколько страниц в секунду? Если соцсеть, то 500 человек за 5 минут (обычно онлайнеров считают именно за это время) - это 1.5 человека в секунду. За 5 минут каждый откроет минимум 5 страниц, итого округлим до 10 страниц в секунду. Допустим одна страница - это 10 запросов. Итого 100 запросов в секунду. Отсюда видим, что был предел и любой запрос, отрабатывающий больше секунды начинал строить очередь ожидания, увеличивая очередь в геометрической прогрессии. А пропала ошибка из-за того, что мускуль быстрее стал отрабатывать ваши запросы (памяти больше -> больше таблиц в памяти помещалось -> быстрее отрабатываются запросы) и очередь не строится.
Вроде правильно посчитал.
Вообще зря не трогали настройки мускуля. Очень советую админов нагружать оптимизацией софта. Если админ ненагружаем, то как вариант, mysqltuner - интересные вещи творит.

Короче, ошибка too many connections возникает и от тяжёлых запросов, и от большого количества одновременных открытий соединений с бд.

Может это проблема днса? Либо MaxSpareServers сильно мал, а мускуль забивает всю память кэшем этой большой таблицы. Соответственно когда апачу надо запустить нового клиента часть мускульной оперативки свопится и заполняется дополнительным процессом апача и он отрабатывает именно за указанное время, ведь раньше, чем запустится дочерний процесс статистика дебаггера считаться не будет?

MaxClients 15

MaxClients - параметр указывает сколько дочерних процессов можно создавать родительскому апача. Поведение будет именно таким, как вы сказали.