¿Qué tan incorrecto es tener un índice único y normal en la misma columna?

Question

Tengo la siguiente estructura de tabla

CREATE TABLE `table` (
  `id` int(11) NOT NULL auto_increment,
  `date_expired` datetime NOT NULL,
  `user_id` int(11) NOT NULL,
  `foreign_id` int(11) NOT NULL,
  PRIMARY KEY  (`id`),
  UNIQUE KEY `date_expired` (`date_expired`,`user_id`,`foreign_id`),
  KEY `user_id` (`user_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

Como notará, tengo índices duplicados en user_id: date_expired & amp; user_id . Por supuesto, quiero el índice único porque quiero asegurarme de que los datos sean únicos.

La razón de los índices duplicados es porque sin el índice user_id , mi consulta de búsqueda principal tarda 4 segundos. Con el índice adicional toma 1 segundo. La consulta se une a la tabla en user_id y comprueba date_expired .

La tabla solo tiene 275 registros.

• ¿Qué tan malo es tener un índice único y normal en el mismo campo?
• ¿Qué tan malo es tener índices más grandes que los datos cuando la tabla es puramente ID?

Answer 1

Creo que si creó su índice único como ( user_id , date_expired , foreign_id ), obtendrá el mismo beneficio de tener un índice normal en user_id con solo el índice único. MySQL puede usar las primeras columnas de cualquier índice para reducir el número de filas en la unión de la misma manera que un índice en user_id .

Consulte documentación del índice de MySQL para obtener más información información.

¿Se refiere a la columna id auto_increment en otra parte de su esquema para ahorrar espacio? Dado que su índice único cubre todas las otras columnas de su tabla, en esencia es una clave primaria en sí misma y podría eliminarse si no lo está.

Puede verificar qué claves está usando su consulta con el prefijo EXPLAIN.

Answer 2

No entiendo qué quieres decir con índices duplicados. Tiene tres índices en la tabla:

1. Uno para la clave principal 'id' (que implica único)
2. Otro único para la combinación de 'date_expired', 'user_id' y 'foreign_id'
3. Y un tercero sobre 'user_id' solamente

para que no haya duplicación, tiene tres índices diferentes que harán cosas diferentes. Necesita el número 3 para acelerar las consultas relacionadas con user_id, que es lo que está viendo. Así que no hay nada malo con esta tabla en particular, no estás duplicando nada. Con respecto a la segunda pregunta, depende de sus necesidades, pero ciertamente no es malo tener más espacio usado en los índices que en los datos.

Lo que sería malo, por ejemplo, es tener un ÚNICO ('user_id') y luego una CLAVE ('user_id') (ni siquiera estoy seguro si MySQL lo permitirá) porque un índice contendría el otro Y no hay nada que ganar.

Answer 3

Tener varios índices, incluido un campo, no está nada mal (esencialmente, indexan cosas diferentes). Tiene un ligero impacto en el rendimiento de escritura, pero esa es la compensación típica que tiene con cada índice en primer lugar. Tener índices que consuman más espacio que los datos en sí no es malo si el espacio es barato. En su caso, debería ser barato dado el hecho de que tiene una cantidad realmente pequeña de entradas.

La pregunta que haría en su posición es: ¿Cómo afecta la indexación de una tabla tan pequeña tan severamente el tiempo de ejecución de mi consulta? Quizás esté haciendo algo mal (pienso en muchas consultas posiblemente redundantes a esta tabla), ya que una sola no debería estar cerca de este rango de tiempo con este pequeño número de entradas).