Why should not we use functions of type mysql_ *?


A very common question is why should we stop using mysql_ * functions? For example mysql_query() , or mysql_connect() .

I see that many people use them, or stop using them but do not know the real reason. Why should they stop being used once they work?

asked by anonymous 18.12.2013 / 12:27

6 answers



The answer is one: we should not use functions of the "mysql" extension because its development has been discontinued ; the extension has become obsolete , meaning code that uses these functions will not work in future versions of PHP .


A user of the Stack Overflow website wrote:


There is no security problem with the library itself, but rather with library users ) .

Voting to discontinue ( deprecate ) or not resulted in 25 votes in favor and 12 votes against . It was a good majority, but it was not a unanimous decision. See the official source .

In this same source, another developer wrote:


The extension is not broken. The problem is the bad usage. ( Extension has no defects.) The problem is the misuse It can be used safely, and good developers have been doing this for years.)

The quote below, also from that same official document, points to the true reasons for discontinuing the extension:


ext / mysql is hard to maintain code. It is not getting new features.   Keeping it up to date for working with new versions of libmysql or   mysqlnd versions is work, we probably could spend that time better.


(The mysql extension contains code that is difficult to maintain.   receiving new features. Keep it up-to-date to work with   new versions of libmysqld and mysqlnd are laborious; we could   be using this time better.)

In other words: " Why have a job to keep this old code? " - for as new versions of MySQL (and its "client libs" ") are released, the extension needs to be updated ...

... and in addition there are already the extensions mysqli (most modern) and the PDO alternative ... so ... why keep on keeping? Let's discontinue? There, 25 voted "yes", 12 voted "no", and the decision was made.

Personal Comment

When I started with PHP there was no PDO extension. I used the "mysql" extension, like most, until I worked on a project using "mysqli" and learned the advantages, and have always preferred it since.

Soon after, I wrote a couple of classes that extend the originals of the mysqli extension, and I use them to this day in pure PHP, ie when I'm not using a framework like Laravel, with its "Fluent" and its "Eloquent", Symfony with "Doctrine", etc ...

For me, accustomed to the little details of preparing "LIKE" clauses, the "black box" of these "prepared statements", "Active Record" or "ORM" was viewed with suspicion. This phase has passed, and today I am a fan of Eloquent that comes with Laravel 4 ...


After posting all of the above, I felt it necessary to stress the importance of the " not getting new features " factor in the decision to discontinue the extension. That means: although it is the fastest (best performance) in the execution of simple tasks, it lacks the full range of functionalities that the alternative extensions (mysqli and PDO) contain ( transactions , SSL support etc ) - a point that was highlighted in other answers here.

06.02.2014 / 22:35

Because the use of the mysql_* functions was disapproved ( deprecated ) from PHP 5.5 and, According to the documentation , the functions will be removed in future versions of PHP, causing the programs that use them to stop working in those versions.

Limitations of functions mysql_*

Unlike the mysqli_* functions, the mysql_* functions do not support

  • Asynchronous, non-blocking queries
  • parameterized queries
  • stored procedures
  • transactions

Failure to support parameterized queries means that by using mysql_* functions without taking certain precautions, your program is vulnerable to SQL injection attacks , compromising data security and integrity. Example:

// consulta vulnerável a injeção de SQL
$query = mysql_query("SELECT * FROM alunos WHERE id = $id")

// consulta parametrizada, variável $id é higienizada
$query = mysqli_query("SELECT * FROM alunos WHERE id = ?")
$query->bind_param("i", $id);


Alternatively, it is recommended to use mysqli_* functions that outweigh the limitations already of the mysql_* functions.

Another option is to use PDO (PHP Data Objects) that provides an abstraction layer of access, which means that no matter which database you are using, you can use the same functions to issue queries and fetch data.


To learn the story behind the disapproval of mysql_* functions, see response from J.Bruni .

18.12.2013 / 12:38

We should no longer use mysql_ * for the following reason:

INSERT INTO usuarios SET nome='$nome';

The value is passed directly in the sql clause, this leaves the application vulnerable to sql injection attacks. With pdo:

$con->prepare("INSERT INTO usuarios SET nome=?");
$con->bindParam(1, $nome);

When using pdo the query is prepared, passing through a protection layer, which mysql_ * layer does not have at the time of replacing the values, this protection layer comes into action checking if the command is similar to sql injection .

06.03.2014 / 02:46

For one simple reason it is enough for many:

This extension of Mysql has been discontinued by the PHP development team. But then you ask me, why was it discontinued since it was simple and worked great? I tell you: As PHP is increasingly object-oriented and this extension of Mysql was created for structured PHP, it started to exhibit flaws in the object-oriented environment. Does not support Stored procedure. It does not support transactions. Only works with Mysql until 5.0. ... Among others. See a Comparison here

Then a code with mysql methods will have a deficit in the future to support new implementations and to fix future bugs. Use PHP PDO.

18.12.2013 / 12:34

We see that we have many answers about this, but in short, anything that the latest version of PHP (or any language) enters into the obsolete state, we should change, try to fit the code and if possible use more recent features than may become standard in the future and the PDO is an example. Unfortunately there are programmers who end up ignoring this and will only learn and make corrections when doing some migration to a server or something of the kind that starts to accuse the error. Anyway, change needed, sooner or later it would need to be done and fortunately in a while to use PDO or MySQLI will be like doing a mysql _ *

06.03.2014 / 03:42

I'll post just for curiosities: follow below an image of the advantages and disadvantages of mysql, mysqli and PDO.

24.05.2016 / 14:50