none
Creación de un Indice para la carga de una Tabla en un DataSet RRS feed

  • Pregunta

  • Hola a todos.

    Estoy cargando en un DataSet una Tabla mediante el Fill del TableAdapter y en dicho Select estoy añadiendo un Order By para que en el DataSet tenga los datos bien ordenados cuando los voy a coger con los BindingSources, y me gustaría saber hasta que punto es aconsejable el añadir un índice en la Tabla de la BBDD por dicho Order by para optimizar la carga, o bien me lo puedo ahorrar y optimizar así el espacio de la propia BBDD.

    Aunqnue parezca una pregunta trivial y aparentemente lo más normal es que el índice exista en la Tabla de la BBDD, no se hasta que punto tiene relación la carga del fill del TableAdapter con la propia Tabla, e incluso si lo más aconsejable es también que dicho índice exista en la propia Tabla pero del DataSet.

    En fin, solamente deseo esclarecer la duda.

    Saludos.

    lunes, 24 de octubre de 2011 10:01

Respuestas

  • Los índices siempre debes especificarlos para optimizar el filtrado y despues en ordenación. Quiero decir...que si tu pones un where col1 >20 y eso devuelve 1Millon de filas y se hace un recorrido del índice, si tu índice tiene todas las columnas no vas a obtener ningun beneficio por tenerlo.

    cada consulta es un mundo, no hay un patron infalible, pero viendo lo que comentas, la respuesta creo que va a ser que no vas a ganar prácticamente nada poniendo un índice para mejorar un order by. Si que es cierto que si el índice satisface al predicado (por ejemplo where campo1= @cantidad)...el que al crear el índice, lo crees con el ordenamiento que toque (que pidas en tu consulta) obviamente va a ayudar, pero fijate que digo que el índice lo creas pensando en mejorar el filtro, no el order by.

    Sobre la cláusula nonclustered, aqui tienes toda la información: http://msdn.microsoft.com/es-es/library/ms177484(v=SQL.105).aspx 

     

    Un saludo

    • Marcado como respuesta Joanca martes, 25 de octubre de 2011 14:21
    martes, 25 de octubre de 2011 14:03

Todas las respuestas

  • Hola Joanca,

    lo importante aqui es saber qué columnas  devuelves (de cuantas) y si haces filtro. Poniéndonos en el caso peor (no filtras), si por ejemplo tu tabla tiene 10 columnas...digamos varchar(100) por hacer mas visible el ejemplo, y tu select recupera 3 por ejemplo, sin filtro ninguno

    select col1,col2,col3 from tutabla order by col4

    si creas un indice :

     create nonclustered index idx_4 on tutabla (col4) include (col1,col2,col3)

    como el nº de páginas del índice es mucho menor que el de la tabla base, SQL Server decidirá utilizarlo y obviamente mejoraras el rendimiento.

    En otro caso, si filtras , el índice deberia estar cubriendo el filtro en lugar de pensarlo para el order by.

    Resumiendo, depende del tipo de consulta y como ves a menos que salgas ganando leyendo menos como el ejemplo que te he puesto...el índice solo va a evitarte el operador Sort (si miras el plan de ejecución) y de el coste que suponga a la consulta dependerá el beneficio que obtengas.


    Atentamente, Enrique Catala Bañuls
    martes, 25 de octubre de 2011 11:35
  • Hola Enrique.

    Ante todo gracias por contestarme.

    Siguiendo lo que comentas, en todos los casos siempre devuelvo todos los Campos indicándolos uno a uno "Select Campo1, Campo2, ...", es decir sin indicar el "Select * From ..", por lo que me devuelve tantos como tenga la tabla, 5, 10, 15, ..., y además siempre también tengo el filtro "Where", en donde si hay casos de Joins indico el correspondiente "INNER JOIN" o "LEFT OUTER JOIN", por lo que en los Campos del Select también recupero los Campos Descripción de las Tablas asociadas Join, y además en el Filtro "Where" acostumbro a indicar algún filtro de la propia Tabla, ya sean por ejemplo los "Activos = 1" de un Campo tipo BIT, o bien algún referencia vía Parámetros "Where Campo1 = @CampoParameter", o incluso más complejos con "LIKE RTRIM(Campo1) = ' ....", o también puedo llegar a colocar en el Select, por ejemplo los "(TOP @Cantidad)" o bien "(TOP @Cantidad PERCENT)".

    Como ves tengo diversidad de filtros y sobre estos en todas las Selects añado al final el "Order by" que me interesa, algunos de los cuales pueden ser una referencia a la Primary Key o a un Indice Unique, o bien otros a diversidad de Campos de la Tabla y ahí es donde radica mi pregunta, los cuales uso básicamente para mostrar datos en pantalla por alguna Tabla Maestros - Detalle, viéndolos ordenados según el BindingSource.

    Si lo entiendo bien, por lo que comentas por mi perfil debería de crear un índice según el "poti - poti" que tengo en el "where" en lugar de crearlo según el "Order By", pero la verdad es que no acabo de verlo.

    Por otro lado pones un ejemplo con la cláusula "nonclustered" y ahí me pierdo un poco, ya que Yo creo los índices en el Sql Management Studio del 2008 Express R2.

    Gracias por tu atención.

    Saludos.

    martes, 25 de octubre de 2011 13:50
  • Los índices siempre debes especificarlos para optimizar el filtrado y despues en ordenación. Quiero decir...que si tu pones un where col1 >20 y eso devuelve 1Millon de filas y se hace un recorrido del índice, si tu índice tiene todas las columnas no vas a obtener ningun beneficio por tenerlo.

    cada consulta es un mundo, no hay un patron infalible, pero viendo lo que comentas, la respuesta creo que va a ser que no vas a ganar prácticamente nada poniendo un índice para mejorar un order by. Si que es cierto que si el índice satisface al predicado (por ejemplo where campo1= @cantidad)...el que al crear el índice, lo crees con el ordenamiento que toque (que pidas en tu consulta) obviamente va a ayudar, pero fijate que digo que el índice lo creas pensando en mejorar el filtro, no el order by.

    Sobre la cláusula nonclustered, aqui tienes toda la información: http://msdn.microsoft.com/es-es/library/ms177484(v=SQL.105).aspx 

     

    Un saludo

    • Marcado como respuesta Joanca martes, 25 de octubre de 2011 14:21
    martes, 25 de octubre de 2011 14:03