Você precisa criar explicitamente um índice ou está implícito ao definir a chave primária? A resposta é a mesma para o MyISAM e o InnoDB?
Você precisa criar explicitamente um índice ou está implícito ao definir a chave primária? A resposta é a mesma para o MyISAM e o InnoDB?
Respostas:
A chave primária é sempre indexada. É o mesmo para MyISAM e InnoDB e geralmente é válido para todos os mecanismos de armazenamento que suportam índices.
De acordo com http://dev.mysql.com/doc/refman/5.0/en/constraint-primary-key.html , parece que isso está implícito
Mesmo que isso tenha sido solicitado em 2009, achei que eu postaria uma referência real à documentação do MySQL sobre chaves primárias. http://dev.mysql.com/doc/refman/5.5/en/optimizing-primary-keys.html
A chave primária de uma tabela representa a coluna ou o conjunto de colunas que você usa em suas consultas mais importantes. Possui um índice associado, para desempenho rápido da consulta
Para referência ao MySQL 5.0, consulte: http://dev.mysql.com/doc/refman/5.0/en/mysql-indexes.html
A maioria dos índices MySQL ( PRIMARY KEY , UNIQUE, INDEX e FULLTEXT) são armazenados em árvores B. As exceções são que os índices nos tipos de dados espaciais usam árvores R e que as tabelas MEMORY também suportam índices de hash.
A chave primária é indexada implicitamente para o MyISAM e o InnoDB. Você pode verificar isso usando EXPLAIN em uma consulta que faz uso da chave primária.
Eu acho que essa é a resposta
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)Os índices são mais usados em colunas que são freqüentemente usadas nas cláusulas where e em qualquer tipo de classificação, como "classificar por". Você pode estar trabalhando em um banco de dados mais complexo, por isso é bom lembrar de algumas regras simples.
Os índices aceleram as cláusulas where e ordenam por. Lembre-se de pensar em COMO seus dados serão usados ao criar suas tabelas. Existem algumas outras coisas para lembrar. Se sua tabela é muito pequena, ou seja, apenas alguns funcionários, é pior usar um índice do que deixá-lo de fora e deixá-lo fazer uma varredura de tabela.
Os índices realmente são úteis apenas com tabelas com muitas linhas.
Outra coisa a lembrar, que é um golpe na situação do banco de dados de nossos funcionários, é que, se a coluna tiver um comprimento variável, os índices (assim como a maior parte do MySQL) terão um desempenho muito menos eficiente.
Não se esqueça de participar também! Os campos de junção indexados aceleram as coisas.
A chave primária é sempre indexada e exclusiva automaticamente. Portanto, tome cuidado para não criar índices redundantes.
Por exemplo, se você criou uma tabela 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;porque você deseja indexar a chave primária e impor uma restrição de exclusividade nela, na verdade, você acaba criando três índices foo!
Pode-se pensar em uma coluna de chave primária como qualquer outra coluna indexada com as restrições da chave primária.
Na maioria dos casos de uso, precisamos de chave primária e coluna / colunas indexadas em uma tabela, porque nossas consultas à tabela podem filtrar linhas com base em colunas / colunas que não são chave primária; nesse caso, geralmente indexamos essas colunas / colunas também.