少なくとも時々はそうです。 Wiresharkを使用してMySQLConnector/Jバージョン5.1.37の動作をテストしました。テーブルについて...
CREATE TABLE lorem (
id INT AUTO_INCREMENT PRIMARY KEY,
tag VARCHAR(7),
text1 VARCHAR(255),
text2 VARCHAR(255)
)
...テストデータ付き...
id tag text1 text2
--- ------- --------------- ---------------
0 row_000 Lorem ipsum ... Lorem ipsum ...
1 row_001 Lorem ipsum ... Lorem ipsum ...
2 row_002 Lorem ipsum ... Lorem ipsum ...
...
999 row_999 Lorem ipsum ... Lorem ipsum ...
(where both `text1` and `text2` actually contain 255 characters in each row)
...そしてコード...
try (Statement s = conn.createStatement(java.sql.ResultSet.TYPE_FORWARD_ONLY, java.sql.ResultSet.CONCUR_READ_ONLY)) {
s.setFetchSize(Integer.MIN_VALUE);
String sql = "SELECT * FROM lorem ORDER BY id";
try (ResultSet rs = s.executeQuery(sql)) {
... s.executeQuery(sql)の直後 –つまり、rs.next()の前 と呼ばれることもあります– MySQL Connector / Jは、テーブルから最初の最大140行を取得しました。
実際、tagだけをクエリする場合 列
String sql = "SELECT tag FROM lorem ORDER BY id";
MySQL Connector / Jは、ネットワークフレームのWiresharkリストに示されているように、1000行すべてをすぐに取得しました。
サーバーにクエリを送信したフレーム19は、次のようになりました。
MySQLサーバーはフレーム20で応答しました。フレーム20は...
で始まります。
...そしてすぐにフレーム21が続きました。フレーム21は...
...など、サーバーがフレーム32を送信するまで続きます。フレーム32は
で終了します。
唯一の違いは各行に返される情報の量であったため、MySQL Connector / Jは、返される各行の最大長と使用可能な空きメモリの量に基づいて適切なバッファサイズを決定すると結論付けることができます。
MySQL Connector / Jは、最初に最初のfetchSizeを取得します 行のグループ、次にrs.next() それらを移動すると、最終的に次の行グループが取得されます。これは、setFetchSize(1)にも当てはまります。 ちなみに、これは本当に 一度に1行だけ取得します。
（setFetchSize(n)に注意してください n> 0の場合、useCursorFetch=trueが必要です 接続URLで。これは、setFetchSize(Integer.MIN_VALUE)には明らかに必要ありません。 。）