¿Necesita crear explícitamente un índice o está implícito al definir la clave primaria? ¿La respuesta es la misma para MyISAM e InnoDB?
¿Necesita crear explícitamente un índice o está implícito al definir la clave primaria? ¿La respuesta es la misma para MyISAM e InnoDB?
Respuestas:
La clave primaria siempre está indexada. Esto es lo mismo para MyISAM e InnoDB, y generalmente es cierto para todos los motores de almacenamiento que admiten todos los índices.
De acuerdo con http://dev.mysql.com/doc/refman/5.0/en/constraint-primary-key.html , parecería que esto sería implícito
Aunque esto se preguntó en 2009, pensé que publicaría una referencia real a la documentación de MySQL en las claves principales. http://dev.mysql.com/doc/refman/5.5/en/optimizing-primary-keys.html
La clave principal de una tabla representa la columna o el conjunto de columnas que utiliza en sus consultas más importantes. Tiene un índice asociado, para un rendimiento rápido de la consulta.
Para obtener una referencia de MySQL 5.0, consulte: http://dev.mysql.com/doc/refman/5.0/en/mysql-indexes.html
La mayoría de los índices MySQL ( PRIMARY KEY , UNIQUE, INDEX y FULLTEXT) se almacenan en B-trees. Las excepciones son que los índices en tipos de datos espaciales usan árboles R, y que las tablas de MEMORIA también admiten índices hash.
La clave primaria está indexada implícitamente tanto para MyISAM como para InnoDB. Puede verificar esto utilizando EXPLAIN en una consulta que utiliza la clave primaria.
Supongo que esta es la respuesta.
mysql> create table test(id int primary key, s varchar(20));
Query OK, 0 rows affected (0.06 sec)
mysql> show indexes from test \G
*************************** 1. row ***************************
Table: test
Non_unique: 0
Key_name: PRIMARY
Seq_in_index: 1
Column_name: id
Collation: A
Cardinality: 0
Sub_part: NULL
Packed: NULL
Null:
Index_type: BTREE
Comment:
Index_comment:
1 row in set (0.00 sec)Los índices se usan mejor en columnas que se usan con frecuencia en las cláusulas where, y en cualquier tipo de clasificación, como "ordenar por". Es posible que esté trabajando en una base de datos más compleja, por lo que es bueno recordar algunas reglas simples.
Los índices se aceleran donde las cláusulas y se ordenan. Recuerde pensar en CÓMO se usarán sus datos al construir sus tablas. Hay algunas otras cosas para recordar. Si su tabla es muy pequeña, es decir, solo unos pocos empleados, es peor usar un índice que dejarlo fuera y dejarlo escanear una tabla.
Los índices realmente solo son útiles con tablas que tienen muchas filas.
Otra cosa para recordar, que es una estafa en la situación de la base de datos de nuestros empleados, es que si la columna tiene una longitud variable, los índices (así como la mayoría de MySQL) funcionan de manera mucho menos eficiente.
¡No olvides unirse también! Los campos de unión indexados aceleran las cosas.
La clave primaria siempre se indexa automáticamente y es única. Por lo tanto, tenga cuidado de no crear índices redundantes.
Por ejemplo, si creó una tabla como tal
CREATE TABLE mytable (foo INT NOT NULL PRIMARY KEY, bar INT NOT NULL, baz INT NOT NULL,
UNIQUE(foo), INDEX(foo)) ENGINE=InnoDB;como desea indexar la clave principal y aplicar una restricción de unicidad, ¡en realidad terminaría creando tres índices foo!
Uno puede pensar en una columna de clave primaria como cualquier otra columna indexada con las restricciones de la clave primaria que trae consigo.
En la mayoría de los casos de uso, necesitamos tanto la clave primaria como la columna / columnas indexadas en una tabla, porque nuestras consultas a la tabla pueden filtrar filas en función de la columna / columnas que no es la clave principal, en ese caso generalmente indexamos esas columnas / columnas también.