标签云

微信群

扫码加入我们

WeChat QR Code

What are the technical reasons for why one shouldn't use mysql_* functions? (e.g. mysql_query(), mysql_connect() or mysql_real_escape_string())?Why should I use something else even if they work on my site?If they don't work on my site, why do I get errors like Warning: mysql_connect(): No such file or directory


Error to be like: Fatal error: Uncaught Error: Call to undefined function mysql_connect() ...

2019年08月19日38分00秒

Deprecated alone is reason enough to avoid them

2019年08月19日38分00秒

Deprecated alone is reason enough to avoid them. They will not be there one day, and you will not be happy if you rely on them. The rest is just a list of things that using the old extensions has kept people from learning.

2019年08月19日38分00秒

Deprecation isn't the magic bullet everyone seems to think it is. PHP itself will not be there one day, yet we rely on the tools we have at our disposal today. When we have to change tools, we will.

2019年08月19日38分00秒

LightnessRacesinOrbit — Deprecation isn't a magic bullet, it is a flag that says "We recognise this sucks so we aren't going to support it for much longer". While having better future proofing of code is a good reason to move away from the deprecated features, it isn't the only one (or even the main one). Change tools because there are better tools, not because you are forced to. (And changing tools before you are forced to means that you aren't learning the new ones just because your code has stopped working and needs fixing yesterday … which is the worst time to learn new tools).

2019年08月19日38分00秒

One thing that I haven't seen mentioned about the lack of prepared statements is the performance issue. Every time you issue a statement, something has to compile it so that the MySQL daemon can understand it. With this API, if you issue 200,000 of the same query in a loop, that's 200,000 times the query has to be compiled for MySQL to understand it. With prepared statements, it's compiled once, and then values are parameterized into the compiled SQL.

2019年08月19日38分00秒

symcbean, It surely does not support prepared statements. That's in fact the main reason why it's deprecated. Without (easy to use) prepared statements the mysql extension often falls victim to SQL injection attacks.

2019年08月19日38分00秒

What the good read above should propably mention: prepared statement take away any meaningful use of the IN (...) construct.

2019年08月19日38分00秒

The question was "Why shouldnt I use mysql_* functions in PHP".This answer, while impressive and full of helpful information, goes WAY out of scope and like trejder says - 8 out of 10 people are going to miss out on that information simply because they don't have 4 hours to spend trying to work through it.This would be far more valuable broken up and used as answers to several, more precise, questions.

2019年08月19日38分00秒

Persoanlly I prefer mysqli and PDO. But for die handling, I tried exception alternativefunction throwEx() { throw new Exception("You did selected not existng db"); } mysql_select_db("nonexistdb") or throwEx(); It work for throwing exceptions.

2019年08月19日38分00秒

you list Doesn't support non-blocking, asynchronous queries as a reason to not use mysql_ - you should also list that as a reason to not use PDO, because PDO doesn't support that either. (but MySQLi supports it)

2019年08月19日38分00秒

There is one more thing: i think that function still exists in PHP for only one reason - compatibility with old, outdated but still running CMS, e-commerce, bulletin board systems etc. Finally it will be removed and you will have to rewrite your application...

2019年08月19日38分00秒

Kamil: That's true, but it's not really a reason why you shouldn't use it. The reason not to use it is because it's ancient, insecure, etc. :)

2019年08月19日38分00秒

Mario -- the PHP devs do have a process, and they've just voted in favour of formally deprecating ext/mysql as of 5.5. It's no longer a hypothetical issue.

2019年08月19日38分00秒

Adding a couple extra lines with a proven technique such as PDO or MySQLi still affords the ease of use PHP has always offered. I hope for the sake of the developer he/she knows that seeing these god-awful mysql_* functions in any tutorial actually detracts from the lesson, and should tell the OP that this kind of code is soooo 10 years ago- and should question the relevance of the tutorial,too!

2019年08月19日38分00秒

What the answer should propably mention: prepared statement take away any meaningful use of the IN (...) construct.

2019年08月19日38分00秒

Be careful with the pdo_query("INSERT INTO pages VALUES (?,?,?,?,?)", $_POST); function - ie: pdo_query("INSERT INTO users VALUES (?, ?, ?), $_POST);$_POST = array( 'username' => 'lawl', 'password' => '123', 'is_admin' => 'true');

2019年08月19日38分00秒

Tom Sure, albeit it's not maintained much (0.9.2 was the last), you can create a fossil account, add to the wiki or file a bug report (without registration IIRC).

2019年08月19日38分00秒

#2 is equally true of mysqli_

2019年08月19日38分00秒

to be fair, given the variations in SQL dialect, even PDO doesn't give you #2 with any degree of certainty. You'd need a proper ORM wrapper for that.

2019年08月19日38分00秒

SDC indeed - the problem with standards is that there's so many of them...

2019年08月19日38分00秒

xkcd.com/927

2019年08月19日38分00秒

the mysql_* function are a shell into mysqlnd functions for newer PHP versions. So even if the old client library is not maintained any more, mysqlnd is maintained :)

2019年08月19日38分00秒

mysql_* makes vulnerabilities very easy to come by. Since PHP is used by a whole lot of novice users, mysql_* is actively harmful in practice, even if in theory it can be used without a hitch.

2019年08月19日38分00秒

everything is parameterized and safe - it may be parameterized, but your function doesn't use real prepared statements.

2019年08月19日38分00秒

How is Not under active development only for that made-up '0.01%'? If you build something with this stand-still function, update your mysql-version in a year and wind up with a non-working system, I'm sure there are an awful lot of people suddenly in that '0.01%'. I'd say that deprecated and not under active development are closely related. You can say that there is "no [worthy] reason" for it, but the fact is that when offered a choice between the options, no active development is almost just as bad as deprecated I'd say?

2019年08月19日38分00秒

MadaraUchiha: Can you explain how vulnerabilities are very easy to come by? Especially in the cases where those same vulnerabilities don't affect PDO or MySQLi... Because I'm not aware of a single one that you speak of.

2019年08月19日38分00秒

ShaquinTrifonoff: sure, it doesn't use prepared statements. But neither does PDO, which most people recommend over MySQLi. So I'm not sure that has a significant impact here. The above code (with a little more parsing) is what PDO does when you prepare a statement by default...

2019年08月19日38分00秒

Unfortunately the poor support in MySQLi_* for passing a variable number of parameters (such as when you want to pass a list of values to check against in an IN clause) encourages non use of parameters, encouraging the use of exactly the same concatenated queries that leave MySQL_* calls vulnerable.

2019年08月19日38分00秒

But, once again, insecurity is not an inherent problem of mysql_* functions, but a problem of incorrect usage.

2019年08月19日38分00秒

Agamemnus The problem is that mysql_* makes it easy to implement that "incorrect usage", especially for inexperienced programmers. Libraries that implement prepared statements make it harder to make that type of error.

2019年08月19日38分00秒

The old functions will allow executing of multiple statements per query - no, they won't. That kind of injection is not possible with ext/mysql - the only way this kind of injection is possible with PHP and MySQL is when using MySQLi and the mysqli_multi_query() function. The kind injection that is possible with ext/mysql and unescaped strings is things like ' OR '1' = '1 to extract data from the database that was not meant to be accessible. In certain situations it is possible to inject sub queries, however it is still not possible to modify the database in this way.

2019年08月19日38分00秒

Thank you for your answer! Have my +1! It's worth noting that mysql_* in on itself isn't insecure, but it does promote insecure code via bad tutorials and the lack of a proper statement prepare API.

2019年08月19日38分00秒

unhashed passwords, oh the horror! =oP Otherwise +1 for detailed explanation.

2019年08月19日38分00秒

Your answer is too lengthy, while the real summary is "mysql ext is no more". That's all

2019年08月19日38分00秒

YourCommonSense My answer is to why mysqli replaced mysql. The point is not to say Mysqli exists today so use it.. Everyone knows that!

2019年08月19日38分00秒

Well, apart from the fact that nobody asked why mysqli replaced mysql, it doesn't answer this question either. It does answer why mysqli was introduced. But it doesn't explain why mysql and mysqli weren't allowed to live in parallel

2019年08月19日38分00秒

YourCommonSense Also the OP's question is "Why should I use something else even if they work on my site?" and that's the reason I pointed out the changes and improvements. You may look at all other answers they are long so I thought I should summarize it.

2019年08月19日38分00秒

Instead to showing link for your solution, please add them here as answer.

2019年08月19日38分00秒

PHP 5 hasn't been latest for over 2 years now.

2019年08月19日38分00秒

This answer is outdated. Besides, it does not add anything useful to the answers that already exists.

2019年08月19日38分00秒