c# - executereader - sqldatareader read

¿Hay algo más rápido que SqlDataReader en.NET?

Question

Necesito cargar una columna de cadenas de la tabla en SqlServer en Array en la memoria usando C #. ¿Hay una manera más rápida que abrir SqlDataReader y recorrerlo en bucle? La mesa es grande y el tiempo es crítico.

EDITAR Estoy intentando construir .dll y usarlo en el servidor para algunas operaciones en la base de datos. Pero es lento por ahora. Si esto es más rápido de lo que tengo que rediseñar la base de datos. Es difícil que exista alguna solución para acelerarlo.

Answer 1

"Proporciona una forma de leer un flujo de filas de una base de datos de SQL Server solo hacia delante" Este es el uso de SqlDataReader de MSDN. La estructura de datos detrás de SqlDataReder solo permite leer hacia adelante, está optimizada para leer datos en una dirección. En mi opinión, quiero usar SqlDataReader que DataSet para la lectura simple de datos.

Answer 2

¿Qué hay de transformar una columna de filas en una fila de columnas y tener solo una fila para leer? SqlDataReader tiene una optimización para leer una sola fila (argumento System.Data.CommandBehavior.SingleRow de ExecuteReader ), por lo que quizás pueda mejorar un poco la velocidad.

Veo varias ventajas:

• Mejora de una sola fila,
• No es necesario acceder a una matriz en cada iteración ( reader[0] ),
• La clonación de una matriz ( reader ) en otra puede ser más rápida que recorrer los elementos y agregar cada una a una nueva matriz.

Por otro lado, tiene la desventaja de obligar a la base de datos SQL a hacer más trabajo.

Answer 3

Algunas cosas a considerar en el nivel de la superficie que pueden afectar la velocidad (además de un lector de datos):

1. Optimización de consultas de base de datos
   • OrderBy es caro
   • Distinto es caro
   • RowCount es caro
   • GroupBy es caro
   • Algunas veces no puede vivir sin estas cosas, pero si puede manejar algunas de estas cosas en su código C #, puede ser más rápido.
2. Indización de la tabla de la base de datos (para empezar, ¿están indexados los campos en su cláusula WHERE?)
3. Tipos de datos de la tabla de la base de datos (¿está utilizando el menor tamaño posible, dados los datos?)
4. ¿Por qué estás convirtiendo el datareader a un array?
   • por ejemplo, ¿serviría igual de bien crear un adaptador / datos que no necesitaría convertir a una matriz?
5. ¿Has mirado en Entity Framework? (podría ser más lento ... pero si está sin opciones, podría valer la pena echarle un vistazo para asegurarse)

Sólo pensamientos al azar. No estoy seguro de lo que podría ayudar en su situación.

Answer 4

El SqlDataReader será la forma más rápida. Optimice el uso de la misma, utilizando el método Getxxx apropiado, que toma un ordinal como parámetro.

Si no es lo suficientemente rápido, vea si puede modificar su consulta. Coloque un índice de cobertura en la (s) columna (s) que desea recuperar. Al hacerlo, el servidor Sql solo tiene que leer el índice, y no tiene que ir directamente a la tabla para recuperar toda la información que se requiere.

Answer 5

No. En realidad, no solo es la forma más rápida, sino que es la ÚNICA (!) Forma. Todos los otros mecanismos INTERNALMENTE usan un DataReader de todos modos.

Answer 6

Si la capacidad de respuesta es un problema al cargar una gran cantidad de datos, observe el uso de los métodos asíncronos: BeginReader.

Lo utilizo todo el tiempo para poblar grandes elementos de la GUI en segundo plano mientras la aplicación sigue respondiendo.

No ha dicho exactamente qué tan grande es este dato, o por qué lo está cargando en una matriz.

Muchas veces, para grandes cantidades de datos, puede dejarlo en la base de datos o dejar que la base de datos haga el trabajo pesado. Pero deberíamos saber qué tipo de procesamiento está haciendo que lo necesita todo en una matriz al mismo tiempo.

Answer 7

Sospecho que SqlDataReader es tan bueno como vas a obtener.

Answer 8

SqlDataReader es la forma más rápida. Asegúrese de utilizar los métodos ordinales de obtener en lugar de obtener el nombre de columna. por ejemplo, GetString (1);

También vale la pena experimentar con MinPoolSize en la cadena de conexión para que siempre haya algunas conexiones en el grupo.

Answer 9

Tiene 4 conjuntos de gastos generales - Acceso a disco - Código .net (cpu) - Código del servidor SQL (cpu) - Tiempo para cambiar entre el código administrado y el no administrado (cpu)

En primer lugar es

select * where column = “junk” 

Lo suficientemente rápido para usted, si no la única solución es hacer que el disco sea más rápido. (Puede obtener datos de SQL Server más rápido de lo que puede leerlos)

Es posible que pueda definir una función de Servidor SQL en C # y luego ejecutar la función en la columna; perdon no se como hacerlo Esto puede ser más rápido que un lector de datos.

Si tiene más de una CPU y conoce un valor en la mitad de la tabla, podría intentar usar más de un subproceso.

Es posible que pueda escribir algunos TSQL que combinen todas las cadenas en una sola cadena usando un separador que sepa que es seguro. Luego divide la cuerda otra vez en C #. Esto reducirá la cantidad de viajes de ida y vuelta entre el código administrado y el no administrado.

Answer 10

Lector de datos

El acceso más rápido que obtendrás a SQL es con SqlDataReader .

Perfil

Vale la pena en realidad perfilar dónde está su problema de rendimiento. Por lo general, donde cree que está el problema de rendimiento, se demuestra que es totalmente incorrecto después de haberlo perfilado.

Por ejemplo podría ser:

1. El tiempo ... la consulta tarda en ejecutarse.
2. El tiempo ... los datos tardan en copiarse a través de la red / límite de proceso
3. El tiempo ... .Net tarda en cargar los datos en la memoria.
4. El tiempo ... tu código tarda en hacer algo con él.

El perfilado de cada uno de ellos de forma aislada le dará una mejor idea de dónde se encuentra su cuello de botella. Para perfilar su código, hay un gran artículo de Microsoft

Caché

Lo que hay que tener en cuenta para mejorar el rendimiento es resolverlo si necesita cargar todos esos datos cada vez. ¿Se puede almacenar en caché la lista (o parte de ella)? Eche un vistazo al nuevo System.Runtime.Caching nombres System.Runtime.Caching .

Reescribir como T-SQL

Si está realizando operaciones puramente de datos (como sugiere su pregunta), puede volver a escribir su código, que utiliza los datos para ser T-SQL y ejecutarse de forma nativa en SQL. Esto tiene el potencial de ser mucho más rápido, ya que trabajará con los datos directamente y no los cambiará.

Si su código tiene una gran cantidad de lógica de procedimiento necesaria, puede intentar mezclar T-SQL con la integración CLR, lo que le brinda los beneficios de ambos mundos.

Esto se reduce en gran medida a la complejidad (o más naturaleza procesal) de su lógica.

Si todo lo demás falla

Si todas las áreas son óptimas (o tan cerca como), y su diseño no tiene fallas. Ni siquiera me metería en la microoptimización, solo le lanzaba hardware .

¿Qué hardware? Pruebe el monitor de confiabilidad y rendimiento para averiguar dónde está el cuello de la botella. Lugar más probable para el problema que describe HDD o RAM.

Answer 11

Si SqlDataReader no es lo suficientemente rápido, tal vez debería almacenar sus cosas en otro lugar, como un caché (en memoria).