As colunas que não são índices são classificadas no disco junto com o índice?

As colunas que não são índices são classificadas no disco juntamente com o índice, no MySQL, no MyISAM e no InnoDB?

Um pensamento incorreto que comecei a escrever:

Eu acho que provavelmente não, pois eles não são indexados; se eles foram classificados, isso significa que são índices.

Isso não está correto porque cada coluna de índice é classificada pela ordem do seu próprio conteúdo, mas estou perguntando sobre a ordem de cada linha (ou de apenas algumas colunas) com seu índice correspondente.

Para explicar, eu digo: isso seria útil para acelerar a seleção de intervalos de linhas, que ficam lado a lado, juntos, por seus índices. Por exemplo, se eu quiser select * where id >1000 and id<2000(pode haver erros na sintaxe do MySQL, eu não a conheço bem), a própria coluna id pode ser lida rapidamente do disco, porque provavelmente suas células de 1000 a 2000 permanecem juntas no disco físico . Mas outro conteúdo da coluna correspondente à identificação 1000 a 2000 pode ser gravado em locais diferentes no disco físico. Se eles também forem classificados, eles serão lidos mais rapidamente. Eu acho que talvez o MySQL classifique automaticamente essas colunas no disco físico, para desempenho de tais operações.

Eles são classificados em outros tipos de bancos de dados (PostgreSQL, etc.)?

27 de dezembro: Vejo pelas 2 respostas que, no caso de índice / chave primária em cluster, as próprias linhas simples não são classificadas no disco físico (como eu pensava que poderia / poderia ser), e até o índice em cluster é não classificado, se for b-tree, li sobre b-tree e vi que seus nós, como eu entendo, permanecem em locais aleatórios no disco.

Eles podem ser classificados em alguns casos. O índice de classificação é geralmente chamado de chave de cluster . Se for esse o caso, a tabela inteira será armazenada dentro desse índice (geralmente em algum tipo de estrutura de árvore B).

No outro caso, a estrutura da tabela é conhecida como heap , as linhas são armazenadas à medida que aparecem, excluindo as folhas "buracos" nos blocos de dados e esses buracos são posteriormente preenchidos com novas linhas, para que nem mesmo a "ordem de inserção" seja preservada.

O MyISAM usa a estrutura da pilha , com cada linha sendo identificada pelo deslocamento (tipo de índice da matriz ) no arquivo de dados. Cada índice contém as colunas indexadas para cada linha, classificadas na ordem correta e com o número de deslocamento para localizar a linha real. Isso significa que acessar a linha por qualquer índice significa localizar o (s) nó (s) certo (s) no índice (árvore B) e, em seguida, ler o (s) deslocamento (s) correto (s) do arquivo de dados (a busca aleatória para uma parte diferente do disco pode ocorrer )

O InnoDB usa clustering pela chave primária (ou, se nenhuma estiver definida, a primeira chave exclusiva não nula será usada ou uma coluna interna de incremento automático será adicionada - para que as linhas sejam sempre classificadas de alguma forma). Nesse caso, o acesso pela chave primária é "direto", quando o valor adequado é localizado, você tem toda a linha em mãos, sem necessidade de fazer uma segunda leitura. Os índices secundários, por outro lado, não podem armazenar um deslocamento como no MyISAM (porque a árvore B está se reequilibrando dinamicamente, portanto o deslocamento de uma linha específica pode mudar a qualquer momento) e, em vez disso, eles armazenam os valores da chave primária da linha. acesso por uma chave secundária significa duas pesquisas em árvore B no InnoDB.

O MS SQL Server oferece uma opção para tornar a chave primária (ou outro índice) em cluster ou não em cluster, para que você possa escolher entre o heap (nenhum índice está em cluster) e a estrutura em árvore (um índice está em cluster). Todos os outros índices não agrupados em cluster armazenam valores especiais (RowID) no caso de heap ou os valores de chave em cluster da linha no caso do IC.

O PostgreSQL usa apenas tabelas de heap , mas permite reordená-las por algum índice sob demanda (você precisa ativá-lo, para que as linhas sejam ordenadas após a ação, mas gravações adicionais na tabela possam quebrar essa ordem novamente).

O TokuDB (um mecanismo MySQL / MariaDB de terceiros) pode usar várias chaves de cluster em uma tabela - efetivamente mantém várias cópias da tabela, cada uma classificada de maneira diferente. Ele vem com uma penalidade nas gravações, mas o TokuDB alega usar algo que eles chamam de índices fractais, o que deve tornar a penalidade bastante pequena.

Se você precisar usar essa funcionalidade para algumas consultas, poderá "emular" criando um índice de cobertura - para que as colunas de sua consulta estejam disponíveis na ordem certa a qualquer momento, mas, novamente, isso significa manter uma cópia ordenada de (partes de ) a tabela em seus índices.

A resposta curta e simples para bancos de dados em geral é: não, a ordem física das linhas em uma tabela geralmente não é a mesma que em algum índice dessa tabela.

Em geral (digo em geral porque existem casos especiais em que isso não é verdade), a tabela e o índice são duas estruturas físicas diferentes no disco. Os RDBMs convencionais armazenam dados para que os valores de uma linha da tabela (não da coluna ) sejam localizados próximos um do outro no disco; as próprias linhas não são armazenadas em nenhuma ordem específica. As entradas de índice, por outro lado, são armazenadas em ordem; um índice típico de árvore b contém valores classificados de colunas indexadas (mas não outras colunas!) e algum tipo de ponteiro para o local de toda a linha na tabela que é, como afirmei anteriormente, uma estrutura física separada no disco.

Dito isto, existem casos especiais. Por exemplo, o InnoDB do MySQL armazena linhas de dados reais em uma estrutura semelhante a um índice. O índice pelo qual as linhas são colocadas nessa "tabela de índice" geralmente é a chave primária da tabela; e esse índice é chamado de índice clusterizado . Mas é claro que uma tabela do InnoDB pode ter outros índices e ordenação de linhas (ou seja, colunas de linha incluídas no respectivo índice) nesses índices não tem nada a ver com a ordenação de linhas na própria tabela.