He creado una secuencia de comandos para encontrar la selectividad de cada columna para todas las tablas. En algunas tablas con menos de 100 filas, la selectividad de una columna es más del 50%. Donde selectividad = valores distintos/Filas de número total. ¿Son esas columnas elegibles para un índice? O bien, ¿puede decirme el requisito mínimo para el número de filas para crear un índice?¿Cuál es el número mínimo de filas requeridas para crear un índice?
Puede indexar en cualquier columna - la pregunta es si tiene algún sentido y si se utiliza ese índice ....
Típicamente, una selectividad de menos de 1-5% podría funcionar - la más pequeña ese porcentaje, mejor. Lo mejor son los valores únicos de una gran población, p. una ID de cliente única de cientos de miles: definitivamente se usarán esos índices.
Las cosas como el género (solo 2 valores) u otras cosas que solo tienen un número muy limitado de valores posibles normalmente no funcionan bien en un índice. Al menos por su cuenta, estas columnas podrían estar bien para ser incluidas en otro índice como una segunda o tercera columna.
Pero en realidad, la única manera de saber si es o no un índice que tiene sentido es
No hay una regla de oro sobre cuándo se usará (o se ignorará) un índice: demasiadas variables influyen en esa decisión.
Para algunos consejos de expertos sobre cómo hacer frente a los índices, y la manera de averiguar lo que los índices no podría acostumbrarse, y cuando tiene sentido para crear un índice, ver las entradas del blog de Kimberly Tripp:
no estoy seguro acerca de SQL-servidor, pero la mayoría de los DBMS no utilizan un índice para la recuperación i f puede recuperar todas las filas de la tabla en una sola E/S. Verá esto en las explicaciones de PLAN, algunas tablas siempre se escanean en el espacio de tablas.
En mi humilde opinión, cualquier tabla con menos de 5000 filas no vale la pena analizar la cardinalidad si el DBMS se está ejecutando en un servidor.
La mayoría de los DBMS utilizan un caché para datos y código (procedimiento almacenado, plan de ejecución, etc.). En SQL Server creo que se llama los datos y caché de procedimientos, y en Oracle, se llama la caché de memoria intermedia y la SGA. Los datos y/o el índice de la tabla pueden estar en la memoria caché.
La tabla pequeña a la que se accede con frecuencia probablemente encajará en la caché. Pero la tabla puede desalojarse de la memoria caché, por ejemplo, si una consulta carga datos nuevos del disco. Hay opciones para indicar que desea que una tabla sea permanentemente en el caché (consulte PINTABLE).Esa es quizás una estrategia mejor que utilizar un índice si su tabla es muy pequeña (que es su caso). Agregar un índice (que también estaría siempre en la caché) podría ayudar aún más, pero no sé cuál sería la ganancia.
La gran diferencia en el rendimiento es el acceso al disco frente al acceso a la memoria. El propósito del índice es reducir la cantidad de datos para leer desde el disco, pero si ya está en la memoria, la ganancia es probablemente pequeña.
Tengo una tabla con 3 valores de interger y todos son dostinct. La selectividad de eso es más del 95%. Y esta tabla se usa principalmente con solo una declaración. Entonces, ¿es posible crear un índice sobre eso? – Paresh
95% significado selectivo? Típicamente, desea una selectividad muy baja: desea que un solo valor (ID = 55) solo seleccione una cantidad mínima de filas. Si su selectividad en ese escenario (porcentaje de cuántas filas del total se seleccionará para un valor dado de su campo) es inferior al 5% o superior, incluso por debajo del 1%, entonces definitivamente tiene sentido indexar. –
"Cosas como el sexo (solo 2 valores)" ahora que es 2018, esta parte de su respuesta está desactualizada. El género debería ser VARCHAR (255) a partir de ahora. Personalmente me identifico como un helicóptero de ataque apache. –