Lumix
и для учебных целей мы заполняем её 1 млн. записей, где в каждое поле tit пишем 32 Кб текста.
Затем выполняем два запроса на клиенте, но данные НЕ фетчим данные.



Насколько я понимаю, первый запрос грузит сервер существенно больше, чем второй.
Вот я и хочу узнать ПРИНЦИПЫ что там примерно происходит, чтобы руководствуясь этими принципами можно было бы принимать более мудрые решения, когда звездочка погоды не делает, а когда замена звездочки на id может привести к сильной экономии.
Например, у меня есть внутренне ощущение, что в данном примере объем записанного текста, хоть 1кб, хоть 32 кб, на запрос со звездочкой не влияют, но я не могу это объяснить.

Бегло пробежал весь топик. А почему никто не спросил какая база? Это может зависеть от конкретной базы, и даже от конкретного режима!
Например, в maria (и в mysql, насколько понимаю) с настройками по умолчанию не важно, фетчите вы данные или нет, вся таблица перегрузится вам в память, и будет создан ResultSet ее всю содержащий. Если данных много - будет OOM. А если сделать setFetchSize(Integer.MIN_VALUE), то драйвер переключается в режим row-by-row fetching, тогда по документации - будет фетчится по 1 колонке, реально - будет фетчиться некоторое небольшое кол-во колонок за раз, по всей видимости ограниченное некоторым размером(это видно по ваершарку). Это означает, что если в этом режиме просто сделать select *, но данные не фетчить, то mysql ничего никуда не закэширует (возможно только первую порцию) и не прочтет, потому что он тоже делает это в потоковом режиме, по мере запроса. Ну, по крайней мере, не должен. При этом какие-то подготовки с запросом будут сделаны, но там неособо много. Правда, пользы от такого селекта будет ноль.

Другие базы могут вести себя как-то по другому, но совершенно точно, что если запрашивается все, то 32кб колонка будет загружена в память - и как минимум эту память отожрет. Возможно, вы не замечаете этого потому что у вас все работает на 1 машине, и винт быстрый, и все отрабатывает быстро. Ну так подключитесь клиентом по медленному вайфаю и выполните эти два селекта. (для чистоты эксперимента можно еще использовать SQL_NO_CACHE или его аналог) Запрошенные данные будут бежать по сети и разницу вы заметите очень легко.

miksoft,

Оу, это ветка по Mysql. Я че-то решил, что я в java. В таком случае, все вопрос "а какая база" - снимается.
Это поведение жавовского коннектора. Наверное, в php и других все обстоит примерно так же, так что скорей всего это же и php.

Я не говорил, что засовывается всегда весь набор в память. Я говорил, что есть 2 режима, и тот что стоит в Java-коннекторе по умолчанию, засовывает весь набор в память.

MasterZivЭто не так даже с Java-коннектором, и даже в PHP, я уверен, всё не так.
читайте документацию http://dev.mysql.com/doc/connector-j/en/connector-j-reference-implementation-notes.html

By default, ResultSets are completely retrieved and stored in memory. In most cases this is the most efficient way to operate and, due to the design of the MySQL network protocol, is easier to implement. If you are working with ResultSets that have a large number of rows or large values and cannot allocate heap space in your JVM for the memory required, you can tell the driver to stream the results back one row at a time.

To enable this functionality, create a Statement instance in the following manner:

stmt = conn.createStatement(java.sql.ResultSet.TYPE_FORWARD_ONLY,
java.sql.ResultSet.CONCUR_READ_ONLY);
stmt.setFetchSize(Integer.MIN_VALUE);

The combination of a forward-only, read-only result set, with a fetch size of Integer.MIN_VALUE serves as a signal to the driver to stream result sets row-by-row. After this, any result sets created with the statement will be retrieved row-by-row.



MasterZivНе идиоты же его писали, чтобы весь набор в память засасывать.

Такими категориями мыслить не следует. Обоснование того или иного решения гораздо более многогранно, каждое решение имеет свои недостатки и свои достоинства. Например, при таком подходе меньше данных бегает по сети. Меньше зависимость от сети, один раз стянул все - и пользуешься. Таким образом, row-by-row нужно когда надо обрабатывать на стороне клиента очень большие по возвращаемым данным селекты, в практике это встречается редко.