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

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

Se todas as suas páginas de dados relevantes couberem na RAM e já estiverem na RAM, e o índice também couber, e seu DBMS não forçar as páginas de índice a serem gravadas antes que a criação seja concluída (portanto, os blocos de índice não são atualizados no disco várias vezes durante a operação), a velocidade de gravação do índice resultante no disco será mais significativa do que o tempo necessário para executar a classificação - portanto, você pode descobrir que está mais próximo de uma relação linear entre o número de linhas e o tempo que a criação do índice leva - mas se você assumir o pior caso, é menos provável que você seja surpreendido de forma desagradável!

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 por largura de banda de E/S e/ou bloqueios com outras atividades; em outro sistema, mesmo que esteja configurado de forma idêntica.

Também digno de nota é que, se você puder dividir os fusos para os índices dos fusos para a tabela, poderá trabalhar em dois discos ao mesmo tempo (ainda limitado à velocidade do controlador de disco no meio, se um RAID ou similar, mas ainda assim será mais rápido que um disco).

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

ADVERTÊNCIAS: Eu também sou um cara do MSSQL e, portanto, não tenho certeza sobre o MySQL, mas imagino que o conceito de divisão de eixos não seja específico para SQLServer e Oracle (onde também ouvi falar sobre isso, 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 não envolvidos PRIMARY(o posicionamento concedido do eixo versus grupos de arquivos é outra história)

Se esta pergunta fosse feita cerca de 6 anos atrás, eu teria dito enfaticamente NÃO, pois ela se referia ao MySQL 4.x. No entanto, o MySQL 5.x executa a criação de índice linearmente hoje. Acabei de ter uma experiência nostálgica explicando isso em minha resposta à pergunta anterior.

Depende.

Variável #1: Se o MySQL optar por construir o(s) índice(s) em tempo real, ou esperar até que todos os dados estejam inseridos, então faça uma classificação, etc, para construir o índice. Nota: índices UNIQUE (eu acho) devem ser construídos em tempo real para que a UNIQUEness possa ser verificada. A PRIMARY KEY para InnoDB é armazenada com os dados (ou você pode indicar vice-versa), de modo que DEVE ser construída aleatoriamente.

Variável nº 2: O índice rastreia os dados (por exemplo, AUTO_INCREMENT ou registro de data e hora) versus aleatório (GUID, MD5) ou em algum lugar intermediário (número da peça, nome, id_amigo).

Variável nº 3 (se o índice for criado dinamicamente): o índice pode caber no cache (key_buffer ou innodb_buffer_pool) ou pode vazar para o disco.

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

Ids aleatórios são uma dor. Se o índice não couber no cache, o tempo para construí-lo será muito pior do que linear, independentemente das outras variáveis. (Não concordo com Rolando neste caso.) Uma enorme tabela InnoDB com um GUID para o PK é dolorosamente lenta para INSERT - planeje 100 linhas/s para discos comuns; talvez 1000 se você tiver SSDs. LOAD DATA e INSERTs em lote não o farão superar a lentidão do armazenamento aleatório.

3,53 a 5,6 - não mudou muito.

Vários fusos? A distribuição de RAID é melhor em quase todas as situações do que atribuir manualmente isso aqui e aquilo ali. A divisão manual leva a situações de desequilíbrio -- uma varredura de tabela está presa no disco de dados; uma operação somente de índice está travada no disco de índice; uma consulta solitária atinge primeiro o disco de índice e, em seguida, o disco de dados (sem sobreposição); etc.