Início / dba / Perguntas / 208720
Accepted
yaki_nuka
Asked: 2018-06-05 07:53:27 +0800 CST

Pior desempenho após criar tabela vazia

  • 772

Estou trabalhando com o MySQL 5.7.10 e tenho esse problema.

Eu tenho esta tabela para rastrear solicitações:

CREATE TABLE `invoice_requests` (
    `REQUEST_ID` VARCHAR(20) NOT NULL DEFAULT '' COLLATE 'utf8_spanish_ci',
    `INVOICE_ID` VARCHAR(50) NULL DEFAULT NULL COLLATE 'utf8_spanish_ci',
    `STARTTIME` DATETIME NULL DEFAULT NULL,
    `ENDTIME` DATETIME NULL DEFAULT NULL,
    `STATUS` VARCHAR(10) NOT NULL DEFAULT 'WORKING',
    PRIMARY KEY (`REQUEST_ID`),
    UNIQUE INDEX `UNQ_INVOICE_ID` (`INVOICE_ID`),
    INDEX `IDX_REQ_CODE_END_TIME` (`REQUEST_ID`, `ENDTIME`),
    INDEX `IDX_INV_NUMBER` (`INVOICE_ID`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Esta tabela tinha 350 MB e dados do ano passado. Então fiz os seguintes passos:

  • RENOMEAR TABLE invoice_requests PARA 201805_invoice_requests;
  • execute a 'criar tabela' acima.

As primeiras execuções com essa nova tabela vazia pioraram o desempenho de algumas consultas (de 1 segundo para 15).

Com o MySQL EXPLAIN, verificamos que nenhum índice é usado no INNER JOIN com outras tabelas, mas as consultas são as mesmas e os JOINs são feitos com o campo indexado INVOICE_ID.

Para fins de teste, encerramos o JOIN invoice_requests na consulta e os dados solicitados retornaram rapidamente.

Com este cenário, minhas perguntas seriam:

  • Essas são as etapas corretas para fazer backup de uma tabela (e seus índices também)?
  • Preciso dos dados de índice "antigos" na nova tabela vazia? Supostamente, não. Mas não entendo esse comportamento.

Qualquer ajuda será muito apreciada.

mysql performance

2 respostas

  1. Best Answer

    Ajudaria ver a consulta lenta e seu arquivo EXPLAIN.

    Enquanto isso, tente

    ANALYZE TABLE invoice_requests;

    Não há 'estatísticas' úteis em uma tabela vazia. O InnoDB deveria ter recalculado as estatísticas antes de você chegar a esse problema, mas pode estar faltando alguma coisa.

    Os índices são uma bagunça:

    PRIMARY KEY (`REQUEST_ID`),   -- notes 1,2
UNIQUE INDEX `UNQ_INVOICE_ID` (`INVOICE_ID`),  -- notes 1,3
INDEX `IDX_REQ_CODE_END_TIME` (`REQUEST_ID`, `ENDTIME`),  -- note 2
INDEX `IDX_INV_NUMBER` (`INVOICE_ID`)  -- note 3

    Notas:

    1. Por que ter dois índices exclusivos? Você não pode viver com apenas um? (Não sabendo um "pedido" de uma "fatura", não posso aconselhar mais.)

    2. Não se preocupe em adicionar um índice que comece com a(s) coluna(s) do PK

    3. Um UNIQUEíndice é um índice mais uma restrição de exclusividade. Portanto, não se preocupe em adicionar outro índice com a(s) mesma(s) coluna(s).

    Ter um monte de tabelas como 201805_invoice_requestsserá um problema a longo prazo. (Há muitos tópicos discutindo ter várias tabelas idênticas.)

    • 1

  2. No post de ontem, a tabela invoice_requests tem 68k linhas e o desempenho foi muito baixo.

    Agora, algumas novas solicitações chegaram e há apenas 59 linhas a mais.

    Eu estava repetindo a consulta para capturar os resultados e os dados EXPLAIN e, inesperadamente, a consulta leva menos de um segundo.

    Não posso dar nenhuma explicação, nenhuma alteração foi feita no post de ontem. Talvez esta não seja uma mensagem informativa, mas tento não deixar post aberto. Talvez eu devesse esperar mais tempo para postar meu problema, mas ontem essa consulta levou de 13 a 15 segundos dezenas de vezes, em momentos diferentes.

    Então, muito obrigado.

    • 0

relate perguntas