La configuración del modo de desplazamiento de ResultSet fetchSize no es válida

Dato 1: ¿Cuál es el significado? Después de la prueba, se encuentra que si hay 1w piezas de datos en la biblioteca y se establece fetchSize = 100, el resultado devuelto sigue siendo 1w, que no juega un papel en la paginación. ? ?

Use el cursor ResultSet para procesar registros en lugar del procesamiento de paginación de la capa de la base de datos, configure el modo abierto del cursor en el modo FORWARD_READONLY y use el cursor ResultSet para procesar el tiempo de ejecución real 2 veces más rápido que el procesamiento de paginación de la capa de la base de datos.
El código es el siguiente (ejemplo):
 

String sql=“select * from xxx”;
PreparedStatement pstmt=conn.prepareStatement(sql,ResultSet.TYPE_FORWARD_ONLY,ResultSet.CONCUR_READ_ONLY);
pstmt.setFetchSize(100);
ResultSetrs = pstmt.executeQuery();

Data 2: ResultSet sin parámetros, ¿se cargará en la memoria de una vez y con los parámetros se leerán línea por línea? ? ?

Conjunto resultante

De forma predeterminada, los ResultSets se recuperan y almacenan por completo en la memoria. En la mayoría de los casos, esta es la forma más eficiente de operar y, debido al diseño del protocolo de red MySQL, es más fácil de implementar. Si está trabajando con ResultSets que tienen una gran cantidad de filas o valores grandes, y no puede asignar espacio de pila en su JVM para la memoria requerida, puede decirle al controlador que transmita los resultados una fila a la vez.

Para habilitar esta funcionalidad, debe crear una instancia de declaración de la siguiente manera:

stmt = conn.createStatement (java.sql.ResultSet.TYPE_FORWARD_ONLY,

java.sql.ResultSet.CONCUR_READ_ONLY);

stmt.setFetchSize (Integer.MIN_VALUE);

La combinación de un conjunto de resultados de solo lectura y solo avance, con un tamaño de recuperación de Integer.MIN_VALUE sirve como una señal al controlador para transmitir los conjuntos de resultados fila por fila. Después de esto, todos los conjuntos de resultados creados con la declaración se recuperarán fila por fila.

Hay algunas advertencias con este enfoque. Tendrá que leer todas las filas en el conjunto de resultados (o cerrarlo) antes de poder emitir cualquier otra consulta sobre la conexión, o se lanzará una excepción.

Datos 3: la consulta prepareStatement con parámetros es más lenta que la consulta sin parámetros y, de hecho, es lenta después de la verificación.

            PreparedStatement ptmt = conn.prepareStatement(sql,ResultSet.TYPE_SCROLL_INSENSITIVE,ResultSet.CONCUR_READ_ONLY); //预编译SQL，减少sql执行
//            PreparedStatement ptmt = conn.prepareStatement(sql); //预编译SQL，减少sql执行

 Dato cuatro: el acceso de Java a la base de datos realmente abre un cursor en la base de datos ; getString se carga en la memoria a la vez y getObject no se lee en la memoria a la vez? ? ?

Cuando el código java ejecuta createStatement y prepareStatement, en realidad es lo mismo que abrir un cursor en la base de datos, especialmente si createStatement y prepareStatement están dentro del ciclo, es muy propenso a errores seguir usándolo y no cerrarlo.

Utilice la función getString para ejecutar: el programa colocará los datos en la memoria de una vez y luego obtendrá los datos llamando al siguiente, getString y otros métodos del ResultSet.

El modo de funcionamiento de getObject: Los datos no se leen en la memoria todos a la vez, sino que se almacenan en la base de datos. Cada vez que se llama a getObject, los datos se obtienen directamente de la base de datos, por lo que pueden ejecutarse normalmente.

Datos 5: El prepareStatement de un parámetro se desbordará en la memoria y el prepareStatement de tres parámetros no se desbordará en la memoria --- ¡Creo que esto está realmente probado! (Aunque no conozco el principio)

Gran cantidad de consulta de datos, se ResultSet produce un  JVM desbordamiento de la memoria en uso 

declaración = connection.prepareStatement (sql);

cambie a:

declaración = connection.prepareStatement (sql, ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY);