Deprecation
As far as I know, it's Oracle folks responsible for the support, just refused to do so anymore. That's seems to be the main reason.
All other reasons are but silly excuses. There are a ton of extension in the PHP of the same age, happily up and running. Some new features in a modern version is not a reason to deprecate an older one. And of course, there is no security problem with library itself but rather with library users.
does this mean I should cease to use them in my sites?
It depends.
- For the legacy code, I doubt it worth starting for emergency rewriting.
- As for the brand new projects - the answer is fairly simple:
you just shouldn't use whatever API calls in the application code but in the DBAL library only.
It will not only make whole driver problem negligible (as you will only need to rewrite a relatively small library code in order to change drivers) but also it can make your code dramatically shorter and cleaner.
Performance
Speaking of the performance difference, there is an interesting thing to mention. The Internet is indeed full of benchmarks telling you that X is faster than Y by Z times. But how one can tell a good benchmark from a bad one? It's hard to tell in general. Generally speaking, when writing a test, one have to understand what are they doing. Unfortunately, most of test-writers don't.
Let's take one linked in your question.
By including connection code in the loop, the author merely benchmarking connection time, but not what he was intended to measure. The results are quite predictable.
Because
- connection is known to be a relatively resource-consuming operation
mysql_connect() never actually reconnects (if not told explicitly), but rather use last opened connection instead.
So we have mysql ext dramatically faster as a result. No wonder, as both mysqli and PDO had to connect all the thousands times, while mysql had to connect only once.
With connect removed from the iterated code, results dramatically change, showing total insignificance.
There are many other pitfalls in this test but the idea remains the same:
NEVER run idle benchmarks out of nowhere. But always do any benchmarks only if you have a reason to and in the real environment. Otherwise you will measure anything but whatever meaningful numbers.
