1 Sempre use o tipo de dados adequado<\/strong><\/h2>\nUma das pr\u00e1ticas recomendadas mais importantes do MySQL \u00e9 usar tipos de dados com base na natureza dos dados. O uso de tipos de dados irrelevantes pode consumir mais espa\u00e7o ou causar erros.<\/p>\n
Por exemplo: Usar varchar (20) em vez do tipo de dados DATETIME para armazenar valores de data e hora levar\u00e1 a erros nos c\u00e1lculos relacionados \u00e0 data e hora. Al\u00e9m disso, \u00e9 poss\u00edvel que dados inv\u00e1lidos sejam armazenados.<\/p>\n
2 Use CHAR (1) sobre VARCHAR (1)<\/strong><\/h2>\nVARCHAR (1) leva bytes extras para armazenar informa\u00e7\u00f5es, portanto, se voc\u00ea inserir um \u00fanico caractere, \u00e9 melhor usar CHAR (1).<\/p>\n
3 Use o tipo de dados CHAR para armazenar apenas dados de comprimento fixo<\/strong><\/h2>\nPor exemplo: Se o comprimento dos dados for menor que 1000, usar char (1000) em vez de varchar (1000) consumir\u00e1 mais espa\u00e7o.<\/p>\n
4 Evite usar formatos de data regionais<\/strong><\/h2>\nAo usar o tipo de dados DATETIME ou DATE, sempre use o formato de data YYYY-MM-DD ou o formato de data ISO adequado para seu SQL Engine. Formatos regionais como DD-MM-AAAA ou MM-DD-AAAA n\u00e3o ser\u00e3o armazenados corretamente.<\/p>\n
5 Colunas de chave de \u00edndice<\/strong><\/h2>\n\u00c9 desej\u00e1vel que a consulta retorne o resultado rapidamente, portanto, certifique-se de indexar as colunas que s\u00e3o usadas nas cl\u00e1usulas JOIN.<\/p>\n
Caso voc\u00ea use a instru\u00e7\u00e3o UPDATE envolvendo mais de uma tabela, certifique-se de indexar todas as colunas que s\u00e3o usadas para unir as tabelas.<\/p>\n
6 N\u00e3o use fun\u00e7\u00f5es sobre colunas indexadas\u2026<\/strong><\/h2>\n\u2026 porque ent\u00e3o o \u00edndice perde sua finalidade.<\/p>\n
Por exemplo, suponha que voc\u00ea queira obter dados em que os dois primeiros caracteres do c\u00f3digo do cliente sejam AK. Escreva:<\/p>\n
SELECT columns FROM table WHERE customer_code like 'AK%'<\/code><\/p>\ne n\u00e3o escreva<\/p>\n
SELECT columns FROM table WHERE left (customer_code,2)='AK\u2019<\/code><\/p>\nPor qu\u00ea? O primeiro exemplo far\u00e1 uso do \u00edndice, o que resultar\u00e1 em um tempo de resposta mais r\u00e1pido.<\/p>\n
7 Use SQL SELECT * somente se necess\u00e1rio<\/strong><\/h2>\nSeguindo a lista das melhores pr\u00e1ticas do MySQL, n\u00e3o use cegamente SELECT * no c\u00f3digo. Se a tabela tiver muitas colunas, todas ser\u00e3o retornadas. Isso diminuir\u00e1 o tempo de resposta, especialmente se voc\u00ea enviar o resultado para um aplicativo front-end.<\/p>\n
Em vez disso, digite explicitamente os nomes das colunas que s\u00e3o realmente necess\u00e1rios.<\/p>\n
Nota: lembre-se de que todas as instru\u00e7\u00f5es SELECT requerem uma cl\u00e1usula WHERE.<\/p>\n
8 Use a cl\u00e1usula ORDER BY somente se necess\u00e1rio<\/strong><\/h2>\nSe voc\u00ea quiser mostrar o resultado no aplicativo front-end, deixe-o ORDER no conjunto de resultados. Se voc\u00ea fizer isso no SQL, o tempo de resposta pode ser mais lento no ambiente multiusu\u00e1rio.<\/p>\n
9 Escolha um Mecanismo de Banco de Dados adequado<\/strong><\/h2>\nSe voc\u00ea desenvolver um aplicativo que l\u00ea dados com mais frequ\u00eancia do que escreve (por exemplo, um mecanismo de pesquisa), escolha o mecanismo de armazenamento MyISAM.<\/p>\n
Escolher o mecanismo de armazenamento errado afetar\u00e1 o desempenho.<\/p>\n
10 Use a cl\u00e1usula EXISTS sempre que necess\u00e1rio<\/strong><\/h2>\nPara verificar a exist\u00eancia de dados, use a cl\u00e1usula EXISTS que \u00e9 mais r\u00e1pida no tempo de resposta. Por exemplo, use:<\/p>\n
If EXISTS(SELECT * from Table WHERE col=\u2019some value\u2019)<\/code><\/p>\nN\u00e3o use :<\/p>\n
If (SELECT count(*) from Table WHERE col=\u2019some value\u2019)>0<\/code><\/p>\n11 EXPLIQUE suas consultas SELECT<\/strong><\/h2>\nSe voc\u00ea usar a palavra-chave EXPLAIN, poder\u00e1 obter informa\u00e7\u00f5es sobre o que o MySQL est\u00e1 fazendo para executar sua consulta. Isso pode ajud\u00e1-lo a detectar problemas com suas estruturas de consulta ou tabela (por exemplo, gargalos).<\/p>\n
Uma consulta EXPLAIN resulta em mostrar quais \u00edndices est\u00e3o sendo utilizados, como a tabela est\u00e1 sendo verificada, classificada, etc.<\/p>\n
Tudo o que voc\u00ea precisa fazer \u00e9 adicionar a palavra-chave EXPLAIN na frente de uma consulta SELECT (de prefer\u00eancia complexa com jun\u00e7\u00f5es). Al\u00e9m disso, se voc\u00ea usar o phpmyadmin para isso, seus resultados ser\u00e3o mostrados em uma boa tabela.<\/p>\n
12 Use LIMIT 1 ao obter uma linha exclusiva<\/strong><\/h2>\n\u00c0s vezes, voc\u00ea sabe de antem\u00e3o que est\u00e1 procurando apenas uma linha ao consultar suas tabelas. Por exemplo, voc\u00ea pode estar buscando um registro exclusivo ou pode estar apenas verificando a exist\u00eancia de qualquer n\u00famero de registros que satisfa\u00e7am sua cl\u00e1usula WHERE.<\/p>\n
Nesses casos, voc\u00ea desejar\u00e1 usar a fun\u00e7\u00e3o limite do MySQL para aumentar o desempenho. Aqui est\u00e1 outra das melhores pr\u00e1ticas do MySQL: simplesmente adicione LIMIT 1 \u00e0 sua consulta. Dessa forma, o mecanismo de banco de dados n\u00e3o precisar\u00e1 percorrer toda a tabela ou \u00edndice. Ele ir\u00e1 parar de escanear quando encontrar apenas 1 registro do que voc\u00ea est\u00e1 procurando.<\/p>\n
\/\/ do I have anyusersfrom Alabama?<\/code><\/p>\n\/\/ o que N\u00c3O fazer:
\n$r = mysql_query(“SELECT * FROM user WHERE state = ‘Alabama’");
\nif (mysql_num_rows($r) > 0) {
\n\/\/ \u2026
\n}<\/p>\n
\/\/ muito melhor:
\n$r = mysql_query(“SELECT 1 FROM user WHERE state = ‘Alabama’ LIMIT 1");
\nif (mysql_num_rows($r) > 0) {
\n\/\/ \u2026
\n}<\/p>\n
13 Indexe e use os mesmos tipos de coluna para jun\u00e7\u00f5es<\/strong><\/h2>\nOutra dica vital das melhores pr\u00e1ticas do MySQL \u2013 se o seu aplicativo tiver muitas consultas JOIN, certifique-se de que as colunas pelas quais voc\u00ea une sejam indexadas em ambas as tabelas. Isso afeta a otimiza\u00e7\u00e3o interna da opera\u00e7\u00e3o de jun\u00e7\u00e3o pelo MySQL.<\/p>\n
Al\u00e9m disso, as colunas unidas precisam ser do mesmo tipo. Por exemplo, se voc\u00ea unir uma coluna DECIMAL a uma coluna INT de outra tabela, o MySQL n\u00e3o poder\u00e1 usar nenhum dos \u00edndices. Mesmo as codifica\u00e7\u00f5es de caracteres precisam ser do mesmo tipo para colunas do tipo string.<\/p>\n
\/\/ looking for companies in my state $r = mysql_query(\"SELECT company_name FROM users LEFT JOIN companies ON (users.state = companies.state) WHERE users.id = $user_id\");<\/code><\/p>\n\/\/ ambas as colunas de estado devem ser indexadas
\n\/\/ e ambas devem ser do mesmo tipo e codifica\u00e7\u00e3o de caracteres
\n\/\/ ou o MySQL pode fazer varreduras completas da tabela<\/p>\n
14 Ocultar o MySQL da Internet<\/strong><\/h2>\nAdministradores de banco de dados experientes e pessoal de seguran\u00e7a sabem disso \u2013 nunca hospede o banco de dados na raiz do servidor da Web.<\/p>\n
Para aplicativos habilitados para Web, o MySQL deve estar oculto atr\u00e1s de um firewall. A comunica\u00e7\u00e3o deve ser habilitada apenas entre servidores de aplicativos e seus servidores Web.<\/p>\n
Outra op\u00e7\u00e3o \u00e9 usar o MySQL skip-networking. Quando habilitado, o MySQL escuta apenas conex\u00f5es de soquetes locais e ignora todas as portas TCP.<\/p>\n
15 Use os menores tipos de dados poss\u00edveis<\/strong><\/h2>\n![\"22](\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-206970-61e8d4b73d55e.jpg\")
<\/a><\/p>\nDeixe-me te contar uma historia. Quando eu estava na faculdade, a filosofia era que “a mem\u00f3ria \u00e9 escassa”. Aqueles eram os dias de discos r\u00edgidos de 256 MB. Hoje em dia, ningu\u00e9m parece se importar nem um pouco com mem\u00f3ria ou espa\u00e7o no disco r\u00edgido. A nova filosofia \u00e9 que “a mem\u00f3ria \u00e9 barata”. Pode ser verdade em termos de d\u00f3lares, mas a leitura de tipos de dados grandes ainda leva mais tempo do que a leitura de tipos menores. Tipos de dados grandes exigem que mais setores de disco sejam lidos na mem\u00f3ria.<\/p>\n
A moral \u00e9: ignore a tenta\u00e7\u00e3o de pular imediatamente para o maior tipo de dados ao projetar suas tabelas. Pense em usar um int em vez de um bigint.<\/p>\n
Al\u00e9m disso, evite campos de texto largechar (255) quando um varchar ou um caractere menor for suficiente.<\/p>\n
Se voc\u00ea usar o tipo de dados correto, mais registros caber\u00e3o na mem\u00f3ria ou no bloco de chave de \u00edndice. Isso leva a menos leituras e desempenho mais r\u00e1pido.<\/p>\n
16 Aproveite o cache de consultas<\/strong><\/h2>\nO cache de consulta \u00e9 um dos m\u00e9todos mais eficazes para melhorar o desempenho. A maioria dos servidores MySQL tem habilitado por padr\u00e3o.<\/p>\n
O cache de consulta armazena o texto de uma instru\u00e7\u00e3o SELECT junto com o conjunto de resultados correspondente. Se o servidor receber posteriormente uma instru\u00e7\u00e3o id\u00eantica, ele recuperar\u00e1 os resultados do cache de consulta em vez de analisar e executar a instru\u00e7\u00e3o novamente. O cache de consulta \u00e9 compartilhado entre as sess\u00f5es, portanto, um conjunto de resultados gerado por um cliente pode ser enviado em resposta \u00e0 mesma consulta emitida por outro cliente.<\/p>\n
No entanto, por melhor que seja, o cache de consultas tem suas limita\u00e7\u00f5es. Tome a seguinte afirma\u00e7\u00e3o:<\/p>\n
O problema aqui \u00e9 que as consultas cont\u00eam certas fun\u00e7\u00f5es n\u00e3o determin\u00edsticas, como NOW() e RAND(). O MySQL n\u00e3o pode calcular essas fun\u00e7\u00f5es antecipadamente, ent\u00e3o elas acabam n\u00e3o sendo armazenadas em cache.<\/p>\n
Felizmente, existe uma solu\u00e7\u00e3o f\u00e1cil para isso: voc\u00ea pode armazenar os resultados da fun\u00e7\u00e3o em uma vari\u00e1vel.<\/p>\n
17 N\u00e3o edite arquivos de despejo<\/strong><\/h2>\nArquivos de despejo s\u00e3o muito enganadores e podem causar corrup\u00e7\u00e3o. Por qu\u00ea? Se voc\u00ea j\u00e1 viu os arquivos de despejo criados pelo mysqldump, voc\u00ea concordar\u00e1 que eles se parecem com arquivos de texto normais e inofensivos. \u00c9 por isso que a maioria das pessoas os edita em um editor de texto padr\u00e3o, o que faz com que apare\u00e7am corrup\u00e7\u00f5es.<\/p>\n
Se voc\u00ea j\u00e1 tentou editar arquivos de despejo, aprendeu rapidamente que eles s\u00e3o tudo menos um arquivo de texto. Portanto, a \u00fanica maneira garantida de evitar problemas \u00e9 deixar os arquivos de despejo em paz.<\/p>\n
18 Use a configura\u00e7\u00e3o de tamanho de bloco MyISAM<\/strong><\/h2>\n
VARCHAR (1) leva bytes extras para armazenar informa\u00e7\u00f5es, portanto, se voc\u00ea inserir um \u00fanico caractere, \u00e9 melhor usar CHAR (1).<\/p>\n
3 Use o tipo de dados CHAR para armazenar apenas dados de comprimento fixo<\/strong><\/h2>\nPor exemplo: Se o comprimento dos dados for menor que 1000, usar char (1000) em vez de varchar (1000) consumir\u00e1 mais espa\u00e7o.<\/p>\n
4 Evite usar formatos de data regionais<\/strong><\/h2>\nAo usar o tipo de dados DATETIME ou DATE, sempre use o formato de data YYYY-MM-DD ou o formato de data ISO adequado para seu SQL Engine. Formatos regionais como DD-MM-AAAA ou MM-DD-AAAA n\u00e3o ser\u00e3o armazenados corretamente.<\/p>\n
5 Colunas de chave de \u00edndice<\/strong><\/h2>\n\u00c9 desej\u00e1vel que a consulta retorne o resultado rapidamente, portanto, certifique-se de indexar as colunas que s\u00e3o usadas nas cl\u00e1usulas JOIN.<\/p>\n
Caso voc\u00ea use a instru\u00e7\u00e3o UPDATE envolvendo mais de uma tabela, certifique-se de indexar todas as colunas que s\u00e3o usadas para unir as tabelas.<\/p>\n
6 N\u00e3o use fun\u00e7\u00f5es sobre colunas indexadas\u2026<\/strong><\/h2>\n\u2026 porque ent\u00e3o o \u00edndice perde sua finalidade.<\/p>\n
Por exemplo, suponha que voc\u00ea queira obter dados em que os dois primeiros caracteres do c\u00f3digo do cliente sejam AK. Escreva:<\/p>\n
SELECT columns FROM table WHERE customer_code like 'AK%'<\/code><\/p>\ne n\u00e3o escreva<\/p>\n
SELECT columns FROM table WHERE left (customer_code,2)='AK\u2019<\/code><\/p>\nPor qu\u00ea? O primeiro exemplo far\u00e1 uso do \u00edndice, o que resultar\u00e1 em um tempo de resposta mais r\u00e1pido.<\/p>\n
7 Use SQL SELECT * somente se necess\u00e1rio<\/strong><\/h2>\nSeguindo a lista das melhores pr\u00e1ticas do MySQL, n\u00e3o use cegamente SELECT * no c\u00f3digo. Se a tabela tiver muitas colunas, todas ser\u00e3o retornadas. Isso diminuir\u00e1 o tempo de resposta, especialmente se voc\u00ea enviar o resultado para um aplicativo front-end.<\/p>\n
Em vez disso, digite explicitamente os nomes das colunas que s\u00e3o realmente necess\u00e1rios.<\/p>\n
Nota: lembre-se de que todas as instru\u00e7\u00f5es SELECT requerem uma cl\u00e1usula WHERE.<\/p>\n
8 Use a cl\u00e1usula ORDER BY somente se necess\u00e1rio<\/strong><\/h2>\nSe voc\u00ea quiser mostrar o resultado no aplicativo front-end, deixe-o ORDER no conjunto de resultados. Se voc\u00ea fizer isso no SQL, o tempo de resposta pode ser mais lento no ambiente multiusu\u00e1rio.<\/p>\n
9 Escolha um Mecanismo de Banco de Dados adequado<\/strong><\/h2>\nSe voc\u00ea desenvolver um aplicativo que l\u00ea dados com mais frequ\u00eancia do que escreve (por exemplo, um mecanismo de pesquisa), escolha o mecanismo de armazenamento MyISAM.<\/p>\n
Escolher o mecanismo de armazenamento errado afetar\u00e1 o desempenho.<\/p>\n
10 Use a cl\u00e1usula EXISTS sempre que necess\u00e1rio<\/strong><\/h2>\nPara verificar a exist\u00eancia de dados, use a cl\u00e1usula EXISTS que \u00e9 mais r\u00e1pida no tempo de resposta. Por exemplo, use:<\/p>\n
If EXISTS(SELECT * from Table WHERE col=\u2019some value\u2019)<\/code><\/p>\nN\u00e3o use :<\/p>\n
If (SELECT count(*) from Table WHERE col=\u2019some value\u2019)>0<\/code><\/p>\n11 EXPLIQUE suas consultas SELECT<\/strong><\/h2>\nSe voc\u00ea usar a palavra-chave EXPLAIN, poder\u00e1 obter informa\u00e7\u00f5es sobre o que o MySQL est\u00e1 fazendo para executar sua consulta. Isso pode ajud\u00e1-lo a detectar problemas com suas estruturas de consulta ou tabela (por exemplo, gargalos).<\/p>\n
Uma consulta EXPLAIN resulta em mostrar quais \u00edndices est\u00e3o sendo utilizados, como a tabela est\u00e1 sendo verificada, classificada, etc.<\/p>\n
Tudo o que voc\u00ea precisa fazer \u00e9 adicionar a palavra-chave EXPLAIN na frente de uma consulta SELECT (de prefer\u00eancia complexa com jun\u00e7\u00f5es). Al\u00e9m disso, se voc\u00ea usar o phpmyadmin para isso, seus resultados ser\u00e3o mostrados em uma boa tabela.<\/p>\n
12 Use LIMIT 1 ao obter uma linha exclusiva<\/strong><\/h2>\n\u00c0s vezes, voc\u00ea sabe de antem\u00e3o que est\u00e1 procurando apenas uma linha ao consultar suas tabelas. Por exemplo, voc\u00ea pode estar buscando um registro exclusivo ou pode estar apenas verificando a exist\u00eancia de qualquer n\u00famero de registros que satisfa\u00e7am sua cl\u00e1usula WHERE.<\/p>\n
Nesses casos, voc\u00ea desejar\u00e1 usar a fun\u00e7\u00e3o limite do MySQL para aumentar o desempenho. Aqui est\u00e1 outra das melhores pr\u00e1ticas do MySQL: simplesmente adicione LIMIT 1 \u00e0 sua consulta. Dessa forma, o mecanismo de banco de dados n\u00e3o precisar\u00e1 percorrer toda a tabela ou \u00edndice. Ele ir\u00e1 parar de escanear quando encontrar apenas 1 registro do que voc\u00ea est\u00e1 procurando.<\/p>\n
\/\/ do I have anyusersfrom Alabama?<\/code><\/p>\n\/\/ o que N\u00c3O fazer:
\n$r = mysql_query(“SELECT * FROM user WHERE state = ‘Alabama’");
\nif (mysql_num_rows($r) > 0) {
\n\/\/ \u2026
\n}<\/p>\n
\/\/ muito melhor:
\n$r = mysql_query(“SELECT 1 FROM user WHERE state = ‘Alabama’ LIMIT 1");
\nif (mysql_num_rows($r) > 0) {
\n\/\/ \u2026
\n}<\/p>\n
13 Indexe e use os mesmos tipos de coluna para jun\u00e7\u00f5es<\/strong><\/h2>\nOutra dica vital das melhores pr\u00e1ticas do MySQL \u2013 se o seu aplicativo tiver muitas consultas JOIN, certifique-se de que as colunas pelas quais voc\u00ea une sejam indexadas em ambas as tabelas. Isso afeta a otimiza\u00e7\u00e3o interna da opera\u00e7\u00e3o de jun\u00e7\u00e3o pelo MySQL.<\/p>\n
Al\u00e9m disso, as colunas unidas precisam ser do mesmo tipo. Por exemplo, se voc\u00ea unir uma coluna DECIMAL a uma coluna INT de outra tabela, o MySQL n\u00e3o poder\u00e1 usar nenhum dos \u00edndices. Mesmo as codifica\u00e7\u00f5es de caracteres precisam ser do mesmo tipo para colunas do tipo string.<\/p>\n
\/\/ looking for companies in my state $r = mysql_query(\"SELECT company_name FROM users LEFT JOIN companies ON (users.state = companies.state) WHERE users.id = $user_id\");<\/code><\/p>\n\/\/ ambas as colunas de estado devem ser indexadas
\n\/\/ e ambas devem ser do mesmo tipo e codifica\u00e7\u00e3o de caracteres
\n\/\/ ou o MySQL pode fazer varreduras completas da tabela<\/p>\n
14 Ocultar o MySQL da Internet<\/strong><\/h2>\nAdministradores de banco de dados experientes e pessoal de seguran\u00e7a sabem disso \u2013 nunca hospede o banco de dados na raiz do servidor da Web.<\/p>\n
Para aplicativos habilitados para Web, o MySQL deve estar oculto atr\u00e1s de um firewall. A comunica\u00e7\u00e3o deve ser habilitada apenas entre servidores de aplicativos e seus servidores Web.<\/p>\n
Outra op\u00e7\u00e3o \u00e9 usar o MySQL skip-networking. Quando habilitado, o MySQL escuta apenas conex\u00f5es de soquetes locais e ignora todas as portas TCP.<\/p>\n
15 Use os menores tipos de dados poss\u00edveis<\/strong><\/h2>\n<\/a><\/p>\nDeixe-me te contar uma historia. Quando eu estava na faculdade, a filosofia era que “a mem\u00f3ria \u00e9 escassa”. Aqueles eram os dias de discos r\u00edgidos de 256 MB. Hoje em dia, ningu\u00e9m parece se importar nem um pouco com mem\u00f3ria ou espa\u00e7o no disco r\u00edgido. A nova filosofia \u00e9 que “a mem\u00f3ria \u00e9 barata”. Pode ser verdade em termos de d\u00f3lares, mas a leitura de tipos de dados grandes ainda leva mais tempo do que a leitura de tipos menores. Tipos de dados grandes exigem que mais setores de disco sejam lidos na mem\u00f3ria.<\/p>\n
A moral \u00e9: ignore a tenta\u00e7\u00e3o de pular imediatamente para o maior tipo de dados ao projetar suas tabelas. Pense em usar um int em vez de um bigint.<\/p>\n
Al\u00e9m disso, evite campos de texto largechar (255) quando um varchar ou um caractere menor for suficiente.<\/p>\n
Se voc\u00ea usar o tipo de dados correto, mais registros caber\u00e3o na mem\u00f3ria ou no bloco de chave de \u00edndice. Isso leva a menos leituras e desempenho mais r\u00e1pido.<\/p>\n
16 Aproveite o cache de consultas<\/strong><\/h2>\nO cache de consulta \u00e9 um dos m\u00e9todos mais eficazes para melhorar o desempenho. A maioria dos servidores MySQL tem habilitado por padr\u00e3o.<\/p>\n
O cache de consulta armazena o texto de uma instru\u00e7\u00e3o SELECT junto com o conjunto de resultados correspondente. Se o servidor receber posteriormente uma instru\u00e7\u00e3o id\u00eantica, ele recuperar\u00e1 os resultados do cache de consulta em vez de analisar e executar a instru\u00e7\u00e3o novamente. O cache de consulta \u00e9 compartilhado entre as sess\u00f5es, portanto, um conjunto de resultados gerado por um cliente pode ser enviado em resposta \u00e0 mesma consulta emitida por outro cliente.<\/p>\n
No entanto, por melhor que seja, o cache de consultas tem suas limita\u00e7\u00f5es. Tome a seguinte afirma\u00e7\u00e3o:<\/p>\n
O problema aqui \u00e9 que as consultas cont\u00eam certas fun\u00e7\u00f5es n\u00e3o determin\u00edsticas, como NOW() e RAND(). O MySQL n\u00e3o pode calcular essas fun\u00e7\u00f5es antecipadamente, ent\u00e3o elas acabam n\u00e3o sendo armazenadas em cache.<\/p>\n
Felizmente, existe uma solu\u00e7\u00e3o f\u00e1cil para isso: voc\u00ea pode armazenar os resultados da fun\u00e7\u00e3o em uma vari\u00e1vel.<\/p>\n
17 N\u00e3o edite arquivos de despejo<\/strong><\/h2>\nArquivos de despejo s\u00e3o muito enganadores e podem causar corrup\u00e7\u00e3o. Por qu\u00ea? Se voc\u00ea j\u00e1 viu os arquivos de despejo criados pelo mysqldump, voc\u00ea concordar\u00e1 que eles se parecem com arquivos de texto normais e inofensivos. \u00c9 por isso que a maioria das pessoas os edita em um editor de texto padr\u00e3o, o que faz com que apare\u00e7am corrup\u00e7\u00f5es.<\/p>\n
Se voc\u00ea j\u00e1 tentou editar arquivos de despejo, aprendeu rapidamente que eles s\u00e3o tudo menos um arquivo de texto. Portanto, a \u00fanica maneira garantida de evitar problemas \u00e9 deixar os arquivos de despejo em paz.<\/p>\n
18 Use a configura\u00e7\u00e3o de tamanho de bloco MyISAM<\/strong><\/h2>\n
Ao usar o tipo de dados DATETIME ou DATE, sempre use o formato de data YYYY-MM-DD ou o formato de data ISO adequado para seu SQL Engine. Formatos regionais como DD-MM-AAAA ou MM-DD-AAAA n\u00e3o ser\u00e3o armazenados corretamente.<\/p>\n
5 Colunas de chave de \u00edndice<\/strong><\/h2>\n\u00c9 desej\u00e1vel que a consulta retorne o resultado rapidamente, portanto, certifique-se de indexar as colunas que s\u00e3o usadas nas cl\u00e1usulas JOIN.<\/p>\n
Caso voc\u00ea use a instru\u00e7\u00e3o UPDATE envolvendo mais de uma tabela, certifique-se de indexar todas as colunas que s\u00e3o usadas para unir as tabelas.<\/p>\n
6 N\u00e3o use fun\u00e7\u00f5es sobre colunas indexadas\u2026<\/strong><\/h2>\n\u2026 porque ent\u00e3o o \u00edndice perde sua finalidade.<\/p>\n
Por exemplo, suponha que voc\u00ea queira obter dados em que os dois primeiros caracteres do c\u00f3digo do cliente sejam AK. Escreva:<\/p>\n
SELECT columns FROM table WHERE customer_code like 'AK%'<\/code><\/p>\ne n\u00e3o escreva<\/p>\n
SELECT columns FROM table WHERE left (customer_code,2)='AK\u2019<\/code><\/p>\nPor qu\u00ea? O primeiro exemplo far\u00e1 uso do \u00edndice, o que resultar\u00e1 em um tempo de resposta mais r\u00e1pido.<\/p>\n
7 Use SQL SELECT * somente se necess\u00e1rio<\/strong><\/h2>\nSeguindo a lista das melhores pr\u00e1ticas do MySQL, n\u00e3o use cegamente SELECT * no c\u00f3digo. Se a tabela tiver muitas colunas, todas ser\u00e3o retornadas. Isso diminuir\u00e1 o tempo de resposta, especialmente se voc\u00ea enviar o resultado para um aplicativo front-end.<\/p>\n
Em vez disso, digite explicitamente os nomes das colunas que s\u00e3o realmente necess\u00e1rios.<\/p>\n
Nota: lembre-se de que todas as instru\u00e7\u00f5es SELECT requerem uma cl\u00e1usula WHERE.<\/p>\n
8 Use a cl\u00e1usula ORDER BY somente se necess\u00e1rio<\/strong><\/h2>\nSe voc\u00ea quiser mostrar o resultado no aplicativo front-end, deixe-o ORDER no conjunto de resultados. Se voc\u00ea fizer isso no SQL, o tempo de resposta pode ser mais lento no ambiente multiusu\u00e1rio.<\/p>\n
9 Escolha um Mecanismo de Banco de Dados adequado<\/strong><\/h2>\nSe voc\u00ea desenvolver um aplicativo que l\u00ea dados com mais frequ\u00eancia do que escreve (por exemplo, um mecanismo de pesquisa), escolha o mecanismo de armazenamento MyISAM.<\/p>\n
Escolher o mecanismo de armazenamento errado afetar\u00e1 o desempenho.<\/p>\n
10 Use a cl\u00e1usula EXISTS sempre que necess\u00e1rio<\/strong><\/h2>\nPara verificar a exist\u00eancia de dados, use a cl\u00e1usula EXISTS que \u00e9 mais r\u00e1pida no tempo de resposta. Por exemplo, use:<\/p>\n
If EXISTS(SELECT * from Table WHERE col=\u2019some value\u2019)<\/code><\/p>\nN\u00e3o use :<\/p>\n
If (SELECT count(*) from Table WHERE col=\u2019some value\u2019)>0<\/code><\/p>\n11 EXPLIQUE suas consultas SELECT<\/strong><\/h2>\nSe voc\u00ea usar a palavra-chave EXPLAIN, poder\u00e1 obter informa\u00e7\u00f5es sobre o que o MySQL est\u00e1 fazendo para executar sua consulta. Isso pode ajud\u00e1-lo a detectar problemas com suas estruturas de consulta ou tabela (por exemplo, gargalos).<\/p>\n
Uma consulta EXPLAIN resulta em mostrar quais \u00edndices est\u00e3o sendo utilizados, como a tabela est\u00e1 sendo verificada, classificada, etc.<\/p>\n
Tudo o que voc\u00ea precisa fazer \u00e9 adicionar a palavra-chave EXPLAIN na frente de uma consulta SELECT (de prefer\u00eancia complexa com jun\u00e7\u00f5es). Al\u00e9m disso, se voc\u00ea usar o phpmyadmin para isso, seus resultados ser\u00e3o mostrados em uma boa tabela.<\/p>\n
12 Use LIMIT 1 ao obter uma linha exclusiva<\/strong><\/h2>\n\u00c0s vezes, voc\u00ea sabe de antem\u00e3o que est\u00e1 procurando apenas uma linha ao consultar suas tabelas. Por exemplo, voc\u00ea pode estar buscando um registro exclusivo ou pode estar apenas verificando a exist\u00eancia de qualquer n\u00famero de registros que satisfa\u00e7am sua cl\u00e1usula WHERE.<\/p>\n
Nesses casos, voc\u00ea desejar\u00e1 usar a fun\u00e7\u00e3o limite do MySQL para aumentar o desempenho. Aqui est\u00e1 outra das melhores pr\u00e1ticas do MySQL: simplesmente adicione LIMIT 1 \u00e0 sua consulta. Dessa forma, o mecanismo de banco de dados n\u00e3o precisar\u00e1 percorrer toda a tabela ou \u00edndice. Ele ir\u00e1 parar de escanear quando encontrar apenas 1 registro do que voc\u00ea est\u00e1 procurando.<\/p>\n
\/\/ do I have anyusersfrom Alabama?<\/code><\/p>\n\/\/ o que N\u00c3O fazer:
\n$r = mysql_query(“SELECT * FROM user WHERE state = ‘Alabama’");
\nif (mysql_num_rows($r) > 0) {
\n\/\/ \u2026
\n}<\/p>\n
\/\/ muito melhor:
\n$r = mysql_query(“SELECT 1 FROM user WHERE state = ‘Alabama’ LIMIT 1");
\nif (mysql_num_rows($r) > 0) {
\n\/\/ \u2026
\n}<\/p>\n
13 Indexe e use os mesmos tipos de coluna para jun\u00e7\u00f5es<\/strong><\/h2>\nOutra dica vital das melhores pr\u00e1ticas do MySQL \u2013 se o seu aplicativo tiver muitas consultas JOIN, certifique-se de que as colunas pelas quais voc\u00ea une sejam indexadas em ambas as tabelas. Isso afeta a otimiza\u00e7\u00e3o interna da opera\u00e7\u00e3o de jun\u00e7\u00e3o pelo MySQL.<\/p>\n
Al\u00e9m disso, as colunas unidas precisam ser do mesmo tipo. Por exemplo, se voc\u00ea unir uma coluna DECIMAL a uma coluna INT de outra tabela, o MySQL n\u00e3o poder\u00e1 usar nenhum dos \u00edndices. Mesmo as codifica\u00e7\u00f5es de caracteres precisam ser do mesmo tipo para colunas do tipo string.<\/p>\n
\/\/ looking for companies in my state $r = mysql_query(\"SELECT company_name FROM users LEFT JOIN companies ON (users.state = companies.state) WHERE users.id = $user_id\");<\/code><\/p>\n\/\/ ambas as colunas de estado devem ser indexadas
\n\/\/ e ambas devem ser do mesmo tipo e codifica\u00e7\u00e3o de caracteres
\n\/\/ ou o MySQL pode fazer varreduras completas da tabela<\/p>\n
14 Ocultar o MySQL da Internet<\/strong><\/h2>\nAdministradores de banco de dados experientes e pessoal de seguran\u00e7a sabem disso \u2013 nunca hospede o banco de dados na raiz do servidor da Web.<\/p>\n
Para aplicativos habilitados para Web, o MySQL deve estar oculto atr\u00e1s de um firewall. A comunica\u00e7\u00e3o deve ser habilitada apenas entre servidores de aplicativos e seus servidores Web.<\/p>\n
Outra op\u00e7\u00e3o \u00e9 usar o MySQL skip-networking. Quando habilitado, o MySQL escuta apenas conex\u00f5es de soquetes locais e ignora todas as portas TCP.<\/p>\n
15 Use os menores tipos de dados poss\u00edveis<\/strong><\/h2>\n<\/a><\/p>\nDeixe-me te contar uma historia. Quando eu estava na faculdade, a filosofia era que “a mem\u00f3ria \u00e9 escassa”. Aqueles eram os dias de discos r\u00edgidos de 256 MB. Hoje em dia, ningu\u00e9m parece se importar nem um pouco com mem\u00f3ria ou espa\u00e7o no disco r\u00edgido. A nova filosofia \u00e9 que “a mem\u00f3ria \u00e9 barata”. Pode ser verdade em termos de d\u00f3lares, mas a leitura de tipos de dados grandes ainda leva mais tempo do que a leitura de tipos menores. Tipos de dados grandes exigem que mais setores de disco sejam lidos na mem\u00f3ria.<\/p>\n
A moral \u00e9: ignore a tenta\u00e7\u00e3o de pular imediatamente para o maior tipo de dados ao projetar suas tabelas. Pense em usar um int em vez de um bigint.<\/p>\n
Al\u00e9m disso, evite campos de texto largechar (255) quando um varchar ou um caractere menor for suficiente.<\/p>\n
Se voc\u00ea usar o tipo de dados correto, mais registros caber\u00e3o na mem\u00f3ria ou no bloco de chave de \u00edndice. Isso leva a menos leituras e desempenho mais r\u00e1pido.<\/p>\n
16 Aproveite o cache de consultas<\/strong><\/h2>\nO cache de consulta \u00e9 um dos m\u00e9todos mais eficazes para melhorar o desempenho. A maioria dos servidores MySQL tem habilitado por padr\u00e3o.<\/p>\n
O cache de consulta armazena o texto de uma instru\u00e7\u00e3o SELECT junto com o conjunto de resultados correspondente. Se o servidor receber posteriormente uma instru\u00e7\u00e3o id\u00eantica, ele recuperar\u00e1 os resultados do cache de consulta em vez de analisar e executar a instru\u00e7\u00e3o novamente. O cache de consulta \u00e9 compartilhado entre as sess\u00f5es, portanto, um conjunto de resultados gerado por um cliente pode ser enviado em resposta \u00e0 mesma consulta emitida por outro cliente.<\/p>\n
No entanto, por melhor que seja, o cache de consultas tem suas limita\u00e7\u00f5es. Tome a seguinte afirma\u00e7\u00e3o:<\/p>\n
O problema aqui \u00e9 que as consultas cont\u00eam certas fun\u00e7\u00f5es n\u00e3o determin\u00edsticas, como NOW() e RAND(). O MySQL n\u00e3o pode calcular essas fun\u00e7\u00f5es antecipadamente, ent\u00e3o elas acabam n\u00e3o sendo armazenadas em cache.<\/p>\n
Felizmente, existe uma solu\u00e7\u00e3o f\u00e1cil para isso: voc\u00ea pode armazenar os resultados da fun\u00e7\u00e3o em uma vari\u00e1vel.<\/p>\n
17 N\u00e3o edite arquivos de despejo<\/strong><\/h2>\nArquivos de despejo s\u00e3o muito enganadores e podem causar corrup\u00e7\u00e3o. Por qu\u00ea? Se voc\u00ea j\u00e1 viu os arquivos de despejo criados pelo mysqldump, voc\u00ea concordar\u00e1 que eles se parecem com arquivos de texto normais e inofensivos. \u00c9 por isso que a maioria das pessoas os edita em um editor de texto padr\u00e3o, o que faz com que apare\u00e7am corrup\u00e7\u00f5es.<\/p>\n
Se voc\u00ea j\u00e1 tentou editar arquivos de despejo, aprendeu rapidamente que eles s\u00e3o tudo menos um arquivo de texto. Portanto, a \u00fanica maneira garantida de evitar problemas \u00e9 deixar os arquivos de despejo em paz.<\/p>\n
18 Use a configura\u00e7\u00e3o de tamanho de bloco MyISAM<\/strong><\/h2>\n
\u2026 porque ent\u00e3o o \u00edndice perde sua finalidade.<\/p>\n
Por exemplo, suponha que voc\u00ea queira obter dados em que os dois primeiros caracteres do c\u00f3digo do cliente sejam AK. Escreva:<\/p>\n
e n\u00e3o escreva<\/p>\n Por qu\u00ea? O primeiro exemplo far\u00e1 uso do \u00edndice, o que resultar\u00e1 em um tempo de resposta mais r\u00e1pido.<\/p>\n Seguindo a lista das melhores pr\u00e1ticas do MySQL, n\u00e3o use cegamente SELECT * no c\u00f3digo. Se a tabela tiver muitas colunas, todas ser\u00e3o retornadas. Isso diminuir\u00e1 o tempo de resposta, especialmente se voc\u00ea enviar o resultado para um aplicativo front-end.<\/p>\n Em vez disso, digite explicitamente os nomes das colunas que s\u00e3o realmente necess\u00e1rios.<\/p>\n Nota: lembre-se de que todas as instru\u00e7\u00f5es SELECT requerem uma cl\u00e1usula WHERE.<\/p>\n Se voc\u00ea quiser mostrar o resultado no aplicativo front-end, deixe-o ORDER no conjunto de resultados. Se voc\u00ea fizer isso no SQL, o tempo de resposta pode ser mais lento no ambiente multiusu\u00e1rio.<\/p>\n Se voc\u00ea desenvolver um aplicativo que l\u00ea dados com mais frequ\u00eancia do que escreve (por exemplo, um mecanismo de pesquisa), escolha o mecanismo de armazenamento MyISAM.<\/p>\n Escolher o mecanismo de armazenamento errado afetar\u00e1 o desempenho.<\/p>\n Para verificar a exist\u00eancia de dados, use a cl\u00e1usula EXISTS que \u00e9 mais r\u00e1pida no tempo de resposta. Por exemplo, use:<\/p>\n N\u00e3o use :<\/p>\n Se voc\u00ea usar a palavra-chave EXPLAIN, poder\u00e1 obter informa\u00e7\u00f5es sobre o que o MySQL est\u00e1 fazendo para executar sua consulta. Isso pode ajud\u00e1-lo a detectar problemas com suas estruturas de consulta ou tabela (por exemplo, gargalos).<\/p>\n Uma consulta EXPLAIN resulta em mostrar quais \u00edndices est\u00e3o sendo utilizados, como a tabela est\u00e1 sendo verificada, classificada, etc.<\/p>\n Tudo o que voc\u00ea precisa fazer \u00e9 adicionar a palavra-chave EXPLAIN na frente de uma consulta SELECT (de prefer\u00eancia complexa com jun\u00e7\u00f5es). Al\u00e9m disso, se voc\u00ea usar o phpmyadmin para isso, seus resultados ser\u00e3o mostrados em uma boa tabela.<\/p>\n \u00c0s vezes, voc\u00ea sabe de antem\u00e3o que est\u00e1 procurando apenas uma linha ao consultar suas tabelas. Por exemplo, voc\u00ea pode estar buscando um registro exclusivo ou pode estar apenas verificando a exist\u00eancia de qualquer n\u00famero de registros que satisfa\u00e7am sua cl\u00e1usula WHERE.<\/p>\n Nesses casos, voc\u00ea desejar\u00e1 usar a fun\u00e7\u00e3o limite do MySQL para aumentar o desempenho. Aqui est\u00e1 outra das melhores pr\u00e1ticas do MySQL: simplesmente adicione LIMIT 1 \u00e0 sua consulta. Dessa forma, o mecanismo de banco de dados n\u00e3o precisar\u00e1 percorrer toda a tabela ou \u00edndice. Ele ir\u00e1 parar de escanear quando encontrar apenas 1 registro do que voc\u00ea est\u00e1 procurando.<\/p>\n \/\/ o que N\u00c3O fazer: \/\/ muito melhor: Outra dica vital das melhores pr\u00e1ticas do MySQL \u2013 se o seu aplicativo tiver muitas consultas JOIN, certifique-se de que as colunas pelas quais voc\u00ea une sejam indexadas em ambas as tabelas. Isso afeta a otimiza\u00e7\u00e3o interna da opera\u00e7\u00e3o de jun\u00e7\u00e3o pelo MySQL.<\/p>\n Al\u00e9m disso, as colunas unidas precisam ser do mesmo tipo. Por exemplo, se voc\u00ea unir uma coluna DECIMAL a uma coluna INT de outra tabela, o MySQL n\u00e3o poder\u00e1 usar nenhum dos \u00edndices. Mesmo as codifica\u00e7\u00f5es de caracteres precisam ser do mesmo tipo para colunas do tipo string.<\/p>\n \/\/ ambas as colunas de estado devem ser indexadas Administradores de banco de dados experientes e pessoal de seguran\u00e7a sabem disso \u2013 nunca hospede o banco de dados na raiz do servidor da Web.<\/p>\n Para aplicativos habilitados para Web, o MySQL deve estar oculto atr\u00e1s de um firewall. A comunica\u00e7\u00e3o deve ser habilitada apenas entre servidores de aplicativos e seus servidores Web.<\/p>\n Outra op\u00e7\u00e3o \u00e9 usar o MySQL skip-networking. Quando habilitado, o MySQL escuta apenas conex\u00f5es de soquetes locais e ignora todas as portas TCP.<\/p>\n Deixe-me te contar uma historia. Quando eu estava na faculdade, a filosofia era que “a mem\u00f3ria \u00e9 escassa”. Aqueles eram os dias de discos r\u00edgidos de 256 MB. Hoje em dia, ningu\u00e9m parece se importar nem um pouco com mem\u00f3ria ou espa\u00e7o no disco r\u00edgido. A nova filosofia \u00e9 que “a mem\u00f3ria \u00e9 barata”. Pode ser verdade em termos de d\u00f3lares, mas a leitura de tipos de dados grandes ainda leva mais tempo do que a leitura de tipos menores. Tipos de dados grandes exigem que mais setores de disco sejam lidos na mem\u00f3ria.<\/p>\n A moral \u00e9: ignore a tenta\u00e7\u00e3o de pular imediatamente para o maior tipo de dados ao projetar suas tabelas. Pense em usar um int em vez de um bigint.<\/p>\n Al\u00e9m disso, evite campos de texto largechar (255) quando um varchar ou um caractere menor for suficiente.<\/p>\n Se voc\u00ea usar o tipo de dados correto, mais registros caber\u00e3o na mem\u00f3ria ou no bloco de chave de \u00edndice. Isso leva a menos leituras e desempenho mais r\u00e1pido.<\/p>\n O cache de consulta \u00e9 um dos m\u00e9todos mais eficazes para melhorar o desempenho. A maioria dos servidores MySQL tem habilitado por padr\u00e3o.<\/p>\n O cache de consulta armazena o texto de uma instru\u00e7\u00e3o SELECT junto com o conjunto de resultados correspondente. Se o servidor receber posteriormente uma instru\u00e7\u00e3o id\u00eantica, ele recuperar\u00e1 os resultados do cache de consulta em vez de analisar e executar a instru\u00e7\u00e3o novamente. O cache de consulta \u00e9 compartilhado entre as sess\u00f5es, portanto, um conjunto de resultados gerado por um cliente pode ser enviado em resposta \u00e0 mesma consulta emitida por outro cliente.<\/p>\n No entanto, por melhor que seja, o cache de consultas tem suas limita\u00e7\u00f5es. Tome a seguinte afirma\u00e7\u00e3o:<\/p>\n O problema aqui \u00e9 que as consultas cont\u00eam certas fun\u00e7\u00f5es n\u00e3o determin\u00edsticas, como NOW() e RAND(). O MySQL n\u00e3o pode calcular essas fun\u00e7\u00f5es antecipadamente, ent\u00e3o elas acabam n\u00e3o sendo armazenadas em cache.<\/p>\n Felizmente, existe uma solu\u00e7\u00e3o f\u00e1cil para isso: voc\u00ea pode armazenar os resultados da fun\u00e7\u00e3o em uma vari\u00e1vel.<\/p>\n Arquivos de despejo s\u00e3o muito enganadores e podem causar corrup\u00e7\u00e3o. Por qu\u00ea? Se voc\u00ea j\u00e1 viu os arquivos de despejo criados pelo mysqldump, voc\u00ea concordar\u00e1 que eles se parecem com arquivos de texto normais e inofensivos. \u00c9 por isso que a maioria das pessoas os edita em um editor de texto padr\u00e3o, o que faz com que apare\u00e7am corrup\u00e7\u00f5es.<\/p>\n Se voc\u00ea j\u00e1 tentou editar arquivos de despejo, aprendeu rapidamente que eles s\u00e3o tudo menos um arquivo de texto. Portanto, a \u00fanica maneira garantida de evitar problemas \u00e9 deixar os arquivos de despejo em paz.<\/p>\nSELECT columns FROM table WHERE customer_code like 'AK%'<\/code><\/p>\nSELECT columns FROM table WHERE left (customer_code,2)='AK\u2019<\/code><\/p>\n7 Use SQL SELECT * somente se necess\u00e1rio<\/strong><\/h2>\n
8 Use a cl\u00e1usula ORDER BY somente se necess\u00e1rio<\/strong><\/h2>\n
9 Escolha um Mecanismo de Banco de Dados adequado<\/strong><\/h2>\n
10 Use a cl\u00e1usula EXISTS sempre que necess\u00e1rio<\/strong><\/h2>\n
If EXISTS(SELECT * from Table WHERE col=\u2019some value\u2019)<\/code><\/p>\nIf (SELECT count(*) from Table WHERE col=\u2019some value\u2019)>0<\/code><\/p>\n11 EXPLIQUE suas consultas SELECT<\/strong><\/h2>\n
12 Use LIMIT 1 ao obter uma linha exclusiva<\/strong><\/h2>\n
\/\/ do I have anyusersfrom Alabama?<\/code><\/p>\n
\n$r = mysql_query(“SELECT * FROM user WHERE state = ‘Alabama’");
\nif (mysql_num_rows($r) > 0) {
\n\/\/ \u2026
\n}<\/p>\n
\n$r = mysql_query(“SELECT 1 FROM user WHERE state = ‘Alabama’ LIMIT 1");
\nif (mysql_num_rows($r) > 0) {
\n\/\/ \u2026
\n}<\/p>\n13 Indexe e use os mesmos tipos de coluna para jun\u00e7\u00f5es<\/strong><\/h2>\n
\/\/ looking for companies in my state $r = mysql_query(\"SELECT company_name FROM users LEFT JOIN companies ON (users.state = companies.state) WHERE users.id = $user_id\");<\/code><\/p>\n
\n\/\/ e ambas devem ser do mesmo tipo e codifica\u00e7\u00e3o de caracteres
\n\/\/ ou o MySQL pode fazer varreduras completas da tabela<\/p>\n14 Ocultar o MySQL da Internet<\/strong><\/h2>\n
15 Use os menores tipos de dados poss\u00edveis<\/strong><\/h2>\n
<\/a><\/p>\n16 Aproveite o cache de consultas<\/strong><\/h2>\n
17 N\u00e3o edite arquivos de despejo<\/strong><\/h2>\n
18 Use a configura\u00e7\u00e3o de tamanho de bloco MyISAM<\/strong><\/h2>\n
![\"22](\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-206970-61e8d4b8518b8.jpg\")
<\/a><\/p>\n![\"22](\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-206970-61e8d4b96bb8a.jpg\")
<\/a><\/p>\n