Почему функции mysql_ PHP устарели?

Расширение mysql является древним и существует со времен PHP 2.0, выпущенного 15 лет назад (!!); который является совершенно другим зверем, чем современный PHP, который пытается избавиться от плохих практик своего прошлого. Расширение mysql является очень сырым, низкоуровневым коннектором для MySQL, которому не хватает многих удобных функций, и поэтому его сложно применять правильно в безопасном режиме; поэтому плохо для noobs. Многие разработчики не понимают SQL-инъекцию, а API-интерфейс mysql достаточно хрупкий, чтобы затруднить его предотвращение, даже если вы знаете об этом. Он заполнен глобальным состоянием (например, неявное соединение), что упрощает запись кода, который трудно поддерживать. Поскольку он старый, может быть неоправданно трудно поддерживать на уровне ядра PHP.

Расширение mysqli намного новее и устраняет все вышеперечисленные проблемы. PDO также является довольно новым и устраняет все эти проблемы, а также больше.

По этим причинам * расширение mysql будет удалено когда-нибудь в будущем. Он выполнял свою работу в период расцвета, довольно плохо, но он это сделал. Время изменилось, появились лучшие практики, приложения стали более сложными и требуют более современного API. mysql уходит на пенсию, живет с ним.

Учитывая все это, нет причин продолжать использовать его, кроме инерции.

* Это сводные причины моего здравого смысла; для всей официальной истории, посмотрите здесь: https://wiki.php.net/rfc/mysql_deprecation

Ниже перечислены цитаты из этого документа:

Группа документации обсуждает ситуацию с безопасностью базы данных, и обучение пользователей удалению от широко используемого расширения ext / mysql является частью этого.

Переход от ext / mysql относится не только к безопасности, но и к доступу ко всем функциям базы данных MySQL.

ext / mysql сложно поддерживать код. Это не новые функции. Сохраняя актуальность работы с новыми версиями версий libmysql или mysqlnd, мы, вероятно, могли бы потратить это время лучше.

Почему они устарели?

Ну, основная причина в том, что API был плохо разработан. Библиотека mysqli была создана как прямая замена для нее, с лучшим дизайном API.

Да, есть проблемы с внутренним кодом для библиотеки, что означает, что его нужно заменить, но если API был лучше разработан, в первую очередь, библиотека mysqli не должна была быть написана; улучшенный код может быть просто заменен на существующую библиотеку, и мы, как разработчики, могли бы использовать существующие функции, не зная, что что-то изменилось внутренне.

Однако это было не так. Первоначальный API имел некоторые критические недостатки в дизайне, что означало, что когда разработчики PHP хотели улучшить ситуацию, были проблемы, которые означали, что они не могли этого сделать.

Таким образом, лучший способ действий для них заключался в предоставлении нового API и обесценивании старого.

неодобрение

Насколько я знаю, это люди Oracle, ответственные за поддержку, просто отказались сделать это больше. Это, по-видимому, главная причина.

Все остальные причины – лишь глупые оправдания. Есть тонна расширения в PHP того же возраста, счастливо работает и работает. Некоторые новые функции в современной версии не являются основанием для отказа от устаревших. И, конечно же, проблема с самой библиотекой не связана с библиотекой, а с пользователями библиотеки.

означает ли это, что я должен перестать использовать их на своих сайтах?

Это зависит.

• Для устаревшего кода я сомневаюсь, что стоит начать экстренное переписывание.
• Что касается совершенно новых проектов – ответ довольно прост:

вы просто не должны использовать любые вызовы API в коде приложения, но только в библиотеке DBAL.

Это не только сделает проблему с целым драйвером незначительной (так как вам потребуется только переписать относительно небольшой библиотечный код для изменения драйверов), но также может сделать ваш код значительно короче и чище.

Представление

Говоря о разнице в производительности, есть интересная вещь. Интернет действительно полон тестов, которые говорят вам, что X быстрее Y по Z раз. Но как можно отличить хороший показатель от плохого? Трудно сказать в общем. Вообще говоря, при написании теста нужно понять, что они делают. К сожалению, большинство авторов тестов этого не делают.

Давайте рассмотрим один вопрос в вашем вопросе.

Включая код подключения в цикле, автор просто сравнивал время соединения , но не то, что он должен был измерить. Результаты вполне предсказуемы.
Потому как

• соединение, как известно, является относительно ресурсоемкой операцией
• mysql_connect() никогда не пересоединяется (если не указано явно), а вместо этого использует последнее открытое соединение.

Таким образом, в результате мы получаем mysql ext. Неудивительно, что и mysqli, и PDO должны были подключаться все тысячи раз, в то время как mysql должен был подключаться только один раз.

При подключении, удаленном от повторяющегося кода, результаты резко меняются, показывая полную незначительность.

В этом тесте есть много других подводных камней, но идея остается прежней:

НИКОГДА не запускайте холостые тесты из ниоткуда. Но всегда делайте какие-либо тесты только в том случае, если у вас есть причина и в реальной среде. В противном случае вы будете измерять все, кроме любых значимых чисел .

Поскольку в нем отсутствуют функции, которые просто ожидаются в настоящее время, это уже не стоит поддерживать. Поскольку PHP пытается поддерживать тонкий API (…), вы можете ожидать, что он будет удален. Это похоже на IE7: вы не можете использовать его, пока он «не исчезнет». Вы должны прекратить использование самостоятельно.

Изображение с сайта http://php.net/manual/en/mysqlinfo.api.choosing.php