{"id":6152,"date":"2015-04-14T09:00:24","date_gmt":"2015-04-14T12:00:24","guid":{"rendered":"http:\/\/172.17.3.8\/blog\/?p=6152"},"modified":"2015-04-14T09:00:24","modified_gmt":"2015-04-14T12:00:24","slug":"aprenda-7-cuidados-para-turbinar-a-performance-do-mysql","status":"publish","type":"post","link":"https:\/\/www.impacta.com.br\/blog\/aprenda-7-cuidados-para-turbinar-a-performance-do-mysql\/","title":{"rendered":"Aprenda 7 cuidados para turbinar a performance do MySQL"},"content":{"rendered":"

Acredite<\/strong>: mesmo profissionais experimentados costumam deixar passar itens b\u00e1sicos de performance.\u00a0Por isso, siga conosco a lista abaixo, que re\u00fane:\u00a0<\/span><\/p>\n

7 cuidados para turbinar a performance do MySQL<\/strong><\/span><\/h2>\n

Os exemplos est\u00e3o em linguagem PHP. Veja:<\/span><\/p>\n

#1 Fuja do asterisco<\/strong><\/span><\/h3>\n

Seja criterioso ao construir sua instru\u00e7\u00e3o SELECT<\/strong>, pois quanto mais dados s\u00e3o lidos das tabelas, mais tempo levar\u00e1 sua execu\u00e7\u00e3o. Especialmente quando o servidor de banco de dados estiver separado do servidor de aplica\u00e7\u00e3o, porque os dados v\u00e3o ter que passar pela rede entre os dois.<\/span><\/p>\n

Crie o h\u00e1bito saud\u00e1vel de sempre especificar as colunas de que vai precisar ao montar o seu SELECT.<\/span><\/p>\n

\/\/ mau h\u00e1bito<\/strong><\/span><\/p>\n

$comando = mysql_query(“SELECT * FROM usuarios WHERE id_usuario = 33”);<\/span><\/p>\n

$dados = mysql_fetch_assoc($comando);<\/span><\/p>\n

echo “Ol\u00e1, {$d[‘nome’]}”;<\/span><\/p>\n

\/\/ bem melhor:)<\/strong><\/span><\/p>\n

$comando = mysql_query(“SELECT nome FROM usuarios WHERE id_usuario = 33”);<\/span><\/p>\n

$dados = mysql_fetch_assoc($r);<\/span><\/p>\n

echo “Ol\u00e1, {$d[‘nome’]}”;<\/span><\/p>\n

\/\/ quanto maior o resultset, mais significante a diferen\u00e7a<\/span><\/p>\n

#2 Adicione \u00edndices a colunas muito pesquisadas<\/strong><\/span><\/h3>\n

O uso de \u00edndices n\u00e3o se limita \u00e0s chaves prim\u00e1rias e chaves exclusivas (unique). Se uma coluna da sua tabela vai ser usada frequentemente em pesquisas, na maioria das vezes voc\u00ea deveria adicionar um \u00edndice a ela. A diferen\u00e7a no tempo de resposta \u00e9 grande.<\/span><\/p>\n

Esta regra se aplica tamb\u00e9m a pesquisas por conte\u00fado parcial da coluna. Por exemplo, quando voc\u00ea fornece o come\u00e7o da string a ser pesquisada: “…sobrenome LIKE ‘so%'”. Ela n\u00e3o se aplica quando voc\u00ea busca uma palavra inteira dentro de um texto maior, por exemplo “WHERE descricao LIKE ‘%multibanda%'”. Neste caso voc\u00ea n\u00e3o ver\u00e1 melhoras com o uso de um \u00edndice normal, seria melhor usar os recursos de fulltext search<\/span><\/a>.<\/span><\/p>\n

#3 E por falar em \u00edndices, tenha estas tr\u00eas regras de indexa\u00e7\u00e3o em mente<\/strong><\/span><\/h3>\n

Voc\u00ea deve ter notado que no item anterior usamos a express\u00e3o “na maioria das vezes” na hora de recomendar a inclus\u00e3o de um \u00edndice. Isto porque esta inclus\u00e3o deve sempre levar em conta o custo computacional adicional gerado. <\/span><\/p>\n

Lembre-se sempre de que quando uma tabela indexada receber um novo registro, n\u00e3o s\u00f3 a tabela mas tamb\u00e9m um ou mais \u00edndices dever\u00e3o ser atualizados.<\/span><\/p>\n

\u00cdndices bem planejados cumprem tr\u00eas miss\u00f5es important\u00edssimas dentro do servidor de banco:<\/span><\/p>\n