Pergunta

Executamos um servidor MySQL com carga moderada (200-300 QPS) em hardware bastante poderoso (HP DL360 com 8 núcleos de Xeon, 8 GB de RAM e RAID10). Todas as tabelas são innodb e o conjunto de dados ativo se encaixa dentro do alocado innodb_buffer_pool_size.

Nosso banco de dados é normalizado e para reduzir o número de junções, usamos vistas materializadas para achatar o conjunto de dados. À medida que os dados são adicionados em lotes algumas vezes ao dia, o MV: S são regenerados usando CREATE TABLE AS SELECT Em vez de atualizado dinamicamente usando gatilhos complexos.

O problema é que às vezes enquanto estes CREATE As consultas são executadas (cada uma das quais leva qualquer coisa de 5 a 50 segundos) Outras consultas não relacionadas ao servidor parecem ser enfileiradas atrás do CREATE Consulta, levando a um banco de dados que não responde.

Para (re) gerar o MV: s, usamos algo assim:

BEGIN TRANSACTION;
DROP TABLE IF EXISTS TableName_TMP;
CREATE TABLE TableName_TMP ENGINE=INNODB CHARACTER SET utf8 COLLATE utf8_swedish_ci AS 
    SELECT about100columns, and10Expressions 
    FROM Table1 
    JOIN Table2 ON Table1.fk = Table2.pk 
    /* join up to 13 other tables */
    WHERE ((removed IS NULL OR removed = 0)) 
    ORDER BY created DESC, id ASC;
ALTER TABLE TableName_TMP ADD PRIMARY KEY(id), INDEX(created);
DROP TABLE IF EXISTS TableName;
ALTER TABLE TableName_TMP RENAME TO TableName;
COMMIT;

A explicação da seleção produz algo como:

+----+-------------+------------------+-------------+---------------+------------+---------+------------------------------+-------+-----------------------------+
| id | select_type | table            | type        | possible_keys | key        | key_len | ref                          | rows  | Extra                       |
+----+-------------+------------------+-------------+---------------+------------+---------+    ------------------------------+-------+-----------------------------+
|  1 | SIMPLE      | Table1           | ref_or_null | removed       | removed    | 5       | const                        | 76093 | Using where; Using filesort | 
|  1 | SIMPLE      | Table2           | eq_ref      | PRIMARY       | PRIMARY    | 4       | Table1.fk1                   |     1 |                             | 
|  1 | SIMPLE      | Table3           | eq_ref      | PRIMARY       | PRIMARY    | 4       | Table1.fk2                   |     1 |                             | 
/* More of the same */
|  1 | SIMPLE      | TableN           | eq_ref      | PRIMARY       | PRIMARY    | 4        | TableM.fk                    |     1 | Using index                 | 
|  1 | SIMPLE      | TableX           | eq_ref      | PRIMARY       | PRIMARY    | 4       | TableY.fk                    |     1 |                             | 
/* More of the same */    
+----+-------------+------------------+-------------+---------------+------------+---------+------------------------------+-------+-----------------------------+

Qualquer idéia por que o CREATE TABLE AS Sobrecarregar completamente nosso servidor e como posso evitá -lo?

Cumprimentos,

Foi útil?

Solução

Resolvemos isso mudando para selecionar e carregar dados infilos como por http://www.mysqlperformanceblog.com/2006/07/12/insert-into-select-performance-with-innodb-tables/ . Muito obrigado a Randolph Potter por nos enviar na direção certa.

Outras dicas

Pode ser essa a causa?

NOTA: A tabela Drop comete automaticamente a transação ativa atual, a menos que você use a palavra -chave temporária.

(http://dev.mysql.com/doc/refman/5.1/en/drop-table.html)

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top