"CREATE INDEX` no MySQL é uma operação linear?

O que quero dizer é o seguinte:

Se criar um índice em uma tabela com nlinhas leva ttempo. A criação de um índice na mesma tabela 1000*nlevará aproximadamente 1000*ttempo.

O que estou tentando obter é estimar o tempo necessário para criar o índice no banco de dados de produção, criando o mesmo índice no banco de dados de teste muito menor.

A criação de índice é essencialmente uma operação de classificação , portanto, na melhor das hipóteses, possui uma complexidade de crescimento da ordem n log nem média (você pode achar que ele se sai melhor em alguns casos e provavelmente não se sai muito pior).

Se todas as suas páginas de dados relevantes couberem na RAM e já estiverem na RAM, e o índice também caberá, e o DBMS não força a gravação das páginas de índice antes da conclusão da criação (para que os blocos de índice não sejam atualizados no disco várias vezes durante operação), a velocidade de gravação do índice resultante no disco será mais significativa do que o tempo necessário para realizar a classificação - portanto, você pode achar que está mais próximo de um relacionamento linear entre o número de linhas e o tempo que a criação do índice leva - mas se você presumir o pior dos casos, é menos provável que fique desagradavelmente surpreso!

Lembre-se de que, a menos que você não interrompa o acesso ao banco de dados de produção durante a operação, qualquer criação de índice estará competindo pela largura de banda de E / S e / ou bloqueios com outras atividades; portanto, tente explicar isso se estiver realizando seus testes de estimativa de tempo em outro sistema, mesmo que ele esteja configurado de forma idêntica.

Também é importante notar que, se você pode dividir os eixos dos índices dos eixos da tabela, poderá trabalhar com dois discos ao mesmo tempo (ainda assim, esteja limitado à velocidade do controlador de disco no meio, se um RAID ou algo parecido, mas ainda assim será mais rápido que um disco).

Percebo que a criação de um índice não é completamente uma operação de leitura, gravação e simulação, mas acelera consideravelmente as coisas.

CAVEATS: Eu também sou um cara do MSSQL e, portanto, não tenho certeza do MySQL, mas tenho que imaginar que o conceito de divisão de eixos não é específico para SQLServer e Oracle (onde ouvi falar sobre isso também, IIRC ) Eu simplesmente não saberia como definir esse conceito. Mas, em termos do SQLServer, isso significaria ter um grupo de arquivos separado PRIMARYe colocar os índices no outro grupo de arquivos, com o outro grupo de arquivos atribuído a um conjunto de eixos-árvore que não envolvem PRIMARY(colocação de eixo- árvore concedida versus grupos de arquivos é outra história)

Se essa pergunta fosse feita há cerca de 6 anos, eu diria enfaticamente NÃO, pois teria pertencido ao MySQL 4.x. No entanto, o MySQL 5.x atualmente realiza a criação de índices linearmente. Eu apenas tive uma experiência nostálgica explicando isso na minha resposta à pergunta anterior.

Depende.

Variável # 1: Se o MySQL optar por criar o (s) índice (s) em tempo real, ou esperar até que todos os dados estejam inseridos, faça uma classificação, etc., para criar o índice. Nota: Índices UNIQUE (eu acho) precisam ser criados dinamicamente para que a UNIQUEness possa ser verificada. A PRIMARY KEY for InnoDB é armazenada com os dados (ou você pode indicar o contrário), de modo que DEVE ser construído aleatoriamente.

Variável # 2: o Índice rastreia os dados (por exemplo, AUTO_INCREMENT ou timestamp) versus aleatório (GUID, MD5) ou em algum lugar intermediário (número da peça, nome, friend_id).

Variável # 3 (se o índice for criado em tempo real): o índice pode caber no cache (key_buffer ou innodb_buffer_pool) ou pode derramar no disco.

Os índices que rastreiam os dados são eficientes e virtualmente lineares, independentemente da resposta ao número 1.

Ids aleatórios são uma dor. Se o índice não couber no cache, o tempo para compilá-lo será muito pior que o linear, independentemente das outras variáveis. (Eu discordo de Rolando neste caso.) Uma enorme tabela do InnoDB com um GUID para o PK é dolorosamente lenta para INSERIR no plano em 100 linhas / s para discos comuns; talvez 1000 se você tiver SSDs. CARREGAR DADOS e INSERTs em lote não ultrapassarão a lentidão do armazenamento aleatório.

3,53 a 5,6 - pouco mudou.

Fusos múltiplos? A distribuição de RAID é melhor em quase qualquer situação do que atribuir manualmente isso aqui e aquilo para lá. A divisão manual leva a situações desequilibradas - uma verificação de tabela está presa no disco de dados; uma operação somente de índice está presa no disco de índice; uma consulta solitária primeiro atinge o disco de índice, depois o disco de dados (sem sobreposição); etc.