Perguntas[mysql](dba)

Preciso de ajuda com isso...

Dentro de uma tabela "posts", tenho duas colunas onde preciso extrair/mover um valor de um campo para outro e mesclá-lo com o valor existente.

Table name: posts
-------------------
post_title       | post_name
-------------------------------
Title            | ashgt-36548
Some title       | ahrgz-46587
Some other title | kkahe-55486

Os valores de post_name estão todos no mesmo formato: 5 letras com um traço "-" e cerca de 5 dígitos (-DIGITS).

Então o que preciso ganhar é:

Remova "-DIGITS" de post_name e injete isso no campo post_title (mesclar valores) no início (primeira posição), remova o "-" e coloque o número de 5 dígitos entre colchetes [DIGITS]+SPACE

Então o resultado deve ser parecido com:

Table name: posts
--------------------------------------
post_title               | post_name
--------------------------------------
[36548] Title            | ashgt
[46587] Some title       | ahrgz
[55486] Some other title | kkahe

A sintaxe SQL que tenho até agora para remover o traço e os dígitos de post_name é (eu seleciono por meio de outra coluna "maschinen"):

UPDATE posts
SET `post_name`= mid(`post_name`, 1,length(`post_name`)-6)
WHERE `post_name` LIKE '%-%' AND `post_type` LIKE 'maschinen';

Qualquer ajuda sobre isso seria ótima. Obrigado.

Tenho um script de tarefa cron de manutenção que é executado a cada 5 minutos que TRUNCA uma tabela, a preenche novamente com dados de manutenção e, em seguida, a TRUNCA no final. Também executo um script mysqldump diário que faz backup de todas as minhas tabelas. Percebi recentemente que algumas das tabelas estavam faltando no backup. Após uma investigação mais aprofundada, descobri que o mysqldump está gerando este erro:

Error 1412 "Table Definition Has Changed"

Depois de investigar mais a fundo, aparentemente o problema é porque meu script de tarefa cron está usando TRUNCATE para esvaziar a tabela no meio de um backup do mysqldump.

Estou usando a opção --single-transaction, mas isso não faz diferença.

Existe alguma maneira de permitir que o mysqldump continue mesmo se uma tabela for truncada enquanto o mysqldump estiver em execução (e ainda fazer backup dessa tabela)? Isso precisa ser feito sem a opção --ignore-table. Descobri como fazer isso, mas prefiro incluir todas as minhas tabelas de manutenção no backup, caso o banco de dados precise ser completamente restaurado de um backup.

A única outra coisa que consegui pensar foi usar "DELETE FROM table" em vez de "TRUNCATE table", mas eu teria que passar por todos os meus scripts em todos os meus sites para mudar isso.

Quero registrar consultas em apenas uma tabela.

Eu encontrei estes

SET GLOBAL log_output = "FILE"; which is set by default.
SET GLOBAL general_log_file = "/path/to/your/logfile.log";
SET GLOBAL general_log = 'ON';

No entanto, isso registra todas as consultas.

Há perguntas no SO, mas elas são para registro total.

Como mostrar as últimas consultas executadas no MySQL?

Registre todas as consultas no mysql

Estou executando o MySql5.7 com o registro de consulta lenta habilitado, e o registro inclui mais metadados do que o mencionado nos documentos; estas três linhas são impressas antes de cada consulta:

# Time: 2025-02-18T14:25:16.286041Z
# User@Host: root[root] @ localhost []  Id: 261083
# Query_time: 3.677193  Lock_time: 0.001193 Rows_sent: 1  Rows_examined: 4334365

Os documentos explicam apenas a terceira linha:

cada declaração escrita no log é precedida por uma linha que começa com um caractere # e tem estes campos (com todos os campos em uma única linha):

• Tempo de consulta
• Tempo de bloqueio
• Linhas_enviadas
• Linhas_examinadas

Das outras duas linhas, a maioria dos campos são óbvios; mas alguém sabe o que o campo Id representa? Ele é diferente para a maioria das entradas no meu log lento, mas em alguns casos há vários que têm o mesmo Id.

Tenho usado o comando "mysql" do console Unix há algum tempo. É mais conveniente para agendar tarefas ou iniciá-las sem supervisão.

O esboço de um script .sh para isso é:

#!/bin/bash

#DB Config
USR_BD=myUsr
PWD_BD=myPass
IP_BD=x.x.x.x

f_exec ()
{
echo `date` ' -> Executing sql file ' $1

mysql -h $IP_BD -u $USR_BD -p$PWD_BD my_schema < $1

echo `date` ' -> Executed sql file ' $1
}

f_exec my_sentences.sql

O problema é que passei por uma verificação de segurança e eles me disseram que não posso salvar a senha clara em uma variável ou em um arquivo de texto simples dentro de um script .sh

Minha pergunta é: como posso resolver esse problema?

• Se você puder salvar algo como um token, o token apresentará o mesmo problema que a senha.
• Se você der permissão para conectar sem senha ao host no qual eu executo o script, se você obtiver acesso a esse host, você também obterá acesso ao banco de dados.

Claro, é óbvio que não vou conectar às 3 da manhã para digitar a senha para executar o script. Ou esperar online por uma consulta pesada de 10 minutos.

Não sei como resolver a situação. Obrigado.

Eu estava enfrentando esse problema em uma instância de produção e tentei uma recriação local em pequena escala e consegui.

Eu tenho uma tabela de teste simples

CREATE TABLE `test` (
  `id` int unsigned NOT NULL AUTO_INCREMENT,
  `val` varchar(255) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `index2` (`val`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci

Estou usando a versão Mysql 8.0.26com um innodbmecanismo de armazenamento

Preenchi esta tabela com cerca de 4 milhões de linhas aleatórias. Selecionar 5000 linhas desta tabela leva cerca de 50 ms. Em seguida, apaguei todas as linhas usandoDELETE FROM test;

Após excluir todas as linhas, se eu executar SELECT * FROM test LIMIT 5000;essa consulta, ela agora leva mais de 1 minuto para ser executada. Quando a consulta select finalmente termina de ser executada, ela retorna 0 linhas (como esperado).

Antes de prosseguir, quero esclarecer que entendo que executar um optimize tableresolverá o problema, mas estou interessado em entender o que realmente está acontecendo nos bastidores. Aqui estão alguns pensamentos que tive

1. Depois de cerca de uma hora, a consulta se torna instantânea novamente. Isso me leva a acreditar que algum tipo de coleta de lixo ou limpeza está acontecendo por baixo dos panos. Não consigo encontrar nada sobre isso nos documentos.
2. A consulta fica significativamente mais lenta após a exclusão. Como não estou usando nenhuma cláusula não indexada na minha consulta select, ela foi resolvida em cerca de 50 ms antes da exclusão, então, de alguma forma, é 1500x mais lenta após a exclusão.
3. Eu pesquisei o conceito de "registros fantasmas", no entanto, todos os resultados que consigo encontrar estão falando apenas sobre o SQL Server em vez do Mysql, o que me leva a acreditar que o conceito de "registros fantasmas" pode não ser uma coisa no Mysql. Não consigo encontrar nenhuma menção nos documentos do Mysql sobre isso.

Eu tentei o log de consulta lenta e esperava ver um monte de dados escaneados, mesmo que tivessem sido excluídos (registros fantasmas), mas além da duração, não consigo ver nada estranho ou inesperado lá

# Time: 2025-02-11T10:29:24.510606Z
# User@Host: root[root] @  [172.17.0.1]  Id: 20978
# Query_time: 69.680895  Lock_time: 0.000135 Rows_sent: 0  Rows_examined: 0 Thread_id: 20978 Errno: 0 Killed: 0 Bytes_received: 0 Bytes_sent: 130 Read_first: 1 Read_last: 0 Read_key: 1 Read_next: 0 Read_prev: 0 Read_rnd: 0 Read_rnd_next: 0 Sort_merge_passes: 0 Sort_range_count: 0 Sort_rows: 0 Sort_scan_count: 0 Created_tmp_disk_tables: 0 Created_tmp_tables: 0 Start: 2025-02-11T10:28:14.829711Z End: 2025-02-11T10:29:24.510606Z
SET timestamp=1739269694;
select * from test
LIMIT 0, 5000;

Alguém pode explicar em detalhes o que exatamente está acontecendo aqui? Idealmente, as duas coisas que eu adoraria saber, se possível, são:

1. O que está realmente acontecendo?
2. É possível ver/diagnosticar esse problema olhando algumas estatísticas internas do Mysql? Algo como o status/information_schema/performance_schema do mecanismo innodb, por exemplo. Basicamente, algo que eu poderia olhar e dizer que uma tabela está tendo esse problema sem saber que uma exclusão acabou de ser executada

Aqui está a explicação do select -SELECT * FROM test LIMIT 5000

Antes de excluir (rápido 50 ms)

id, select_type, table, partitions, type, possible_keys, key, key_len, ref, rows, filtered, Extra
'1', 'SIMPLE', 'test', NULL, 'index', NULL, 'index2', '1022', NULL, '6958223', '100.00', 'Using index'

Após a exclusão (lento 69s) - Corri analyze table testpara atualizar as estatísticas antes de executar novamente a seleção e a explicação

id, select_type, table, partitions, type, possible_keys, key, key_len, ref, rows, filtered, Extra
'1', 'SIMPLE', 'test', NULL, 'index', NULL, 'index2', '1022', NULL, '1', '100.00', 'Using index'

Tenho uma tabela com ids e nomes de jogadores. Para cada rodada, a tabela será embaralhada, dividida ao meio e colocada lado a lado. O tratamento de quantidades desiguais de linhas em cada grupo não é o escopo desta questão.

A única coisa que preciso alcançar é (metade superior + metade inferior) OU (tabela a + tabela b) lado a lado. Em detalhes, tabela a como está + ambas as colunas de b sem nenhuma referência uma à outra - linha por linha.

preparei um violino simples:

https://dbfiddle.uk/vkahsaFj

Português: https://dbfiddle.uk/ASM405Co

Algumas referências:

https://stackoverflow.com/questions/7983369/how-do-i-combine-a-mysql-query-and-subquery-when-theres-multiple-rows

O resultado deve ser este:

Tentei todos os tipos de junções, tabelas temporárias, agrupamentos e assim por diante, sem sucesso.

Tenho as seguintes 2 dúvidas:

SELECT * FROM mytable
WHERE id=1;

e

SELECT * FROM mytable
WHERE id IN(1);

Supondo que mytableseja muito grande, estou interessado na diferença de desempenho para os 2 em tabelas muito grandes. Sei que IN() deve ser geralmente mais lento nos casos em que forneço uma lista de valores para ele, mas como IN(1) é equivalente ao caso =1 quando um item existe, o planejador/otimizador de consultas reconhece esse caso e lida com a sobrecarga de desempenho que geralmente existe? Existe alguma maneira de verificar isso além de cronometrar os resultados da consulta?

Para testes de compatibilidade, precisamos de uma lista completa de todos os tipos de dados disponíveis no MySQL v8.0, para garantir que um software de destino fora do ecossistema MySQL possa manipular corretamente todos os tipos de dados da fonte MySQL.

O ChatGPT me disse para tentar a seguinte consulta:

SELECT DISTINCT DATA_TYPE
FROM INFORMATION_SCHEMA.COLUMNS
ORDER BY DATA_TYPE;

Mas ele retorna apenas os tipos usados ​​na instância do MySQL à qual estamos nos conectando. Por exemplo, nossa consulta retornou 24 tipos, enquanto o ChatGPT me disse depois que o MySQL suporta 36 tipos no total.

Também consultamos o seguinte documento oficial online, mas ele não forneceu uma lista geral e também nos preocupamos que o documento possa não fornecer informações suficientes sobre a implementação.

• https://dev.mysql.com/doc/refman/8.0/en/data-types.html

Se quisermos descobrir isso programaticamente, dê-nos um exemplo.

Ou, se pudermos nos referir a um repositório de código aberto. Por favor, nos dê algumas dicas, pois não estamos familiarizados com os repositórios do mundo de código aberto.

Agradecemos muito quaisquer dicas e sugestões.

Estou tentando limpar o banco de dados MySQL e restaurar o SQL --no-data para abrir uma nova instalação do meu aplicativo da web. Também tentei SET FOREIGN_KEY_CHECKS = 0, depois TRUNCATE TABLE 'table', depois SET FOREIGN_KEY_CHECKS = 1. Ainda não consigo me livrar dos valores AUTO_INCREMENT. Sei que estou esquecendo de algo óbvio. Qual é a maneira mais fácil de limpar esses dados para que eu possa reinstalar uma versão nova? Obrigado.