{"id":106286,"date":"2022-12-28T15:36:45","date_gmt":"2022-12-28T13:36:45","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/predstavlena-novaya-znachitelnaya-vetka-subd-mariadb-11"},"modified":"2022-12-28T15:36:45","modified_gmt":"2022-12-28T13:36:45","slug":"predstavlena-novaya-znachitelnaya-vetka-subd-mariadb-11","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/news\/predstavlena-novaya-znachitelnaya-vetka-subd-mariadb-11","title":{"rendered":"Foi apresentada uma nova e significativa vers\u00e3o do SGBD MariaDB 11","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Ap\u00f3s 10 anos desde a cria\u00e7\u00e3o da ramifica\u00e7\u00e3o 10.x, foi lan\u00e7ada a vers\u00e3o do SGBD MariaDB 11.0.0, que traz v\u00e1rias melhorias significativas e altera\u00e7\u00f5es que quebram a compatibilidade. A ramifica\u00e7\u00e3o ainda tem qualidade de vers\u00e3o alfa e estar\u00e1 pronta para aplica\u00e7\u00f5es de produ\u00e7\u00e3o ap\u00f3s a estabiliza\u00e7\u00e3o. A forma\u00e7\u00e3o da pr\u00f3xima ramifica\u00e7\u00e3o significativa, MariaDB 12, que conter\u00e1 altera\u00e7\u00f5es que quebram a compatibilidade, \u00e9 esperada n\u00e3o antes de 10 anos (em 2032). <\/p>\n
O projeto MariaDB desenvolve um desdobramento do MySQL, que, tanto quanto poss\u00edvel, mant\u00e9m a compatibilidade retroativa e se distingue pela integra\u00e7\u00e3o de mecanismos de armazenamento adicionais e recursos avan\u00e7ados. O desenvolvimento do MariaDB \u00e9 supervisionado pela organiza\u00e7\u00e3o independente MariaDB Foundation, de acordo com um processo de desenvolvimento aberto e transparente, que n\u00e3o depende de fornecedores espec\u00edficos. O SGBD MariaDB \u00e9 fornecido em vez do MySQL em muitas distribui\u00e7\u00f5es Linux (RHEL, SUSE, Fedora, openSUSE, Slackware, OpenMandriva, ROSA, Arch Linux, Debian) e est\u00e1 implementado em grandes projetos como Wikipedia, Google Cloud SQL e Nimbuzz. <\/p>\n
A principal melhoria na ramifica\u00e7\u00e3o MariaDB 11 \u00e9 a transi\u00e7\u00e3o do otimizador de consultas para um novo modelo de custo (cost model), que garante previs\u00f5es mais precisas sobre os custos de cada plano de execu\u00e7\u00e3o de consulta. Embora o novo modelo ajude a eliminar alguns gargalos de desempenho, n\u00e3o se pode garantir que ele seja otimizado para todos os cen\u00e1rios, e pode haver uma diminui\u00e7\u00e3o em alguns tipos de consultas, por isso \u00e9 recomendado que os usu\u00e1rios participem dos testes e notifiquem os desenvolvedores em caso de problemas. <\/p>\n
O modelo anteriormente utilizado adequava-se bem para encontrar o \u00edndice otimizado, mas apresentava problemas com a aplicabilidade das opera\u00e7\u00f5es de varredura de tabela, varredura de \u00edndice ou sele\u00e7\u00e3o por intervalos. No novo modelo, essa desvantagem foi eliminada por meio da altera\u00e7\u00e3o do peso b\u00e1sico das opera\u00e7\u00f5es no mecanismo de armazenamento. Ao avaliar o desempenho de opera\u00e7\u00f5es que dependem da velocidade de acesso ao disco, como a varredura sequencial de registros, agora assume-se que os dados s\u00e3o armazenados em um SSD, que oferece uma velocidade de leitura de 400 MB por segundo. Al\u00e9m disso, outras vari\u00e1veis de peso do otimizador foram ajustadas, o que, por exemplo, permitiu a implementa\u00e7\u00e3o do uso de \u00edndices para opera\u00e7\u00f5es de «ORDER BY\/GROUP BY» em subconsultas e acelerou o trabalho com tabelas muito pequenas. <\/p>\n
Observa-se que o novo modelo de peso permitir\u00e1 escolher um plano de execu\u00e7\u00e3o de consulta mais otimizado nas seguintes situa\u00e7\u00f5es: <\/p>\n
\n
Ao utilizar consultas que abrangem mais de 2 tabelas.\n
Quando existem \u00edndices contendo um grande n\u00famero de valores id\u00eanticos.\n
Ao usar intervalos que abrangem mais de 10% da tabela.\n
Quando h\u00e1 consultas complexas, nas quais nem todas as colunas utilizadas est\u00e3o indexadas.\n
Quando s\u00e3o utilizadas consultas que envolvem diferentes mecanismos de armazenamento (por exemplo, quando em uma consulta h\u00e1 acesso a tabelas nos mecanismos InnoDB e Memory).\n
Ao usar FORCE INDEX para melhorar o plano da consulta.\n
Na deteriora\u00e7\u00e3o do plano de consulta ao usar «ANALYZE TABLE».\n
Quando a consulta abrange um grande n\u00famero de tabelas derivadas (um grande n\u00famero de SELECT aninhados).\n
Ao utilizar express\u00f5es de ORDER BY ou GROUP BY que se encaixam nos \u00edndices. <\/ul>\n
Principais viola\u00e7\u00f5es de compatibilidade na vers\u00e3o MariaDB 11: <\/p>\n
\n
Os privil\u00e9gios SUPER n\u00e3o permitem mais executar a\u00e7\u00f5es para as quais h\u00e1 privil\u00e9gios concedidos separadamente. Por exemplo, para alterar o formato dos logs bin\u00e1rios, ser\u00e3o necess\u00e1rios os direitos de BINLOG ADMIN.\n
Removida a implementa\u00e7\u00e3o do buffer de altera\u00e7\u00f5es no InnoDB.\n
Declarados obsoletos innodb_flush_method e innodb_file_per_table.\n
Declarada obsoleta a suporte a nomes mysql*.\n
Declarado obsoleto o ajuste do par\u00e2metro explicit_defaults_for_timestamp para o valor 0.\n
As liga\u00e7\u00f5es simb\u00f3licas para compatibilidade com MySQL foram transferidas para um pacote separado.\n
O valor do par\u00e2metro innodb_undo_tablespaces foi alterado para 3 por padr\u00e3o. <\/ul>\n<\/ul>\n