Por que mysql_* em PHP é um mal: análise completa com exemplos

História de um erro: por que mysql_* é coisa do passado

Imagine: você está escrevendo um site em PHP, conectando-se a um banco de dados MySQL e usando a função familiar da faculdade mysql_query(). Tudo funciona, o site está no ar, os usuários estão satisfeitos. Mas um dia você percebe um aviso estranho nos logs: «Deprecated: mysql_connect(): The mysql extension is deprecated and will be removed in the future». Isso não é apenas uma reclamação do interpretador — é uma bandeira vermelha que não pode ser ignorada.

No Stack Overflow, a pergunta «Why shouldn't I use mysql_* functions in PHP?» acumulou milhares de visualizações e centenas de comentários. E isso não é por acaso. Neste artigo, vamos entender por que as funções mysql_* (mysql_connect, mysql_query, mysql_fetch_array e outras) se tornaram o inimigo número um dos desenvolvedores PHP, mostrar com exemplos reais de código como substituí-las e fornecer um plano de migração passo a passo.

O que são mysql_* e por que foram removidas?

A extensão mysql_* (MySQL original) surgiu no PHP 2.0 em 1997. Era simples e intuitiva: chamava mysql_connect(), executava a consulta com mysql_query(), obtinha o resultado. Mas essa simplicidade tinha um lado sombrio.

A partir do PHP 5.5.0, todas as funções mysql_* foram marcadas como obsoletas (deprecated) e, no PHP 7.0, foram completamente removidas. Se você tentar usar mysql_connect() no PHP 7+, receberá um erro fatal: Call to undefined function mysql_connect(). O motivo não é um capricho dos desenvolvedores do PHP, mas sim problemas fundamentais de segurança e arquitetura.

Três principais razões para abandonar mysql_*

\n
• Injeções SQL sem proteção — as funções não suportam consultas preparadas (prepared statements), tornando a sanitização manual obrigatória, mas frequentemente esquecida.
\n
• Arquitetura obsoleta — não há suporte para estilo orientado a objetos, procedimentos armazenados, múltiplas consultas e transações.
\n
• Falta de evolução — a extensão não foi atualizada por anos, enquanto o MySQL mudava (por exemplo, novos tipos de dados, codificações, mecanismos de autenticação).
\n

Exemplo prático: como mysql_* destrói seu site

Vamos ver um código clássico que ainda aparece em livros antigos e fóruns:

<?php\n// CÓDIGO OBSOLETO - NÃO USAR!\n$link = mysql_connect('localhost', 'root', 'password');\nmysql_select_db('users_db', $link);\n\n$user_input = $_GET['username']; // usuário insere: ' OR 1=1 --\n$query = "SELECT * FROM users WHERE username = '$user_input'";\n$result = mysql_query($query, $link);\n\nwhile ($row = mysql_fetch_assoc($result)) {\n    echo "Olá, " . $row['username'] . "<br>";\n}\n?>

Qual é o problema? Se um invasor passar no parâmetro username o valor ' OR 1=1 --, a consulta se torna:

SELECT * FROM users WHERE username = '' OR 1=1 --

O hífen duplo -- comenta o restante da consulta, e a condição 1=1 é sempre verdadeira. Como resultado, você obtém todos os usuários do banco de dados, incluindo senhas, e-mails e outras informações confidenciais. Isso não é teoria — é uma vulnerabilidade real que quebra milhares de sites todos os dias.

Claro, você pode usar mysql_real_escape_string(), mas:

\n
• Os desenvolvedores frequentemente esquecem de chamá-la.
\n
• Ela não protege contra todos os tipos de ataque (por exemplo, ataques usando codificações).
\n
• O código fica confuso e difícil de ler.
\n

O que usar no lugar de mysql_*: duas abordagens modernas

No PHP moderno, existem duas extensões dignas para trabalhar com MySQL: mysqli (MySQL Improved) e PDO (PHP Data Objects). Ambas suportam