Início / user-109917

yaki_nuka's questions

Martin Hope
yaki_nuka
Asked: 2025-02-13 19:58:58 +0800 CST
  • 5

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.

mysql
Martin Hope
yaki_nuka
Asked: 2024-11-06 23:54:58 +0800 CST
  • 6

Estou usando o MySQL 8.0.32. Tenho algumas perguntas sobre uma conversão interna, que não entendo. Além disso, às vezes essa conversão é mostrada em SHOW FULL PROCESSLIST, pois sua execução era muito longa.

Esta é a minha mesa.

CREATE TABLE `provinces` (
 `ID` VARCHAR(2) NOT NULL COLLATE 'utf8mb4_swedish_ci',
 `PROVINCIA` VARCHAR(45) NOT NULL COLLATE 'utf8mb4_swedish_ci',
  PRIMARY KEY (`ID`)
  ) COLLATE='utf8mb4_swedish_ci' ENGINE=InnoDB;

Eu tenho 53 linhas como essas

EU IA PROVÍNCIA
01 Álava
02 Albacete

A função MySQL é:

CREATE FUNCTION `get_provincia`( `id_provincia` VARCHAR(2)  )
RETURNS varchar(45)
LANGUAGE SQL
NOT DETERMINISTIC
READS SQL DATA
SQL SECURITY DEFINER
COMMENT ''
BEGIN
    DECLARE desc_provincia VARCHAR(45) DEFAULT '-';

    SELECT PROVINCIA INTO desc_provincia
    FROM provinces
    WHERE ID = id_provincia;
    
    RETURN desc_provincia;
END

O SHOW STATUS desta função mostra:

  • character_set_client: utf8mb4
  • conexão_de_agrupamento: utf8mb4_0900_ai_ci
  • database_collation: latin1_swedish_ci

Essa função é invocada como um campo em uma consulta.

SELECT customer_id, customer_name, ..., get_provincia(SUBSTRING(zip_code,1,2))...
FROM ...

Quando estou revisando a execução com SHOW FULL PROCESSLIST, a consulta dentro da função é mostrada assim:

SELECT provincia INTO desc_provincia
FROM provincias
WHERE id =  NAME_CONST('id_provincia',_latin1'15' COLLATE 'latin1_swedish_ci')

Então, eu tenho essas perguntas:

  1. Por que o NAME_CONST é forçado pelo MySQL?
  2. Isso tem impacto no desempenho? Não entendo que uma consulta muito simples mostre o valor "2" na coluna "Time" do comando SHOW FULL PROCESSLIST, pois demora 2 segundos.

Desde já, obrigado.

mysql
Martin Hope
yaki_nuka
Asked: 2018-06-05 07:53:27 +0800 CST
  • 0

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