Início / dba / Perguntas / 9009
Accepted
Alex
Asked: 2011-12-10 16:11:10 +0800 CST

Tenho índices de chave duplicados?

  • 772
CREATE TABLE relations (

  object_id BIGINT(20) NOT NULL PRIMARY KEY,
  object_term BIGINT(20) NOT NULL,

  UNIQUE KEY link(object_id, object_term),

  CONSTRAINT fk_term FOREIGN KEY(object_term)
    REFERENCES terms(id) ON DELETE CASCADE ON UPDATE RESTRICT,

  CONSTRAINT fk_object FOREIGN KEY(object_id)
    REFERENCES objects(id) ON DELETE CASCADE ON UPDATE RESTRICT

) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

Tenho a sensação de que estou indexando object_id3 vezes e object_termduas vezes. Estou certo?

Se sim, como posso consertar isso e ainda manter as restrições e a força (object_id, object_term)para serem únicas?

ok, segunda tentativa:

CREATE TABLE relations (

  object_id BIGINT(20) NOT NULL,
  object_term BIGINT(20) NOT NULL,

  PRIMARY KEY link(object_id, object_term),

  CONSTRAINT fk_term FOREIGN KEY(object_term)
    REFERENCES terms(id) ON DELETE CASCADE ON UPDATE RESTRICT,

  CONSTRAINT fk_object FOREIGN KEY(object_id)
    REFERENCES objects(id) ON DELETE CASCADE ON UPDATE RESTRICT

) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

isso é melhor?

mysql database-design

1 respostas

  1. Best Answer

    object_idé indexado três vezes

    • PRIMARY KEY
    • UNIQUE KEY link
    • FOREIGN KEY fk_object

    object_termé realmente indexado uma vez

    • fk_term
    • Em UNIQUE KEY link, object_termnão é a coluna principal.

    ATUALIZAÇÃO 2011-12-09 19:42 EDT

    Na primeira tentativa:

    • object_idé único ( PRIMARY KEY)
    • ( object_id, object_term) é único (isso significa que object_id só pode ser associado a um object_term em um determinado momento)

    Na segunda tentativa:

    • object_idnão é único
    • ( object_id, object_term) é único (isso significa que object_id só pode ser associado a mais de object_term)

    ATUALIZAÇÃO 2011-12-09 19:57 EDT

    Se você está preocupado com o espaço em disco ocupado pelos índices, você deve tomar uma decisão

    OPÇÃO 1: O espaço em disco não é um objeto

    Isso só pode ser benéfico se suas consultas usarem índices de cobertura de maneira eficaz e você estiver disposto a viver com (e fornecer) um grande espaço em disco.

    OPÇÃO 2: O espaço em disco é um bem precioso

    É hora de fazer algumas previsões. Ambos object_ide object_termsão BIGINT. Você pode reduzir o espaço da seguinte maneira:

    SELECT * FROM relations PROCEDURE ANALYSE();

    Isso não despejará todas as linhas. Ele fará uma amostra dos dados e retornará com uma recomendação para as melhores definições de coluna de acordo com os dados.

    Por que isso é importante?

    • TINYINT UNSIGNED é um byte (intervalo de 0 a 255)
    • SMALLINT UNSIGNED é de dois bytes (intervalo de 0 a 65535)
    • MEDIUMINT UNSIGNED é três bytes (intervalo de 0 a 16777215)
    • INT UNSIGNED é de quatro bytes (intervalo de 0 a 4294967295)
    • BIGINT UNSIGNED é de cinco bytes (intervalo de 0 a 2^40 - 1)

    Se você souber que o número não ultrapassará determinados valores, poderá alterar as definições da coluna para acomodar menos espaço em disco. No mínimo, deixe PROCEDURE ANALYSE() sugerir isso para você.

    OPÇÃO 3: O espaço em disco pode ser um gargalo

    Quanto mais hóspedes em casa, mais tarefas domésticas para acomodar. Se um anfitrião pode cuidar de 20 hóspedes, manter todos os 20 felizes, e o anfitrião também está feliz, o anfitrião pode sempre cuidar de 20 hóspedes repetidamente. Adicione mais um convidado e a qualidade dos serviços do anfitrião diminui. O mesmo acontece com os índices. Se suas consultas forem rápidas o suficiente para garantir a manutenção dos índices, você precisará selecionar quais índices são realmente necessários e eliminar os índices redundantes (hóspedes indesejados). O anfitrião deve garantir que a solicitação (consulta) de cada hóspede da casa possa ser atendida (feita com índices de cobertura)

    Bons Links sobre Índices de Cobertura

    • 1

relate perguntas