Comments 35
Спасибо, полезно! Но насчет нервов и трудозатрат — это спорный вопрос. Как сам автор отметил: «Сегодня все используют PDO...».
mysqlnd_ms может адекватно и нативно заменить mysql proxy?
Спасибо, про память было особенно интересно!
Очень годно! Спасибо!
Огромное спасибо за это:
mysqli_options($m, MYSQLI_OPT_INT_AND_FLOAT_NATIVE, true);
Впилил в mysqli модуль для Коханы, при выборке 100 записей из БД потребление памяти упало на 5%. Помоему неплохо для однострочного фикса.
mysqli_options($m, MYSQLI_OPT_INT_AND_FLOAT_NATIVE, true);
Впилил в mysqli модуль для Коханы, при выборке 100 записей из БД потребление памяти упало на 5%. Помоему неплохо для однострочного фикса.
По теме статьи: моя любимая функция в PHP — как раз mysqli_real_escape_string </sarcasm>
Очень интересная и полезная статья. Я прочитал её недели 2 назад и сразу отправил ссылки знакомым. Могу порекомендовать остальные 3 статьи в блоге автора: jpauli.github.io/ (английский язык). Пишет про внутренности PHP и то, как это соотносится с буднями программирования на самом PHP.
эмм возможно я вас неверно понял но функции
mysqli_set_character_name() у mysqli нет, есть mysqli_set_charsetАвтор, по-видимому, описался. Правильно mysqli_set_charset().
Кому интересно, чем это отличается от SET NAMES и почему функция mysqli_set_charset() правильнее, вот тут есть пример того, как кодировка влияет на правила эскейпинга. Для меня было откровением. Правда, в реалиях UTF-8, насколько я понимаю, на это наткнуться невозможно (т. е. отличия SET NAMES 'utf8' от mysqli_set_charset не будет).
Кому интересно, чем это отличается от SET NAMES и почему функция mysqli_set_charset() правильнее, вот тут есть пример того, как кодировка влияет на правила эскейпинга. Для меня было откровением. Правда, в реалиях UTF-8, насколько я понимаю, на это наткнуться невозможно (т. е. отличия SET NAMES 'utf8' от mysqli_set_charset не будет).
Спасибо, поправил. Как-то я и сам этот момент упустил
del
Установка пакета mysqlnd в Ubuntu
Проверить, установлен ли
sudo apt-get install php5-mysqlnd
Проверить, установлен ли
php -m | grep mysqlnd
Спасибо. Классная статейка. Особенно понравилось про раздувание памяти. Как-то я раньше не думал об этом.
Более 5 лет использую mysqli и узнал кое-что новое
как говорится «век живи — век учись»
а вообще-то ман в руки и с флагом по жизни!
спасибо за статью
интересно, а с каких пор в маил-ру есть РНР-ные проекты?
как говорится «век живи — век учись»
а вообще-то ман в руки и с флагом по жизни!
спасибо за статью
интересно, а с каких пор в маил-ру есть РНР-ные проекты?
первая статья мейлру которую я плюсану с большим удовольствием. Спасибо за подробное описание. Даёшь меньше коммерции, больше технической информации!
Ну, как показывает практика, сама libmysql написана через Ж..., и для её использования в много-тредовом режиме приходится делать танцы с бубнами. Багрепорты не помогают…
Вот кто и зачем делает настолько бледные схемы расцветки кода?
Они как бы говорят мне «У твоего монитора недостаточно выкручена контрастность»)
Они как бы говорят мне «У твоего монитора недостаточно выкручена контрастность»)
Очень грустно читать статью, автор которой предубеждён против какой-либо технологии, и, за неимением фактов, пытается отстаивать свои пристрастия с помощью голословных утверждений.
Это единственно правильное поведение в 99.9% случаев.
Поддерживаемые базой подготовленные выражения ориентированы на однократную подготовку и множественное выполнение одного и того же запроса. В пхп такое поведение требуется в мизерном количестве случаев. Всё остальное время гонять запрос в БД по два раза, чтобы «достичь уровняпросветления подготовленного выражения» — бессмысленно. И замена плейсхолдеров на их значения, производимая PDO, работает прекрасно.
Да, режим эмуляции приводит к небольшим неудобствам.
Да, параметр LIMIT без явного указания типа приведет к ошибке.
Да, даже явное указание не спасёт для случая
— PDO все равно добавит кавычки, несмотря на модификатор PDO::PARAM_INT.
Но положа руку на сердце — это не те проблемы, ради которых стоит устраивать такой шум. Режим эмуляции — прекрасная вещь, и бежать отключать его совсем не обязательно.
Я не пойму — это аргумент за «режим эмуляции» или против? Судя по тону автора, складывается впечатление, что второе.
Однако по отзывам знакомых программистов — это чуть ли не лучшее, что есть в PDO.
Куда полезнее будет включить режим критического отношения к голословным утверждениям (это же относится к заявлениям еще одного противника режима эмуляции — А.Феррары, если вам случалось читать их на Stackoverflow).
В случае с MySQL, уровень эмуляции PDO активен по умолчанию, когда вы готовите запрос. Но он никогда не достигнет уровня подготовленного выражения. По сути, код PDO отпарсит и соберёт ваш запрос без взаимодействия с MySQL на эту тему. Это странное поведение.
Это единственно правильное поведение в 99.9% случаев.
Поддерживаемые базой подготовленные выражения ориентированы на однократную подготовку и множественное выполнение одного и того же запроса. В пхп такое поведение требуется в мизерном количестве случаев. Всё остальное время гонять запрос в БД по два раза, чтобы «достичь уровня
Да, режим эмуляции приводит к небольшим неудобствам.
Да, параметр LIMIT без явного указания типа приведет к ошибке.
Да, даже явное указание не спасёт для случая
$stmt->bindValue('limit', '10', PDO::PARAM_INT);— PDO все равно добавит кавычки, несмотря на модификатор PDO::PARAM_INT.
Но положа руку на сердце — это не те проблемы, ради которых стоит устраивать такой шум. Режим эмуляции — прекрасная вещь, и бежать отключать его совсем не обязательно.
Несмотря на то, что мы явным образом отключили уровень эмуляции подготовленных выражений в PDO, он всё ещё немного активен. У него инициирован парсинг параметров. Есть два вида синтаксиса параметров: анонимные параметры, представленные как «?» в вашем запросе на заполнение, и именованные параметры, вроде «:myparam». Не каждая RDBMS поддерживает оба синтаксиса, причём MySQL не поддерживает именованные, только анонимные. Однако наш предыдущий запрос завершён без проблем. Всё дело в том, что анализатор запросов PDO всё ещё активен, даже с отключённым уровнем эмуляции. Он вмешался и заменил каждый именованный параметр на анонимный
Я не пойму — это аргумент за «режим эмуляции» или против? Судя по тону автора, складывается впечатление, что второе.
Однако по отзывам знакомых программистов — это чуть ли не лучшее, что есть в PDO.
Поэтому отключите этот уровень эмуляции как можно скорее
Куда полезнее будет включить режим критического отношения к голословным утверждениям (это же относится к заявлениям еще одного противника режима эмуляции — А.Феррары, если вам случалось читать их на Stackoverflow).
У меня после запуска скрипта с статьи:
2ой столбец результат функции ( memory_usage с этого скрипта), 3ий ф. memory_get_usage() / 1000000
libmysql
initial memory ->79144 kB — 0.237144
resultSet stored ->95688 kB — 0.237472
query result saved ->170812 kB — 75.687992
resultSet freed ->154364 kB — 75.687952
saved result freed ->79760 kB — 0.237408
Db closed ->79760 kB — 0.236944
И после установки mysqlnd:
initial memory ->5524 kB — 0.244352
resultSet stored ->27172 kB — 2.646576
query result saved ->84524 kB — 61.295688
resultSet freed ->82212 kB — 75.694144
saved result freed ->80928 kB — 0.244744
Db closed ->80928 kB — 0.236944
Ubuntu 14.4.1 / php 5.5.9
2ой столбец результат функции ( memory_usage с этого скрипта), 3ий ф. memory_get_usage() / 1000000
libmysql
initial memory ->79144 kB — 0.237144
resultSet stored ->95688 kB — 0.237472
query result saved ->170812 kB — 75.687992
resultSet freed ->154364 kB — 75.687952
saved result freed ->79760 kB — 0.237408
Db closed ->79760 kB — 0.236944
И после установки mysqlnd:
initial memory ->5524 kB — 0.244352
resultSet stored ->27172 kB — 2.646576
query result saved ->84524 kB — 61.295688
resultSet freed ->82212 kB — 75.694144
saved result freed ->80928 kB — 0.244744
Db closed ->80928 kB — 0.236944
Ubuntu 14.4.1 / php 5.5.9
Sign up to leave a comment.
mysqlnd — проводник между PHP и MySQL