Como errado é ter um índice exclusivo e normal na mesma coluna?

Question

Eu tenho a seguinte estrutura de tabela

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 você vai notar, tenho índices duplicados na user_id: date_expired & user_id. Eu, claro, quer que o índice exclusivo, porque eu quero garantir que os dados é único.

A razão para os índices duplicados é porque sem o índice user_id, minha principal consulta de pesquisa leva 4 segundos. Com o índice extra que leva 1 segundo. A consulta está se juntando a tabela na user_id e verificar date_expired.

A tabela tem apenas 275 registros.

• Como é que é ruim para ter um índice exclusivo e normal no mesmo campo?
• Como é que é ruim ter índices maiores do que os dados quando a tabela é puramente ids?

Answer 1

Eu acredito que se você criou seu índice exclusivo como (user_id, date_expired, foreign_id), você vai obter o mesmo benefício de ter um índice normal na user_id com apenas o índice exclusivo. MySQL pode usar as primeiras colunas de qualquer índice para aparar o número de linhas na junção da mesma maneira como um índice em user_id.

Consulte do MySQL documentação índice para obter mais informações.

Você está se referindo à coluna id auto_increment outro lugar no seu esquema para economizar espaço? Desde que seu índice exclusivo abrange todas as outras colunas na sua tabela, é, em essência, em si uma chave primária e pode ser descartado se você não é.

Você pode verificar quais teclas sua consulta está usando prefixando-lo com EXPLICAR.

Answer 2

Eu não entendo o que você quer dizer com índices duplicados. Você tem três índices na tabela:

1. Um para o 'id' chave primária (que implica único)
2. Outro exclusivo para a combinação de 'date_expired', 'user_id', e 'foreign_id'
3. e um terceiro sobre 'user_id' única

por isso não há duplicação, você tem três diferentes índices que vai fazer coisas diferentes. Você precisa de número 3 para acelerar as consultas relacionadas com user_id que é o que você está vendo. Então não há nada de errado com essa tabela particular, você não está duplicando nada. Quanto à segunda pergunta, ele depende de suas necessidades, mas certamente não é mau ter mais espaço utilizado em índices do que no de dados.

O que seria ruim, por exemplo, é ter um único ( 'user_id') e, posteriormente, uma tecla ( 'user_id') (Eu não estou mesmo certo se o MySQL permitirá que) porque um índice conteria o outro e não há nada a ganhar.

Answer 3

Tendo vários índices, incluindo um campo não é mau de todo (essencialmente, eles fazem coisas diferentes de índice). Ele tem um ligeiro impacto sobre write perfomance, mas esse é o trade-off típico que você tem com cada índice em primeiro lugar. Tendo índices comer mais espaço do que os dados em si não é ruim se o espaço é barato. No seu caso, ele deve ser barato, dado o fato de que você tem realmente uma pequena quantidade de entradas.

A pergunta que eu gostaria de pedir a sua posição é: Como é que a indexação de uma pequena mesa, tais afetam tão severamente meu tempo de execução de consulta? Talvez você está fazendo errado alguma coisa (eu penso sobre lotes de querys possivelmente redundantes para esta tabela), como um único deve ser nem perto deste intervalo de tempo com este pequeno número de entradas).