Comportamento com Chaves Compostas usando FK - MySQL

[bnobre]

Olá a todos,

Eu precisei modelar uma tabela hoje e reparei em um comportamento que até então nunca tinha percebido no MySQL, até pelo fato de raramente usar índices compostos, pra ser sincero nunca. kkkkkkkkkkkkkkkkkk

No MySQL, sempre que criou um campo FK, automaticamente o banco cria também um índice do tipo KEY associado a esse campo FK, inclusive se eu tentar apagar esse índice do tipo KEY criado automaticamente recebo um erro do MySQL, portanto ele é obrigatório existe para toda a FK. Acho que até aí não é novidade para ninguém.

Só que hoje eu precisei criar um índice composto do tipo UNIQUE na seguinte estrutura abaixo:

O primeiro campo eu deixei como chave primária e autoincrement, como rege a boa prática, pois com uma chave primária simples facilito relacionamentos futuros (além de outros benefícios) e consigo o mesmo efeito da chave composta com um índice do tipo UNIQUE.

O segundo e terceiro campos (destacados em amarelo) são respectivamente FKs para a tabela "tbl_produtos" e "tbl_tabelaprecos" que possuo em meu banco de dados. Portanto como explicitado no início do tópico o MySQL criou também índices do tipo KEY associado aos mesmos que inclusive não podem sem excluídos... Até aí tudo certo.

Porém eu preciso criar a chave composta do tipo UNIQUE com esses campos, e deu certo, mas o que me intrigou e fez eu abrir esse tópico é que ao criar com esses campos uma chave composta do tipo UNIQUE o MySQL apagou a chave do tipo KEY associada ao campo id_produtos. Manteve só a do outro (id_tabelaprecos). Porque??????

Interessante que ao criar a chave composta do tipo UNIQUE, se eu alterar a ordem dos campos na chave, o MySQL também altera o campo do tipo KEY que ele apaga, por exemplo:

O comando usado foi esse:

Citar

UNIQUE INDEX `id_produtos_id_tabelaprecos` (`id_produtos`, `id_tabelaprecos`) -> id_produtos vem primeiro

Mas se eu usar:

Citar

UNIQUE INDEX `id_produtos_id_tabelaprecos` (`id_tabelaprecos`, `id_produtos`) -> id_tabelaprecos vem primeiro

Nesse caso ele apaga o índice do tipo KEY associado a FK id_tabelaprecos.

O mesmo comportamento se dá na criação de PKs compostas usando campos FKs, já testei.

Tentei pesquisar na internet o porque dessa comportamento do MySQL, mas não achei nada. Alguém saberia me explicar?

Desde já agradeço a atenção

 

[Victor H. Gonzales - Panda]

Eu não conheço índice do tipo KEY.

conheço indices que são unique e non-unique, que tem o tipo Btree, FullText, Spatial.

o tipo Key acredito que referece aos indices non-unique btree.

o fato da primary key criar um index, pois a PK é do tipo Primary Btree, mas ela não cria outro indice, ela precisa de um indice clusterizado.

se esses 3 ID seu é unico por registro, eles podem ser a PK sua.

ou se é uma tabela de produtos (por produto), você não precisa da primeira coluna de controle, só da segunda e terceira como pk

 

MySQL :: Manual de Referência do MySQL 8.1 :: 15.6.2.1 Índices Secundários e Agrupados