Peter VARGA's questions

Esta é a saída PMA padrão de uma exportação:

CREATE TABLE `foo` (
  `id` int(11) UNSIGNED NOT NULL,
  `fk_id` int(11) UNSIGNED NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

ALTER TABLE `foo`
  ADD PRIMARY KEY (`id`);

ALTER TABLE `foo`
  MODIFY `id` int(11) UNSIGNED NOT NULL AUTO_INCREMENT;

ALTER TABLE `foo`
  ADD CONSTRAINT `foo_ibfk_1` FOREIGN KEY (`fk_id`) REFERENCES `bar` (`id`),

...

Existe uma maneira de obter uma exportação em que todos os itens a seguir ALTER TABLEsejam mesclados na CREATE TABLEinstrução?

Eu tenho esta tabela:

CREATE TABLE `foo` (
  `CalculatedResultsId` int NOT NULL,
  `Md5Hash` char(32) CHARACTER SET latin1 COLLATE latin1_general_ci NOT NULL,
  `SectionData` json NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_general_ci;

ALTER TABLE `foo`
  ADD UNIQUE KEY `CalculatedResultsId` (`CalculatedResultsId`),
  ADD UNIQUE KEY `Md5Hash` (`Md5Hash`);

que contém ~ 400 mil linhas e tem ~ 800 MB de tamanho. Esta é a saída do PMA:

Em seguida, excluo 2.454 linhas [< 0,6%], o que produz uma sobrecarga de cerca de 5 MB, que também está documentada no PMA:

A execução OPTIMIZE Tablerepentina dobra o tamanho desta tabela. Verifiquei o tamanho real do arquivo da tabela no diretório e está correto. Realmente dobrou!

Minha pergunta:

Por que, o que está acontecendo? O que aconteceu, qual é a razão, que o tamanho da mesa dobrou?

A única maneira que encontrei de reduzir o tamanho da tabela como era antes é criar uma nova tabela e preenchê-la novamente. Outro fato muito estranho:

Executando este comando para obter a cópia da tabela grande CREATE TABLE foo_new AS SELECT * FROM foo;é executado por 27! minutos para essas 400 mil linhas.

Criando uma tabela vazia e depois copiando com INSERT INTO foo_new SELECT * FROM foonecessidades 24! segundos.

Por que tanta diferença? Eu não sei, mas de alguma forma me parece um problema de design muito sério no MySQL, ou um bug.

MySQL 8.0.20 rodando no SLES 15.1

Eu tenho essas configurações em my.cnf:

[mysqld]
...
disable_log_bin
general-log      = false
general_log_file = /var/log/mysql/mysqld.general.log

long_query_time     = 1
slow_query_log      = false
slow_query_log_file = /var/log/mysql/mysqld.slow.query.log

[safe_mysqld]
log-error = /var/log/mysql/mysqld.log

[mysqld_multi]
...
log        = /var/log/mysql/mysqld_multi.log

Cada vez que eu inicio o servidor MySQL, um arquivo vazio /var/log/mysql.logé criado e nunca é preenchido. Eu estava procurando na web por alguma solução, mas não encontro nada sobre o mysql.logque parece estar desatualizado.

Pode ser que ele tenha sido criado por um erro , novamente, pois não encontro nada referente mysql.logao MySQL 8.x ou você sabe como evitar a criação?

Estou executando o MySQL 8.0.20

Eu tenho isto:

SELECT
   @foo1 := UDF1(0, a, b, c, d) AS Foo1,
   @foo2 := UDF1(1, a, b, c, d) AS Foo2,
   @foo3 := UDF1(2, a, b, c, d) AS Foo3,
   @foo4 := UDF1(3, a, b, c, d) AS Foo4,
   @foo5 := UDF2( @foo1, @foo2, @foo3, @foo4) AS Foo5,
   @foo6 := UDF3( @foo1, @foo2, @foo3, @foo4) AS Foo6,
   @foo8 := UDF4( @foo5, @foo7, x, y, z) AS Foo8
FROM MyTable;

Como você pode ver, é bastante complicado e a, b, c, d, x, ye zsão nomes de campos bastante longos [Os nomes expressam sua funcionalidade ].

Recebo agora esta mensagem de erro no MySQL 8.0.20:

X A configuração de variáveis ​​de usuário em expressões está obsoleta e será removida em uma versão futura. Considere alternativas: 'SET variável=expressão, ...', ou 'SELECT expressão(ões) INTO variável(is)'.

OK, este é o lugar errado para discutir se faz sentido que @var := valueseja obsoleto, então eu tenho que seguir em frente e quero garantir que o programa não pare de funcionar se a próxima atualização do MySQL for instalada.

Eu poderia resolver assim:

SELECT
   UDF1(0, a, b, c, d) AS Foo1,
   UDF1(1, a, b, c, d) AS Foo2,
   UDF1(2, a, b, c, d) AS Foo3,
   UDF1(3, a, b, c, d) AS Foo4,
   UDF2(UDF1(0, a, b, c, d), UDF1(1, a, b, c, d), UDF1(2, a, b, c, d), UDF1(3, a, b, c, d)) AS Foo5,
   UDF3(UDF1(0, a, b, c, d), UDF1(1, a, b, c, d), UDF1(2, a, b, c, d), UDF1(3, a, b, c, d) ) AS Foo5,
   UDF3(UDF2(UDF1(0, a, b, c, d) , UDF1(1, a, b, c, d) , UDF1(2, a, b, c, d) , UDF1(3, a, b, c, d) ) ,
        UDF3(UDF1(0, a, b, c, d), UDF1(1, a, b, c, d), UDF1(2, a, b, c, d), UDF1(3, a, b, c, d) ), x, y, z) AS Foo6
FROM MyTable;

Honestamente, isso não dói e, o que eu acho pior, fica tão ilegível e alterando qualquer chamada que tenho que manter muitas vezes --> buggy.

Além disso, na versão atual, o comprimento do SELECT cresce de 2.334 bytes para 3.504 bytes.

Estou tentando trabalhar com uma tabela temporária, mas para preencher a tabela é um SELECT bastante longo e [inútil] complicado usando LEFT JOINcomo @foo5depende @foo1-4e @foo6depende de @foo5.

Isso funciona, mas estou querendo saber se pode haver outra solução que não sou capaz de ver. O sugerido SELECT expression(s) INTO variables(s)eu não entendo como isso deve ajudar no meu caso.

Como escrevi no início, não entendo por que esse recurso está obsoleto, pois aparentemente pode resolver muitos problemas e simplificar as instruções SELECT complicadas ...

Alguma sugestão?

Eu pensei, MyISAMé para tabelas simples e selects devido a sua arquitetura mais rápida que InnoDB. Portanto, alterei o mecanismo para esta tabela de InnoDBpara MyISAM:

CREATE TABLE `table1` (
  `DateTime` datetime NOT NULL,
  `BidHigh` decimal(11,5) NOT NULL,
  `BidLow` decimal(11,5) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_bin COMMENT='1 minute rates';

ALTER TABLE `table1` ADD PRIMARY KEY (`DateTime`);

Estas condições se aplicam:

1. Estou testando em uma VM SLES 15.1 com 5 GB de RAM e 8 núcleos de CPU em um host que é meu e não precisa atender outra VM [apenas uma informação de que não existe outra VM que possa influenciar no resultado].
2. Um script PHP está executando milhares das instruções SELECT abaixo.
3. Existem 24 das tabelas acima no banco de dados que são acessadas no script PHP.
4. Cada tabela tem cerca de 800 mil linhas.
5. Entre cada teste eu reinicio o servidor para garantir que haja sempre as mesmas condições. Devido ao fato de a diferença ser tão grande, não estou executando vários testes para obter uma média ...

O tempo de execução:

• Com InnoDBengine o script roda 199 segundos.
• Com MyISAMengine o script roda 1'026 segundos. Mais de 5 vezes mais.

Estou executando estas instruções SELECT:

SELECT `DateTime` FROM table1
     WHERE `DateTime` BETWEEN '2018-12-27 07:50:00' AND '2199-12-31 23:59:00'
        AND BidHigh > 0.96604
     ORDER BY `DateTime` LIMIT 1;

-- e --

SELECT MIN( BidLow ) FROM table1
    WHERE `DateTime` BETWEEN '2018-12-27 07:45:00' AND '2199-12-31 23:59:00';

OK, eu descobri que é um problema de índice. Adicionando esses dois índices

ALTER TABLE `table1` ADD UNIQUE `BidHigh` (`DateTime`, `BidHigh`);

-- e --

ALTER TABLE `table1` ADD UNIQUE `BidLow` (`DateTime`, `BidLow`);

corrige o problema de desempenho e agora o script precisa de 245 segundos, ainda mais lento do que InnoDB- isso não é realmente o que eu esperava ...

Adicionar esses índices à InnoDBversão não melhora o desempenho.

Minhas perguntas:

1. Por que InnoDBnão precisa desses índices e ainda é mais rápido?
2. Existe uma solução melhor?
3. E, o que eu aparentemente entendi totalmente errado como a mudança MyISAMcausou um desempenho tão horrível.

Eu tenho esta tabela:

CREATE TABLE `ClusterDescription` (
  `ClusterDescriptionId` int(11) NOT NULL AUTO_INCREMENT,
  `ClusterId` int(11) NOT NULL,
  `RightBarDateTime` datetime NOT NULL,
  `InstrumentId` int(11) NOT NULL,
  `RowCreated` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`ClusterDescriptionId`),
  UNIQUE KEY `ClusterInstrumentId` (`ClusterId`,`InstrumentId`),
  KEY `InstrumentId` (`InstrumentId`) USING BTREE,
  KEY `OrderDesc` (`RightBarDateTime` DESC,`ClusterId` DESC)
) ENGINE=InnoDB AUTO_INCREMENT=3055989 DEFAULT CHARSET=latin1 COLLATE=latin1_general_ci 

A tabela tem mais de 3 milhões de linhas.

Recebo regularmente este erro:

SQLSTATE[40001]: Falha de serialização: 1213 Deadlock encontrado ao tentar obter o bloqueio; tente reiniciar a transação

para este comando:

INSERT INTO ClusterDescription (ClusterId, RightBarDateTime, InstrumentId)
 SELECT IFNULL(MAX(ClusterId) + 1, 1), :rightBarDateTime, :instrumentId
 FROM ClusterDescription WHERE InstrumentId = :instrumentId

• Pode haver até 50 acima de INSERT quase ao mesmo tempo.
• :instrumentIdnunca é o mesmo em nenhum dos comandos paralelos.
• Verificando a lista de processos vejo muitos desses comandos esperando para serem executados com um Timevalor > 30 segundos.
• Eu configurei innodb_lock_wait_timeoutpara 360 segundos, o que melhorou a situação. Antes de receber muitos dos erros mencionados acima e este erro:

SQLSTATE[HY000]: Erro geral: 1205 Tempo limite de espera de bloqueio excedido; tente reiniciar a transação

Minhas perguntas:

• O que há de errado com esta definição de tabela?

• Por que os comandos paralelos INSERT precisam de mais de 50 segundos para serem executados?

• Por que recebo um dead lockerro quando apenas 1 tabela é afetada?

Executando no MySQL 8.0.13

Eu preciso do InnoDBmotor por causa do índice descendente.

Eu tenho essa pergunta feita, mas depois de uma investigação mais profunda, percebi que o enforcamento não é o problema. Depois de ler este tópico , decidi fazer uma nova pergunta.

Por exemplo, passo essa string para a mysql_query()função:

SELECT 1

Quando executo vários milhares desse comando mysql_query(), o comando NÃO é enviado ao servidor MySQL!

Verifiquei o arquivo de log do MySQL e não acreditei, mas o comando não estava lá e, portanto mysql_query(), nunca retorna porque não recebe nenhuma resposta do servidor.

O MySql está gravando o comando no arquivo de log ANTES de ser executado. Eu tentei com SELECT SLEEP(10).

Observação:

Eu sei, isso significa muito, mas funcionou por 3 anos sem nenhum problema no SLES 11.3/XenServer 6.5. Nota: Este é um MCVE onde não funciona tão bem!

Desde que o mudei para o SLES 12.3 e XenServer 7.4, os problemas começaram.

O código C++ é muito simples - eu o verifiquei por 3 semanas antes de escrever esta pergunta. O ponto é que esse problema começa após ~ 10 mil consultas. A VM ainda tem ~ 3 GB de RAM livre.

Nota sobre um MCVE:

Criei um MCVE que funciona para mais de 500k execuções do comando MySQL.

Quando insiro este código MCVE no meu projeto e comento o meu existente main()para executar a função principal do MCVE, depois de alguns milhares [ou mesmo apenas centenas] de execuções, de repente o comando MySQL não é enviado novamente ao servidor MySQL.

Para ser mais específico: Somente objetos estáticos do meu projeto são inicializados antes da execução do MCVE incorporado.

Isso deve ser algo muito estranho em relação a essas inicializações estáticas porque nenhuma outra linha de código está sendo executada.

Pergunta:

alguma ideia do que está acontecendo? Especialmente o fato de que o comando aparentemente [por que eu deveria duvidar do arquivo de log do MySQL Server] não enviado do cliente C API para o servidor MySQL está realmente me incomodando.

Dados técnicos:

• SLES 12.3 rodando no XenServer 7.4 como VM
• Compilado com gcc7.3 usando -std=c++17e quase todas as opções de aviso.
• Usando o SLES 12.3 glibc 2.22 padrão com todas as atualizações do SLES instaladas.
• Conectando-se ao MySQL Community Server 5.7.21
• Cliente API C 5.7.21

Ao executar o mysql rpm mysql-community-server-5.7.14-1.sles12.x86_64.rpm, recebo este erro:

sed: -e expressão #1, char 17: opção desconhecida para `s'

Até aí tudo funciona, mas notei imediatamente após a atualização que havia 712 MB! less no disco do sistema e suspeito que o processo de limpeza não funcionou bem por causa do erro.

Minha pergunta:

1. Alguém tem uma ideia de como corrigir o problema, mesmo que seja um arquivo rpm que baixei diretamente do MySQL?
2. Onde posso remover manualmente os arquivos temporários criados durante o processo de atualização?

Informações:

Linux: SLES 12 SP1

MySQL: 5.7.14

Esclarecimento:

Não quero saber o que significa o problema no sedprograma. Não tenho acesso aos parâmetros [ nãosed escrevi; é entregue pela organização MySQL] devido ao fato de ser executado pelo rpmprograma controlado pelo arquivo rpm.

De acordo com a página de download do MySQL para o MySQL Community Server , existem apenas binários disponíveis para SLES 12.

Minha pergunta é se o MySQL Community Server 5.7.11[e superior] é compatível SLES 11 SP3quando eu compilo o MySQL sozinho?