Início / dba / Perguntas / 18975
Accepted
Abdul Manaf
Asked: 2012-06-08 22:48:45 +0800 CST

Como melhorar o desempenho do servidor MySQL..?

  • 772

Como DBA MySQL, na maioria das vezes, devemos otimizar servidores MySQL com baixo desempenho.

Agora, minha pergunta é por onde começar, pois precisaremos descobrir muitas coisas como 

1.Find the duplicate indexes.
2.Find unused indexes on the basis of selectivity.
3.Monitor the Server Parameters(What should be important parameters).
4.Execute MySQL Server performance tuning script.
5.Slow logs

Então, qual deve ser a ordem de examinar o servidor e quais devem ser as coisas exatas que devem ser monitoradas/analisadas para melhorar o desempenho.

mysql performance

1 respostas

  1. Best Answer

    Encontrando Índices Duplicados

    Em janeiro de 2012, @gbn respondeu a uma pergunta sobre índices duplicados, onde apresentou 2 visualizações que vieram do blog de Ronald Bradford . Combinei as duas exibições em uma única consulta para apresentar índices duplicados da seguinte maneira:

    SELECT
    ndx1.TABLE_SCHEMA,ndx1.TABLE_NAME,
    CASE 
        WHEN ndx1.COLUMNS = ndx2.COLUMNS
        AND (ndx1.IS_UNIQUE = ndx2.IS_UNIQUE) 
        THEN GREATEST(ndx1.INDEX_NAME, ndx2.INDEX_NAME) 
        ELSE ndx1.INDEX_NAME 
    END REDUNDANT_INDEX_NAME,
    GROUP_CONCAT(DISTINCT 
        CASE 
            WHEN ndx1.COLUMNS = ndx2.COLUMNS
            AND (ndx1.IS_UNIQUE = ndx2.IS_UNIQUE) 
            THEN LEAST(ndx1.INDEX_NAME, ndx2.INDEX_NAME) 
            ELSE ndx2.INDEX_NAME 
        END
    ) INDEX_NAME 
FROM
(
    SELECT
        TABLE_SCHEMA,TABLE_NAME,INDEX_NAME,INDEX_TYPE,
        IF(NON_UNIQUE, 'NO', 'YES') IS_UNIQUE,
        GROUP_CONCAT(CONCAT('`',COLUMN_NAME,'`')
        ORDER BY IF(INDEX_TYPE='BTREE',SEQ_IN_INDEX,0), COLUMN_NAME
        ) COLUMNS 
    FROM
        information_schema.STATISTICS 
    GROUP BY
        TABLE_SCHEMA,TABLE_NAME,INDEX_NAME,INDEX_TYPE,NON_UNIQUE 
) ndx1 INNER JOIN 
(
    SELECT
        TABLE_SCHEMA,TABLE_NAME,INDEX_NAME,INDEX_TYPE,
        IF(NON_UNIQUE, 'NO', 'YES') IS_UNIQUE,
        GROUP_CONCAT( 
        CONCAT('`',COLUMN_NAME,'`') 
        ORDER BY IF( INDEX_TYPE = 'BTREE'
        , SEQ_IN_INDEX
        , 0) 
        , COLUMN_NAME
        ) COLUMNS 
    FROM
        information_schema.STATISTICS 
    GROUP BY
        TABLE_SCHEMA,TABLE_NAME,INDEX_NAME,INDEX_TYPE,NON_UNIQUE 
) ndx2
ON ndx1.TABLE_SCHEMA = ndx2.TABLE_SCHEMA
AND ndx1.TABLE_NAME = ndx2.TABLE_NAME 
AND ndx1.INDEX_NAME != ndx2.INDEX_NAME
AND ndx1.INDEX_TYPE = ndx2.INDEX_TYPE 
AND CASE 
WHEN ndx1.COLUMNS = ndx2.COLUMNS
AND (ndx1.IS_UNIQUE = 'NO'
OR ndx1.IS_UNIQUE = ndx2.IS_UNIQUE)
THEN TRUE 
WHEN ndx1.INDEX_TYPE = 'BTREE' -- when BTREE 
AND INSTR(ndx2.COLUMNS, ndx1.COLUMNS) = 1
AND ndx1.IS_UNIQUE = 'NO'
THEN TRUE 
ELSE FALSE 
END 
GROUP BY ndx1.TABLE_SCHEMA,ndx1.TABLE_NAME,REDUNDANT_INDEX_NAME
;

    Obviamente, os índices com menos coluna por agrupamento precisam ser eliminados

    Encontre índices não utilizados com base na seletividade.

    Não fiz muito com índices não utilizados em meus dias de desenvolvedor. Eu tento fazer apenas índices necessários que correspondam às seguintes cláusulas:

    • ONDE
    • GRUPO POR
    • ORDENAR POR

    No caso de você precisar limpar um banco de dados procurando índices não utilizados, leia estes:

    Monitore os Parâmetros do Servidor (Quais devem ser parâmetros importantes)

    Esta é apenas uma amostra do tipo de valores de status globais a serem monitorados. Por favor, leia a documentação do MySQL nas variáveis ​​de status do servidor .

    Execute o script de ajuste de desempenho do MySQL Server

    O script mais direto é mysqltuner.pl Basta obtê-lo e executá-lo

    # wget mysqtuner.pl
# perl mysqltuner.pl

    Registros lentos

    Logs lentos podem ser bastante úteis em um ambiente de baixo tráfego. Infelizmente, tenho visto muitas ocorrências do seguinte

    Diante desse cenário, tenho consultas que funcionam de forma independente com uma velocidade incrível param quando uma infinidade de consultas precisa de tabelas comuns.

    IMHO, o log de consulta lento, na verdade, não é bom porque registra consultas concluídas que são consideradas lentas. O que você realmente deseja fazer é capturar consultas de longa duração no ato de serem de longa duração. Portanto, eu recomendaria usar pt-query-digest para agrupar a lista de processos (ou tmpdump) para consultas em execução descontrolada. Escrevi uma postagem em dezembro de 2011 sobre como criar um script de trabalho crontab que pesquisa a lista de processos a cada 20 minutos usando mk-query-digest (pt-query-digest pode ser inserido nele).

    • 7

relate perguntas