2012-04-09 14 views
6

Tengo un problema de rendimiento al llamar a getInt dentro de un ResultSetExtractor. GetInt se llama 20000 veces. Una llamada cuesta 0.15 ms, el costo total es de 24 segundos, mientras se ejecuta dentro del generador de perfiles. La ejecución de las sentencias de SQL lleva alrededor de 8 segundos (acceso a través de la clave principal). Uso el controlador mysql versión 5.1.13, servidor mysql 5.1.44 y spring-jdbc-3.1.1 ¿Tiene una idea para mejorar el rendimiento?Problema de rendimiento con getInt dentro de ResultSetExtractor

mut.getMutEffect()[0]=(rs.getInt("leffect_a") != 0); 
    mut.getMutEffect()[1]=(rs.getInt("leffect_c") != 0); 
    ... 
    mut.getMutEffect()[19]=(rs.getInt("leffect_y") != 0); 
    mut.getMutReliability()[0]=rs.getInt("lreliability_a"); 
    ... 
    mut.getMutReliability()[19]=rs.getInt("lreliability_y"); 

Mi esquema es el siguiente

CREATE TABLE mutation (
... 
leffect_a BIT NOT NULL, 
lreliability_a TINYINT UNSIGNED NOT NULL, 
... 
leffect_y BIT NOT NULL, 
lreliability_y TINYINT UNSIGNED NOT NULL, 
... 
) ENGINE=MyISAM; 

Editar: Dentro de la méthode getInt getIntWithOverflowCheck se llama que parece ser caro. ¿Es posible cambiar estos controles?

Respuesta

2

Aquí están algunas sugerencias:

  • Conjunto traiga tamaño a un número bastante grande: Statement.setFetchSize(). Esto debería reducir los viajes de ida y vuelta al servidor de la base de datos mientras se procesa el conjunto de resultados.

  • Asegúrese de que la instrucción de selección es óptima mediante el perfilado

  • optimización de la tabla general, por ejemplo, ¿Estás usando tipos de datos correctos? Parece que podría cambiar el archivo leffect_a a BOOLEAN

  • Asegúrese de no devolver ninguna columna innecesaria en su instrucción SELECT.

  • Uso PreparedStatement

  • Evitar conjuntos de resultados desplazables y actualizables (tampoco lo son por defecto)

+0

Statement.setFetchSize() funcionó bien. Muchas gracias. –

0

dos sugerencias:

  1. almacenar el resultado de getMutEffect() y getMutReliability() en las variables locales, ya que se utilizan repetidamente. El jit de hotspot puede alinear y eliminar las expresiones duplicadas, pero creo que es más claro no confiar en esto.
  2. Puede ser más rápido recuperar los valores de ResultSet usando sus indices en lugar de los nombres de las columnas. Incluso podría crear un mapa local de nombres para indexar, curiosamente para algunos controladores jdbc esto es más rápido que dejar que ResultSet realice la asignación.
+0

Gracias por la respuesta. El generador de perfiles muestra que es barato mapear el nombre de la columna al índice. Y tampoco hay problemas de rendimiento al acceder a getMutEffect. –

Cuestiones relacionadas