Início / user-154486

Dinesh Kumar's questions

Martin Hope
Dinesh Kumar
Asked: 2019-04-29 23:38:29 +0800 CST
  • 4

No mysql 5.6 , considere estes 2 exemplos criando relacionamentos entre A, B, C e D.

Exemplo 1

CREATE TABLE `a` (
    id INT UNSIGNED NOT NULL,
    PRIMARY KEY (id)
) ENGINE = INNODB;

CREATE TABLE `b` (
    id INT UNSIGNED NOT NULL,
    a INT UNSIGNED NOT NULL,
    PRIMARY KEY (id),
    FOREIGN KEY (a) REFERENCES a (id) ON DELETE CASCADE
) ENGINE = INNODB;

CREATE TABLE `c` (
    id INT UNSIGNED NOT NULL,
    a INT UNSIGNED NOT NULL,
    PRIMARY KEY (id),
    FOREIGN KEY (a) REFERENCES a (id) ON DELETE CASCADE
) ENGINE = INNODB;

CREATE TABLE `d` (
    id INT UNSIGNED NOT NULL,
    b INT UNSIGNED NOT NULL,
    c INT UNSIGNED NOT NULL,
    PRIMARY KEY (id),
    FOREIGN KEY (id) REFERENCES b (id) ON DELETE CASCADE,
    FOREIGN KEY (id) REFERENCES c (id) ON DELETE RESTRICT
) ENGINE = INNODB;

INSERT INTO a VALUES (1);
INSERT INTO b VALUES (1, 1);
INSERT INTO c VALUES (1, 1);
INSERT INTO d VALUES (1, 1, 1);

DELETE FROM a;

O resultado é que todas as linhas são excluídas.

Exemplo 2

CREATE TABLE `a` (
    id INT UNSIGNED NOT NULL,
    PRIMARY KEY (id)
) ENGINE = INNODB;

CREATE TABLE `b` (
    id INT UNSIGNED NOT NULL,
    a INT UNSIGNED NOT NULL,
    PRIMARY KEY (id),
    FOREIGN KEY (a) REFERENCES a (id) ON DELETE CASCADE
) ENGINE = INNODB;

CREATE TABLE `c` (
    id INT UNSIGNED NOT NULL,
    a INT UNSIGNED NOT NULL,
    PRIMARY KEY (id),
    FOREIGN KEY (a) REFERENCES a (id) ON DELETE CASCADE
) ENGINE = INNODB;

CREATE TABLE `d` (
    id INT UNSIGNED NOT NULL,
    b INT UNSIGNED NOT NULL,
    c INT UNSIGNED NOT NULL,
    PRIMARY KEY (id),
    FOREIGN KEY (id) REFERENCES b (id) ON DELETE RESTRICT,
    FOREIGN KEY (id) REFERENCES c (id) ON DELETE CASCADE
) ENGINE = INNODB;

INSERT INTO a VALUES (1);
INSERT INTO b VALUES (1, 1);
INSERT INTO c VALUES (1, 1);
INSERT INTO d VALUES (1, 1, 1);

DELETE FROM a;

Observe que a única diferença é a mudança de qual chave estrangeira é RESTRICT de d . Este exemplo, no entanto, falha com

Código de erro: 1451 Não é possível excluir ou atualizar uma linha pai: uma restrição de chave estrangeira falha ( hello. d, CONSTRAINT d_ibfk_1FOREIGN KEY ( id) REFERENCES b( id))

Embora logicamente, seja o mesmo que o Exemplo 1 . Sem ter olhado o código-fonte do MySQL , suspeito fortemente que as chaves estrangeiras são "aplicadas" em ordem lexical com base em seu nome. Qual será o comportamento padrão (ANSI-SQL) neste cenário?

mysql foreign-key
Martin Hope
Dinesh Kumar
Asked: 2018-11-22 04:15:56 +0800 CST
  • 1

Eu posso imaginar como as linhas serão organizadas em uma única página de banco de dados como ordem de chave primária (por exemplo, uma chave de incremento automático) depois de ler este post . Mas eu me pergunto como será no caso de chaves primárias compostas. Por exemplo, considere a pk(a integer, b integer), se as linhas estão organizadas por coluna a ou por coluna b na página do banco de dados?

mysql database-internals
Martin Hope
Dinesh Kumar
Asked: 2018-11-10 02:46:32 +0800 CST
  • 3

Eu estava experimentando com texto e varchars no mysql 5.7. Eu crio uma tabela mysql simples como abaixo

CREATE TABLE small_table(
   pkint(11) NOT NULL AUTO_INCREMENT,
   varcvarchar(255) DEFAULT NULL,
   txttext,
  CHAVE PRIMÁRIA ( pk)
) ENGINE=InnoDB AUTO_INCREMENT=103925 DEFAULT CHARSET=utf8

A tabela tem cerca de 100 mil linhas.

Eu executei as consultas abaixo e perfilei as duas

Consulta 1 (Agrupar por na coluna varchar)

selecione varc,count(*) do grupo small_table por varc;

Resultado do perfil 1

+-----------+----------+
| Situação | Duração |
+-----------+----------+
| começando | 0,000064 |
| verificando permissões | 0,000004 |
| Mesas de abertura | 0,004812 |
| iniciar | 0,000026 |
| Bloqueio do sistema | 0,000005 |
| otimizando | 0,000006 |
| estatísticas | 0,000010 |
| preparando | 0,000006 |
| Criando tabela tmp | 0,000021 |
| Resultado da ordenação | 0,000003 |
| executando | 0,000001 |
| Envio de dados | 0,052795 |
| Criando índice de classificação | 0,000049 |
| fim | 0,000003 |
| fim da consulta | 0,000006 |
| removendo a tabela tmp | 0,000004 |
| fim da consulta | 0,000002 |
| mesas de fechamento | 0,000006 |
| libertar artigos | 0,000021 |
| limpeza | 0,000018 |
+-----------+----------+

Detalhes da tabela temporária 1

+--------------+-------+
| Nome_variável | Valor |
+--------------+-------+
| Created_tmp_disk_tables | 0 |
| Created_tmp_tables | 1 |
+--------------+-------+

Consulta 2 (Agrupar por na coluna de texto)

selecione txt,count(*) do grupo small_table por txt;

Resultado do perfil 2

+----------------------+-----------+
| Situação | Duração |
+----------------------+-----------+
| começando | 0,000134 |
| verificando permissões | 0,000010 |
| Mesas de abertura | 0,006690 |
| iniciar | 0,000034 |
| Bloqueio do sistema | 0,000007 |
| otimizando | 0,000004 |
| estatísticas | 0,000017 |
| preparando | 0,000008 |
| Criando tabela tmp | 0,000027 |
| Resultado da ordenação | 0,000005 |
| executando | 0,000002 |
| Envio de dados | 26.359877 |
| Criando índice de classificação | 0,001042 |
| fim | 0,000007 |
| fim da consulta | 0,000007 |
| removendo a tabela tmp | 0,000208 |
| fim da consulta | 0,000003 |
| mesas de fechamento | 0,000007 |
| libertar artigos | 0,000028 |
| limpeza | 0,000020 |
+----------------------+-----------+

Detalhes da tabela temporária 2

+--------------+-------+
| Nome_variável | Valor |
+--------------+-------+
| Created_tmp_disk_tables | 1 |
| Created_tmp_tables | 1 |
+--------------+-------+

Ambos os perfis levaram quase o mesmo tempo em cada estágio, exceto 'Enviando estágio de dados'. Para o primeiro levou 0,052795s e para o segundo levou 26,359877s. Por que há tanta diferença nessa fase? (mesmas consultas sem agrupar por cláusula não mostram diferença em 'Enviando estágio de dados')

performance mysql-5.7
Martin Hope
Dinesh Kumar
Asked: 2018-11-10 01:20:29 +0800 CST
  • 0

Eu tenho uma tabela com 100k linhas

CREATE TABLE `small_table` (
  `pk` int(11) NOT NULL AUTO_INCREMENT,
  `varc` varchar(255) DEFAULT NULL,
  texto `txt`,
  CHAVE PRIMÁRIA (`pk`)
) ENGINE=InnoDB AUTO_INCREMENT=103925 DEFAULT CHARSET=utf8

e eu executei a seguinte consulta

selecione varc,count(*) do grupo small_table por varc;

e eu tinha perfilado o mesmo

+-----------+----------+
| Situação | Duração |
+-----------+----------+
| começando | 0,000060 |
| verificando permissões | 0,000010 |
| Mesas de abertura | 0,004685 |
| iniciar | 0,000025 |
| Bloqueio do sistema | 0,000006 |
| otimizando | 0,000002 |
| estatísticas | 0,000010 |
| preparando | 0,000006 |
| Criando tabela tmp | 0,000020 |
| Resultado da ordenação | 0,000003 |
| executando | 0,000005 |
| Envio de dados | 0,001720 |
| Criando índice de classificação | 0,000033 |
| fim | 0,000002 |
| fim da consulta | 0,000004 |
| removendo a tabela tmp | 0,000004 |
| fim da consulta | 0,000002 |
| mesas de fechamento | 0,000004 |
| libertar artigos | 0,000015 |
| limpeza | 0,000007 |
+-----------+----------+

O perfil tem Criando o estado da tabela tmp (por documentos do mysql, significa que uma tabela tmp é criada na memória ou no disco). Minha dúvida é que o perfil não tem Copiando para o estado da tabela tmp (durante o estado, O servidor estará copiando para uma tabela temporária na memória.) Minha suposição é que ele tenha criado uma tabela tmp e não a esteja utilizando. Estou certo?

Onde está meu estado Copiando para a tabela tmp ?

mysql performance
Martin Hope
Dinesh Kumar
Asked: 2018-09-13 22:56:23 +0800 CST
  • 3

Aqui está a situação:

  1. Eu encontrei vários posts para " utf8_bin vs utf8_general_ci ".
  2. Da mesma forma, " utf8_general_cs vs utf8_general_ci ".

Mas não consigo encontrar um post para " utf8_bin vs utf8_general_cs ". Então, eles são iguais? Se não, qual a diferença entre eles?

Nota: verifiquei que utf8_general_cs não está disponível no MySQL padrão. Posso saber porquê?

mysql collation
Martin Hope
Dinesh Kumar
Asked: 2018-09-03 22:08:22 +0800 CST
  • 0

Eu preciso de alguns insights sobre o bloqueio de nível de linha no Postgres .

  1. Quantos bloqueios compartilhados (FOR SHARE) podem estar simultaneamente em uma tupla específica em uma relação.
  2. Terá muitos bloqueios compartilhados na mesma tupla, causando qualquer desempenho/ou qualquer problema no banco de dados.
  3. Caso existam tais limitações, como configurá-las e limites aconselháveis.
postgresql locking
Martin Hope
Dinesh Kumar
Asked: 2018-09-02 02:17:06 +0800 CST
  • 3

Eu tenho uma tabela chamada 'carro'

              Tabela "db145004db.car"
  Coluna | Tipo | Agrupamento | Anulável | Predefinição
----------+--------+-----------+----------+------- --
 carro_no | bigint | | não nulo |
 nome_carro | texto | | |
Índices:
    CHAVE PRIMÁRIA "car_pkey", btree (car_no)

Conteúdo da tabela:

carro_no | car_name  
--------+------------
      1 | primeiro carro
      2 | segundo_carro
      3 | third_car

Eu executei isso após duas transações,

Transação 1:

começar ;
selecione * do carro onde car_no=2 para atualização;

Transação 2:

começar ;
selecione * do carro onde car_no=2 para atualização; (aguardando a primeira transação liberar o bloqueio)

Minha tabela 'pg_locks' se parece com:

  tipo de bloqueio | banco de dados | relação | página | tupla | virtualxid | ID de transação | classid | objid | objsubid | transação virtual | pid | modo | concedido | atalho
---------------+----------+----------+------+----- --+------------+---------------+---------+-------+ ----------+--------------------+-------+---------- ------------+-------------+----------
 relação | 103777 | 143022 | | | | | | | | 4/75 | 11043 | AccessShareLock | t | t
 relação | 103777 | 143016 | | | | | | | | 4/75 | 11043 | RowShareLock | t | t
 virtualxid | | | | | 4/75 | | | | | 4/75 | 11043 | Bloqueio exclusivo | t | t
 relação | 103777 | 143022 | | | | | | | | 5/144 | 11150 | AccessShareLock | t | t
 relação | 103777 | 143016 | | | | | | | | 5/144 | 11150 | RowShareLock | t | t
 virtualxid | | | | | 5/144 | | | | | 5/144 | 11150 | Bloqueio exclusivo | t | t
 relação | 103777 | 11577 | | | | | | | | 3/141 | 11263 | AccessShareLock | t | t
 virtualxid | | | | | 3/141 | | | | | 3/141 | 11263 | Bloqueio exclusivo | t | t
 ID de transação | | | | | | 10204 | | | | 5/144 | 11150 | ShareLock | f | f
 tupla | 103777 | 143016 | 0 | 2 | | | | | | 5/144 | 11150 | AcessoExclusivoBloqueio | t | f
 ID de transação | | | | | | 10204 | | | | 4/75 | 11043 | Bloqueio exclusivo | t | f

Não consigo ver nenhum bloqueio relacionado a linhas/tuplas (car_no=2). Além disso, locktype e mode são um pouco confusos (não consigo entender o que eles tendem a transmitir). Como um novato no psql, estou totalmente confuso. Alguém pode ajudar a interpretar 'pg_locks', com relação ao bloqueio de nível de linha, em relação ao cenário acima.

postgresql locking
Martin Hope
Dinesh Kumar
Asked: 2018-08-28 05:54:14 +0800 CST
  • 6

Recentemente me deparei com esse comportamento estranho no Postgres. Eu tinha uma tabela como a seguinte:

sasdb=# \d emp_manager_rel
           Tabela "db3004db.emp_manager_rel"
   Coluna | Tipo | Agrupamento | Anulável | Predefinição
------------+--------+-----------+----------+----- ----
 emp_id | bigint | | |
 manager_id | bigint | | |

selecione * de emp_manager_rel ;
 emp_id | manager_id
--------+------------
      1 | 123

Executei a seguinte instrução de atualização:

ATUALIZAÇÃO 1:

atualizar emp_manager_rel set manager_id = manager_id+emp_id , emp_id=emp_id*4;

que atualizam a tabela como segue:

emp_id | manager_id
--------+------------
      4 | 124

ATUALIZAÇÃO 2: Executei a seguinte consulta (na tabela original, não na atualizada)

atualizar emp_manager_rel set emp_id=emp_id*4 , manager_id = manager_id+emp_id ;

ele atualiza a tabela da seguinte forma:

emp_id | manager_id
--------+------------
      4 | 124

Estou esperando que o valor de manager_id em UPDATE 2 seja 127 (porque emp_id foi alterado para 4 por empid * 4). Mas, ambas as ATUALIZAÇÕES produzem o mesmo resultado. Gostaria de saber qual será a ordem de execução da cláusula set no padrão ANSI.

postgresql update
Martin Hope
Dinesh Kumar
Asked: 2018-08-14 21:30:57 +0800 CST
  • 2

No MySQL 5.7

  1. alter table mydb.roles add constraint uk1 unique (role_name);

  2. alter table mydb.roles add constraint uk2 unique (role_name);

O 2º alter comando me lançou um aviso informando:

Índice duplicado 'uk2' definido na tabela 'world_x.roles'. Isso está obsoleto e não será permitido em uma versão futura.

Quando tentei o mesmo no Postgres(10.x), não me avisou.

Então, qual seria o padrão SQL nesse cenário?

mysql postgresql