¿Hacer que un campo sea único lo hace indexado?

10

Si hago una uniquerestricción en un campo, ¿también necesito hacer un índice en ese campo para obtener un tiempo de inserción escalable? ¿O esto se hace por mí (incluso si el índice que utiliza no es de acceso público?)

Específicamente, estoy trabajando con Apache Derby para la creación de prototipos, aunque probablemente lo traslade a MySQL en un futuro semi-cercano. También espero que haya algo en el estándar SQL que diga algo sobre esto.

Nunca tendré necesidad de buscar por este campo, por lo que preferiría no hacer un índice inútil. Pero prefiero tener un índice inútil que tener un O(n)tiempo de inserción.

— corsiKa
fuente

2

Por lo que sé, una restricción única se implementa detrás de un índice único. Puede ver algunas opiniones sobre esta situación en esta pregunta: ¿ cuándo usar una restricción única en lugar de un índice único?

— Marian

@Marian gracias por ese enlace. Fue muy perspicaz.

— corsiKa

2

--EDITAR--

Mi respuesta original (a continuación) probablemente no sea útil para usted porque no aborda la cuestión de las uniquerestricciones. Como han dicho otros, estas restricciones generalmente se implementan con un índice único implícito. En casos especiales, esto podría no ser cierto (por ejemplo, disable novalidatepara Oracle).

La pregunta podría ser: ¿es posible hacer cumplir la unicidad sin un índice? En general, la respuesta es no, aunque en algunos casos un índice agrupado significará que el índice y la tabla son el mismo objeto.

--END EDITAR--

Dijiste "Prefiero tener un índice inútil que tener un tiempo de inserción O (n)", pero en general las bases de datos no tienen tiempo de inserción O (n). Hay dos casos a considerar:

Una tabla normal con o sin índices:

Se vuelcan nuevas filas en la parte superior del montón. El RDBMS probablemente solo mira 1 bloque, por lo que no solo O (1) sino O muy pequeño (1).

Si la tabla tiene índices, se agregará un puntero a la fila a cada uno. Esto generalmente será una operación O (log (n)).
Una tabla con algún tipo de agrupación, por ejemplo, una tabla organizada de índice o clúster para Oracle, o un índice agrupado para SQL Server y otros:

Se insertan nuevas filas en un bloque en particular, lo que puede hacer que el bloque se divida o se desborde, pero pase lo que pase, sigue siendo O (log (n)) o mejor , causado por el árbol b o una estructura similar utilizada para encontrar el bloque.

— Jack dice que intente topanswers.xyz
fuente

Pero la unicidad sin un índice sería O(n)como tener que verificar toda la tabla. Eso es lo que estoy tratando de evitar.

— corsiKa

¡Esta es la mejor respuesta para esta pregunta! +1

— RolandoMySQLDBA

@Trick: sí, al principio no entendí bien. El índice es el precio que paga por la restricción de unicidad, me temo. ¿Puedes usar un índice agrupado en tu caso?

— Jack dice que intente topanswers.xyz

1

@JackPDougless Puedo usar un "índice" estándar y obtener un O(lg n)tiempo de inserción. Eso no es un problema. Mi pregunta es si el sistema, sabiendo que necesita ese índice para obtener un tiempo de inserción decente, cree un índice para mí.

— corsiKa

2

CLAVE PRIMARIA> = ÚNICA> = ÍNDICE == CLAVE

Los datos de InnoDB son ordenados por la PK. MyISAM PK actúa igual que UNIQUE.

INSERT debe agregar una "fila" a todos y cada uno de los índices (de cualquier tipo) que tenga. Esto lleva algo de tiempo. (Por lo general, no hay suficiente tiempo para importar). Todos los índices se almacenan en formato BTree. Los bloques MyISAM BTree son de 1 KB; InnoDB usa 16KB.

Insertar en InnoDB actualiza la PK y los datos simultáneamente.

Insertar en MyISAM generalmente "agrega" los datos al .MYD. Por separado, agrega una fila a la PK (si la hay).

INSERT tiene que verificar primero que no haya una clave duplicada para ninguna clave PRIMARIA o ÚNICA. Esto se hace usando el índice. Y, por lo tanto, por qué las RESTRICCIONES CLAVE ÚNICAS y EXTRANJERAS realmente crean índices. Esto es O (logN), pero generalmente CPU, no E / S, porque si es un almacenamiento en caché eficiente.

— Rick James
fuente

¿Tiene una cita en la especificación de InnoDB que establece que una UNIQUErestricción creará un índice sin que el usuario especifique uno?

— corsiKa

Hmmm ... No, solo años de experiencia.

— Rick James

Y aquí hay una forma de probarlo ... CREA una tabla sin ningún índice secundario; SHOW TABLE STATUS - Index_length será 0. Luego agregue un índice ÚNICO; El ESTADO DE LA TABLA ahora mostrará algo. (Puede que tenga que poner una cantidad de datos no trivial en la tabla.)

— Rick James

1

Para responder a la pregunta en negrita: Sí, hacer que un campo sea único lo indexa como la clave principal. De hecho, había discutido esto en otra pregunta con respecto a las claves primarias que tienen su propio nombre para distinguirlo de otras claves únicas (candidatas) .

En cuanto a las restricciones, se crean índices para usted de modo que se configura el paradigma de restricción. Debería poder eliminar índices duplicados, incluso claves ÚNICAS, siempre que la restricción que haya hecho no haga referencia a otras claves ÚNICAS que haya creado personalmente, aparte del paradigma de restricción.

Es posible que nunca tenga que buscar este campo, pero MySQL seguramente lo hará como ruta para determinar la validez de las claves y determinar cómo realizar las operaciones ON DELETE CASCADE y ON UPDATE CASCADE.

El índice ÚNICO simplemente garantiza la unicidad de las tuplas (singletons, pares, trillizos, ..., n-tuplas, etc.) en cada fila de la tabla.

Es a su discreción eliminar tales índices duplicados, siempre que no rompa el paradigma de restricción que desea que tenga la tabla.

— RolandoMySQLDBA
fuente

1

Esto no responde mi pregunta. Mi pregunta está relacionada con el tiempo de inserción. Si tiene una restricción única, el sistema debe garantizar la unicidad del campo antes de una inserción; si no hay índice en el campo, tendrá que buscar en toda la tabla ( O(n)). Si hay un índice, la búsqueda será mucho más rápida (probablemente O(lg n)). Ese es mi problema. Soy muy consciente de la mecánica de integridad referencial, solo estoy preocupado (a los fines de esta pregunta) sobre el rendimiento.

— corsiKa