sanjihan's questions

Estou sofrendo com lentidão no mysqldump/mariadb-dump.

Descobri que desabilitar autocommit, unique_checks and foreign_key_checksaumenta o desempenho da importação.

Eu faço isso adicionando dump.sqlantes

SET autocommit=0;SET unique_checks=0;SET foreign_key_checks=0;

e anexando

COMMIT;SET unique_checks=1;SET foreign_key_checks=1;

até o fim disso.

Acrescentar é trivial, mas ao acrescentar preciso fazer um acordo entre tempo ou espaço consumido.

Prependendo com

sed -i '0,/^/s//SET autocommit=0;SET unique_checks=0;SET foreign_key_checks=0;/' dump.sql

pode levar muito tempo para despejos grandes, mas cria um único arquivo.

cat <(echo "SET autocommit=0;SET unique_checks=0;SET foreign_key_checks=0;") dump.sql <(echo "COMMIT;SET unique_checks=1;SET foreign_key_checks=1;") > new-dump.sql"

É rápido, mas cria outro arquivo de despejo e, portanto, usa muito espaço (mesmo que seja apenas temporário)

É possível instruir mysqldump/maridb-dumppara acrescentar e acrescentar um texto personalizado ao dump quando ele estiver sendo criado?

Estou armazenando ips usando VARBINARY(16)tipo de dados. Eu gostaria de selecionar apenas os ips ipv4. É possível filtrar a coluna pelo comprimento usado em VARBINARY(ou VARCHAR)? Algo assim

SELECT INET6_NTOA(`ip`) from TABLE where BYTESLENGHT(`ip`) = 4

Eu gostaria de monitorar quantas vezes determinadas consultas são executadas. Dê uma olhada nas 3 consultas abaixo, a segunda e a terceira são escritas como declaração preparada.

SELECT COUNT(*) FROM TABLE1

UPDATE TABLE2 SET `last_parsed` = NOW() WHERE `id` = ?

SELECT 1 FROM TABLE2 WHERE (`last_parsed` IS NULL OR `last_parsed` < DATE_SUB(CURRENT_TIMESTAMP, INTERVAL 7 DAY)) AND `id` = ?

O mariadb/mysql dbms acompanha quantas vezes cada consulta é executada? Ele agrupa as declarações preparadas em uma listagem, de modo que, se idfor 10 ou 20, ambas apareçam na mesma categoria?

Eu gostaria de obter as últimas (ou últimas) linhas de uma tabela (chamada CONTENT) contendo mais de 10 milhões de linhas. A consulta contém junções em 2 outras tabelas e é extremamente lenta. Estas são as definições da tabela e minha consulta:

CREATE TABLE `USER` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `value` varchar(64) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY (`value`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=latin1;


CREATE TABLE `GUID` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `value` char(36) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `value` (`value`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=latin1;


CREATE TABLE `CONTENT` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `user_id` int(11) unsigned DEFAULT NULL,
  `guid_id` int(11) unsigned DEFAULT NULL,
  `timestamp` datetime DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `guid` (`guid_id`),
  KEY `user_id` (`user_id`),
  KEY `timestamp` (`timestamp`),

  CONSTRAINT `CONTENT_ibfk_4` FOREIGN KEY (`guid_id`) REFERENCES `GUID` (`id`) ON DELETE CASCADE ON UPDATE CASCADE,
  CONSTRAINT `CONTENT_ibfk_5` FOREIGN KEY (`user_id`) REFERENCES `USER` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

Consulta:

SELECT 
`CONTENT`.`id`,
`GUID`.`value` AS `guid_value`, 
`USER`.`value` AS `user_value` 
FROM `CONTENT`, `USER`, `GUID` 
WHERE `CONTENT`.`user_id` = `USER`.`id` 
AND `CONTENT`.`guid_id` = `GUID`.`id` 
ORDER BY `CONTENT`.`timestamp` DESC LIMIT 1
  # even without ORDER BY the query is slow as seen by explain command

Estes são os resultados do comando Explain copiado como INSERT:

+------+-------------+---------+--------+---------------+---------+---------+-----------------------------+-------+----------------------------------------------+
| id   | select_type | table   | type   | possible_keys | key     | key_len | ref                         | rows  | Extra                                        |
+------+-------------+---------+--------+---------------+---------+---------+-----------------------------+-------+----------------------------------------------+
|    1 | SIMPLE      | GUID    | index  | PRIMARY       | value   | 37      | NULL                        | 16329 | Using index; Using temporary; Using filesort |
|    1 | SIMPLE      | CONTENT | ref    | guid,user_id  | guid    | 5       | MANAGER.GUID.id             | 293   | Using where                                  |
|    1 | SIMPLE      | USER    | eq_ref | PRIMARY       | PRIMARY | 4       | MANAGER.CONTENT.user_id     | 1     |                                              |
+------+-------------+---------+--------+---------------+---------+---------+-----------------------------+-------+----------------------------------------------+

A consulta é inutilizável, então estou dividindo-a em 2 consultas. Primeiro, recupero o CONTENT.id de interesse e, segundo, coloco uma WHERE CONTENT.id = xcláusula adicional na instrução SELECT. Parece que na consulta original o otimizador MariaDB não entende que eu só preciso de 1 linha, então ele faz o produto cartesiano com cada linha na tabela GUID. Dividir a consulta em 2 subconsultas é o caminho a seguir? Alguém pode confirmar que a operação cartesiana do produto é de fato a operação que está causando problemas? (primeira linha de resultados do comando de explicação)

EXPLIQUE da consulta de Ricks:

+------+-------------+------------+--------+----------------------+-------------------+---------+-----------------------------+---------+-------------+
| id   | select_type | table      | type   | possible_keys        | key               | key_len | ref                         | rows    | Extra       |
+------+-------------+------------+--------+----------------------+-------------------+---------+-----------------------------+---------+-------------+
|    1 | PRIMARY     | <derived2> | ALL    | NULL                 | NULL              | NULL    | NULL                        | 2       |             |
|    1 | PRIMARY     | CONTENT    | eq_ref | PRIMARY,guid,user_id | PRIMARY           | 4       | c.id                        | 1       | Using where |
|    1 | PRIMARY     | USER       | eq_ref | PRIMARY              | PRIMARY           | 4       | MANAGER.CONTENT.user_id     | 1       |             |
|    1 | PRIMARY     | GUID       | eq_ref | PRIMARY              | PRIMARY           | 4       | MANAGER.CONTENT.guid_id     | 1       |             |
|    2 | DERIVED     | CONTENT    | index  | NULL                 | timestamp         | 6       | NULL                        | 9474301 | Using index |
+------+-------------+------------+--------+----------------------+-------------------+---------+-----------------------------+---------+-------------+

Uma abordagem possível para otimizar as consultas de pesquisa é (a) armazenar os registros que retêm dados que correspondem a diferentes relações/tabelas em (b) o mesmo arquivo → nas mesmas páginas. Dessa forma, uma junção pode ser executada muito mais rapidamente.

Eu pesquisei "co-clustering" e surpreendentemente poucos resultados apareceram. Não encontrei nada no MySQL, por exemplo. Há alguma indicação de que a Oracle o ofereceu há 10 anos. O co-clustering ainda é uma opção válida para otimização?

Por exemplo, você tem duas relações/tabelas:

• Employee (id, name, age, did)
• Department (did, location)

Uma consulta típica para a qual você otimiza talvez seja algo assim:

SELECT E.name, 
       E.age 
  FROM Employee E, 
       Department D 
 WHERE E.age = 25 
   AND E.did = D.did;

Se você tinha 1.000.000 de funcionários e todos eles têm entre 25 e 27, o melhor método de junção é provavelmente a junção por mesclagem ou junção por hash - ambos exigem várias verificações.

Agora, se você armazena tuplas/linhas de várias relações/tabelas na mesma página, você pode usar uma estrutura física que armazena um departamento com um determinado didjuntamente com funcionários com o mesmo did. Observe que essa junção requer muito menos E/S.

Estou tentando colocar em uma escala atributos redundantes e ganho de desempenho. Embora armazenar informações redundantes cause muitas anomalias, estou focando apenas no tamanho de um atributo redundante versus armazenar um ponteiro (ou referência) para outra tupla em uma tabela diferente.

Então, qual é o tamanho do ponteiro para uma tupla nos sistemas InnoDB Mysql? Descobri que MyISAM usa 6 bytes. É o mesmo para o InnoDB? Para referência, 6 bytes tornam o armazenamento de 3 SMALLINTs (2 bytes cada) em uma tabela separada inútil em termos de armazenamento. Talvez uma pergunta equivalente seria: qual é o tamanho de um endereço de registro?

Estou tendo problemas para entender por que um determinado conjunto de dependências funcionais não é mínimo. Temos uma relação R(A,B,C,D,E,F,G)com as seguintes dependências F:

1. A->CDE
2. B->FG
3. AB->CDEFG

A cobertura mínima de F é apenas a dependência 1 e 2. É intuitivo que os atributos CDEFG já sejam determinados por A e B separadamente. Portanto, nenhum novo atributo é determinado pela união de AB. Existe uma regra exata que determine que tal dependência (união de AB->CDEFG) seja redundante?

As regras de Armstrong listadas até agora no livro são:

    IR1 (reflexive rule): If X ⊇ Y, then X →Y.
    IR2 (augmentation rule): {X → Y} |=XZ → YZ. 
    IR3 (transitive rule): {X → Y, Y → Z} |=X → Z.

e

    IR4 (decomposition, or projective, rule): {X → YZ} |=X → Y. 
    IR5 (union, or additive, rule): {X → Y, X → Z} |=X → YZ. 
    IR6 (pseudotransitive rule): {X → Y, WY → Z} |=WX → Z.

Não tenho certeza de qual regra é responsável pela redundância de AB->CDEFG. A regra de união parece próxima, mas os atributos do lado esquerdo são listados como sendo os mesmos (ambos X), o que não posso dizer FD1 U FD2no meu caso.

Estou lendo um livro sobre bancos de dados e um capítulo dele fala sobre o gerenciador de buffer e suas estratégias de substituição.

Percebi que o DBMS interage diretamente com a memória, em vez de solicitar que o SO interaja com a memória virtual. Isso é correto? Como exatamente essa comunicação direta ocorre? Quanta memória o DBMS pode alocar? Eu nunca fui exposto a chamadas de função de baixo nível e adoraria ver algumas explicações e exemplos disso.

Obter esse tipo de informação é meio complicado de encontrar no google se você não souber as palavras-chave corretas para pesquisar.