MySQL & MySQLi разница? | Mysql

Jack3d

MySQL & MySQLi в чем разница?

Гость

В «i»

Гость

MySQLi — это всего лишь драйвер (модуль) для языка PHP с помощью которого предоставляется доступ к серверу MySQL.

MySQL — сервер БД.

Гость

MySQLi от стандартного MySQL отличается работой кеша, это более новый вариант драйвера созданный специально под php 5, для самой базы данных все равно через какой из них работать

Гость

лучший ответ MySQLi поддерживает отправку множества запросов за раз (записанных единой строкой) — mysqli_multi_query используется для этого. В обычном расширении MySQL этого нет — только отпарвка отдельно взятого запроса через mysql_query
MySQLi поддерживает подготовленные выражения. Это означает, что можно отправить запрос серверу один раз, но без данных. Сервер разберет его, проанализирует, оптимизирует и подготовит план выполнения. Дальше вы шлете только данные, которые нужно использовать при выполнении запроса. Полезно, когда нужно выполнить множество однотипных запросов — нет нужды каждый раз выполнять синтаксический анализ и разбор выражения — делается все один раз, а потом идет непосредственно выполнение с разными данными (например, вставка множества строк в одну таблицу).

Расширение MySQL изначально этого не поддерживает, хотя и можно выкрутиться, вручную генерируя запросы к СУБД, сообщающие о необходимости подготовить выражение, с последующей отправкой запросов для простановки данных в переменные и требованием выполнить подготовленное ранее выражение.

Есть и еще ряд плюшек.

MySQLi поддерживает асинхронность в некоторой степени, хотя сделано это так себе. То есть Вы не можете назначить обработчик на событие «результат вернулся», а получаете результат все в том же контексте, что отправляли запрос (поэтому если результат еще не вернулся, все равно будет некоторый период ожидания).

С другой стороны расширение MySQL несколько быстрее MySQLi, поскольку просто предоставляет доступ к клиентской библиотеке libmysqlclient, в то время как MySQLi является дополнительной оберткой над ней, производящей дополнительные операции над данными, которые вы передаете в функции.
Однако, если вам нужны подготовленные выражения или возможность отправлять множество запросов, то MySQLi будет быстрее, чем собственная обертка над MySQL, написанная на PHP для поддержки этих возможностей.

Гость

Стоит заметить, что обе библиотеки теперь используют один и тот же драйвер — mysqlnd. MySQL предоставляет к нему почти прямой доступ, в то время как MySQLi является библиотекой-оберткой с дополнительной обработкой (то есть Просто использует mysqlnd где-то внутри).

Базовые различия при работе с базами данными MySQL и PostgreSQL Дилетантский обзор / Habr

Продолжая свое знакомство с БД PostgreSQL, с уже имеющимися навыками работы в БД MySQL, обнаружил ряд интересных полезных особенностей которые на практике часто не хватало в MySQL. Цель этого обзора не в создании бесконечного спора, что лучше, а дать легкое сравнение, которое обычно обсуждается программистами на обеденном перерыве в ближайшей кафешке. В сравнении обретаются новые знания и опыт, поэтому оно того стоит.

1. Вакансиях многих компаний довольно часто пишут требуемые знания через косую черту MySQL/PostgreSQL

На мой взгляд это совершенно разные базы данных и поэтому просто ставя между ними косую черту учитывая лишь во внимание написание схожих SQL запросов не совсем правильно. Все таки пару месяцев нужно для PostgreSQL, чтобы начать себя уверенно чувствовать в клиенте psql после MySQL.

Что я бы выделил на этапе компиляции из исходников этих двух БД,

1.1 PostgreSQL не имеет типы движков (MySQL — innodb, mysql, archive и т.д), но имеет кучу расширений, подобно PHP, которые можно дополнительно ставить, расширяя возможности. Создается впечатление, что PostgreSQL это своего рода каркас, который набиваешь функциональностью.

1.2 Разворачивание сервера MySQL сводиться лишь по сути к запуску сервера (systemctl start mysql.conf, service mysql start), тогда как в PostgreSQL нужно завести отдельного пользователя (в операционной системе) для запуска сервера, развернуть отдельно кластер (крутое слово, но по сути тоже самое, что и в MySQL — несколько баз данных на одном сервере)
1.3 Физическое указание расположения новых таблиц на диске (табличное пространство) на уровне SQL для PostgreSQL.

и т.д.

2. Различия в клиентах при запросах к БД — psql и mysql.

2.1 Что явно не хватает в MySQL, так это подобие команды \watch в psql, которая позволяет, указав секунды, повторять выполнение SQL запроса (аналог утилиты watch -n). Это обычно удобно для того, чтобы отслеживать как идет миграция (наполнение данных в таблицах)

select NOW() \watch 1;

2.2 В PostgreSQL по умолчанию все выполняемые запросы не отображают время исполнения, в отличие от MySQL, нужно дополнительно указывать команду \timing. Повторное выполнение команды отключает опцию. Такой прием часто встречается во многих настройках PostgreSQL, в отличие от MySQL, где это нужно писать более длинее. При этом, в PostgreSQL, когда смотришь справочную информацию, то рядом в круглых скобочках отображается текущее значение просматриваемой настройки. Очень удобно. Плохо только, что одним шрифтом теста идет, не сразу зрительно быстро воспринимается.

2.3 В PostgreSQL можно быстро просмотреть историю запросов из psql командой \s, тогда как в клиенте MySQL нужно использовать клавиши вверх/вниз задействую функционал readline библиотеки (либо смотреть историю команд отдельно от клиента mysql). Это часто нужно, когда тестируешь повторно запрос на использование индексов. Было бы удобней в PostgreSQL после набора \s вместо копирования запроса, набирать номер запроса, как это делается при profile в MySQL.

3. Есть много общих моментов, которые, к примеру в MySQL более удобны, а в PostgreSQL более сложны.

К примеру, вывод результата select, который не помещается по горизонтали. В обоих клиентах баз данных есть вертикальный вывод. Для MySQL достаточно добавить в конец запроса \G, тогда как в PostgreSQL в начале нужно выполнить \pset expanded. Когда нужно по быстрому просмотреть, вариант PostgreSQL на мой взгляд это не совсем удобно.

4. Особо интересный момент в PostgreSQL, в отличие от MySQL, это более тесная интеграция с bash оболочкой.

Можно из psql выполнять shell команды (наподобие как в vim редакторе :! pwd), сохранять в переменные результат и затем использовать в генерации SQL запросов. В MySQL это все можно тоже сделать, но более длинными и не всегда удобными путями.

5. PostgreSQL выделяется особой любовью к использованию переменных окружения (export) в отличие от MySQL.

Ты это чувствуешь сразу после того, как скомпилировал исходники и начинаешь “разворачивать” сервер, указывая путь к директории базы данных (-D или PGDATA).

На этом думаю, закончить свой беглый дилетантский обзор. Как я уже писал, целью является не позиционирование той или иной БД, а получение дополнительного опыта через сравнение. Для себя конкретно изучение PostgreSQL является дополнительным конкурентным техническим преимуществом.

MySQL и MongoDB — когда и что лучше использовать / Habr

Петр Зайцев показывает разницу между MySQL и MongoDB. Это — расшифровка доклада с Highload++ 2016.

Если посмотреть такой известный DB-Engines Ranking, то можно увидеть, что в течении многих лет популярность open source баз данных растет, а коммерческих — постепенно снижается.

Что еще более интересно: если посмотреть на вот это отношение для разных типов баз данных, то видно, что для многих типов — таких, как колунарные базы данных, time series, document stories — open source базы данных наиболее популярны. Только для более старых технологий, таких как реляционные базы данных, или еще более древних, как multivalue база данных, коммерческие лицензии значительно популярнее.

Мы видим, что для многих приложений используют несколько баз данных для того, чтобы задействовать их сильные стороны. Ни одна база данных не оптимизирована для всех всевозможных юзкейсов. Даже если это PostgreSQL [смех на сцене и в зале].

С одной стороны, это хороший выбор, с другой — нужно пытаться найти баланс, так как чем у нас больше разных технологий, тем сложнее их поддерживать, особенно, если компания не очень большая.

Часто что видим, что люди приходят на такие конференции, слушают Facebook или «Яндекс» и говорят: «Ух ты! Сколько вот люди делают интересного. У них технологий разных используется штук 20, и еще штук 10 они написали сами». А потом они тот же самый подход пытаются использовать в своем стартапе из 10 человек, что работает, разумеется, не очень хорошо. Это как раз тот случай, где размер имеет значение.

Очень часто мы видим, что используется основное операционное хранилище и какие-то дополнительные сервисы. Например, для кэширования или полнотекстового поиска.

Другой подход к архитектуре с использованием разных баз данных — это микросервисы, у каждого из которых может быть своя база данных, которая лучше оптимизирована для задач именно этого сервиса. Как пример: основное хранилище может быть на MySQL, Redis и Memcache — для кэширования, Elastic Search или родной Sphinx — для поиска. И что-то вроде Kafka — чтобы передавать данные в систему аналитики, которая часто делалась на чём-то вроде Hadoop.

Если мы говорим про основное операционное хранилище, наверное, у нас есть два выбора. С одной стороны, мы можем выбрать реляционные базы данных, с языком SQL. С другой стороны — что-то нереляционное, а дальше уже смотреть на подвиды, которые доступы в данном случае.

Если говорить про NoSQL-модели данных, то их тоже достаточно много. Наиболее типичные — это либо key value, либо document, либо wide column базы данных. Примеры: Memcache, MongoDB, Cassandra, соответственно.

Почему в данном случае мы сравниваем именно MySQL и MongoDB? На самом деле причин несколько. Если посмотреть на Ranking баз данных, то мы видим, что MySQL, согласно этому рейтингу, — наиболее популярная реляционная база данных, а MongoDB — наиболее популярная нереляционная база данных. Поэтому их разумно сравнивать.

А ещё у меня есть наибольший опыт в использовании этих двух баз данных. Мы в Percona занимаемся плотно именно с ними, работаем с многими клиентами, помогаем им сделать такой выбор. Еще одна причина: обе технологии изначально ориентированы на разработчиков простых приложений. Для тех людей, для которых PostgreSQL — это слишком сложно.

Компания MongoDB изначально очень активно фокусировалась на пользователях MySQL. Поэтому очень часто у людей есть опыт использования и выбор между этими двумя технологиями.

В Percona кроме того, что мы занимаемся поддержкой, консалтингом для этих технологий, у нас есть достаточно много написанного open source софта для обеих технологий. На слайде можно посмотреть. Подробно я рассказывать об этом не буду.

Что следует обо мне лично: я занимаюсь MySQL значительно больше, чем MongoDB. Несмотря на то, что я постараюсь предоставить сбалансированный обзор с моей стороны, у меня могут быть какие-то предрасположенности к MySQL, так как его тараканы я знаю лучше.

Вот список разных вопросов, которые на мой взгляд имеет смысл рассматривать. Сейчас из них рассмотрим каждый более детально.

Что наиболее важно на мой взгляд — это учитывать, какие есть опыт и предпочтения команды. Для многих задач подходят оба решения. Их можно сделать и так, и так, может быть несколько сложнее, может быть несколько проще. Но если у вас команда, которая долго работала с SQL-базами данных и понимает реляционную алгебру и прочее, может быть сложно перетягивать и заставлять их использовать нереляционные базы данных, такие как MongoDB, где нет даже полноценной транзакции.

И наоборот: если есть какая-то команда, которая использует и хорошо знает MongoDB, SQL-язык может быть для неё сложен. Также имеет смысл рассматривать как оригинальную разработку, так и дальнейшее сопровождение и администрирование, поскольку всё это в итоге важно в цикле приложения.

Какие есть преимущества у данных систем?

Если говорить про MySQL — это проверенная технология. Понятно, что MySQL используется крупными компаниями более 15 лет. Так как он использует стандарт SQL, есть возможность достаточно простой миграции на другие SQL-базы данных, если захочется. Есть возможность транзакций. Поддерживаются сложные запросы, включая аналитику. И так далее.

С точки зрения MongoDB, здесь преимущество то, что у нас гибкий JSON-формат документов. Для некоторых задач и каким-то разработчикам это удобнее, чем мучиться с добавлением колонок в SQL-базах данных. Не нужно учить SQL — для некоторых это сложно. Простые запросы реже создают проблемы. Если посмотреть на проблемы производительности, в основном они возникают, когда люди пишут сложные запросы с

JOIN в кучу таблиц и GROUP BY. Если такой функциональности в системе нет, то создать сложный запрос получается сложнее.

В MongoDB встроена достаточно простая масштабируемость с использованием технологии шардинга. Сложные запросы если возникают, мы их обычно решаем на стороне приложения. То есть, если нам нужно сделать что-то вроде JOIN, мы можем сходить выбрать данные, потом сходить выбрать данные по ссылкам и затем их обработать на стороне приложения. Для людей, которые знают язык SQL, это выглядит как-то убого и ненатурально. Но на самом деле для многих разработка application-серверов такое куда проще, чем разбираться с JOIN.

Если говорить про приложения, где используется MongoDB, и на чём они фокусируются — это очень быстрая разработка. Потому что всё можно постоянно менять, не нужно постоянно заботиться о строгом формате документа.

Второй момент — это схема данных. Здесь нужно понимать, что у данных всегда есть схема, вопрос лишь в том, где она реализуется. Вы можете реализовывать схему данных у себя в приложении, потому что каким-то же образом вы эти данные используете. Либо эта схема реализуется на уровне базы данных.

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

Здесь возникает также вопрос времени жизни приложения. С MongoDB хорошо делать приложения, у которых очень ограниченный цикл жизни. То есть если мы делаем приложение, которое живёт недолго, например, сайт для запуска фильма или олимпиады. Мы пожили несколько месяцев после этого, и это приложение практически не используется. Если приложение живёт дольше, то тут уже другой вопрос.

Если говорить про распределение преимуществ и недостатков MySQL и MongoDB с точки зрения цикла разработки приложения, то их можно представить так:

Модель данных очень сильно зависит от приложения и опыта команды. Было бы странным сказать, что у нас реляционный или нереляционный подход к базам данных лучше и лучше всегда.

Если сравнивать их между собой, то понятно, что у нас есть. В MySQL — реляционная база данных. Мы можем с помощью реляционной базы данных легко отображать связи между таблицами. Нормализуя данные, мы можем заставлять изменения данных происходить атомарно в одном месте. Когда данные у нас денормализованы, нам не нужно при каких-то изменениях бежать и модифицировать кучу документов.

Хорошо это или плохо? Результат — всегда таблица. С одной стороны, это просто, с другой — некоторые структуры данных не всегда хорошо ложатся на таблицу, нам может быть неудобно с этим работать.

Это всё в теории. Если говорить о практическом использовании MySQL, мы знаем, что часто денормализуем данные, иногда для некоторых приложений мы используем что-то подобное: храним JSON, XML или другую структуру в колонках приложения.

У MongoDB структура данных основана на документах. Данные многих веб-приложений отображать очень просто. Потому что если храним структуру — что-то вроде ассоциированного массива приложения, то это очень просто и понятно для разработчика сериализуется в JSON-документ. Раскладывать такое в реляционной базе данных по разным табличкам — задача более нетривиальная.

Результаты как список документов, у которых может быть совершенно разная структура — более гибкое решение.

Пример. Мы хотим сохранить контакт-лист с телефона. Понятно, что есть данные, которые хорошо кладутся в одну реляционную табличку: Фамилия, Имя и т.д. Но если посмотреть на телефоны или email-адреса, то у одного человека их может быть несколько. Если подобное хранить в хорошем реляционном виде, то нам неплохо бы это хранить в отдельных таблицах, потом это всё собирать JOIN, что менее удобно, чем хранить это всё в одной коллекции, где находятся иерархические документы.

Следует сказать, что это всё в строго реляционной теории — некоторые базы данных поддерживают массивы. В MySQL поддерживается формат JSON, в который можно засунуть такие вещи, как несколько email-адресов. Или многие годы люди серилизовали это ручками: надо нам сохранить несколько email-адресов, то давайте запишем их через запятую, и дальше приложение разберётся. Но как-то это не очень кошерно.

Интересно, что между MySQL и MongoDB — вообще, между реляционными и нереляционными СУБД — что-то совпадает, что-то различается. Например, в обоих случаях мы говорим о базах данных, но то, что мы называем таблицей в реляционной базе данных, часто в нереляционной называется коллекцией. То, что в MySQL — колонка, в MongoDB — поле. И так далее.

С точки зрения использования JOIN, в MongoDB нет такого понятия — это вообще понятие из реляционной структуры. Там мы либо делаем встроенный документ, что близко к концепту денормализации, либо мы просто сохраняем идентификатор документа в каком-то поле, называем это ссылкой и дальше ручками выбираем данные, которые нам нужны.

Что касается доступа: там, где мы к реляционным данным используем язык SQL, в MongoDB и многих других NoSQL-базах данных используется такой стандарт, как CRUD. Этот стандарт говорит, что есть операции для создания, чтения, удаления и обновления документов.

Несколько примеров.

Как у нас могут выглядеть наиболее типичные задачи по работе с документами в MySQL и MongoDB:

Вот пример вставки.

Пример обновления.

Пример удаления.

Если вы разработчик, который знаком с языком JavaScript, то такой синтаксис, который предоставляет CRUD (MongoDB), для вас будет более естественным, чем синтаксис SQL.

На мой взгляд, когда у нас есть простейшие операции: поиск, вставка, они все работают достаточно хорошо. Когда речь идёт о более интересных операциях выборки, на мой взгляд, язык SQL куда более читаемый.

&gt вместо простого знака «>». Не очень читаемо, на мой взгляд.

Достаточно легко с помощью интерфейса делать такие вещи, как подсчёт числа строк в таблице или коллекции.

Но если мы делаем более сложные вещи, например, GROUP BY, в MongoDB для этого требуется использовать Aggregation Framework. Это несколько более сложный интерфейс, который показывает, как мы хотим отфильтровать, как мы хотим группировать и т.д. Aggregation Framework уже поддерживает что-то вроде операций JOIN.

Следующий момент — это транзакции и консистентность (ACID). Если пойти и почитать документацию MongoDB, там будет: «Мы поддерживаем ACID-транзакции, но с ограничением». На мой взгляд, стоит сказать: «ACID мы не поддерживаем, но поддерживаем другие минимальные нетранзакционные гарантии».

Какая у нас между ними разница?

Если говорить про MySQL, он поддерживает ACID-транзакции произвольного размера. У нас есть атомарность этих транзакций, у нас есть мультиверсионность, можно выбирать уровень изоляции транзакций, который может начинаться с READ UNCOMMITED и заканчиваться SERIALIZABLE. На уровне узла и репликаций мы можем конфигурировать, как данные хранятся.

Мы можем сконфигурировать у InnoDB, как работать с лог-файлом: сохранять его на диск при коммите транзакции или же делать это периодически. Мы можем сконфигурировать репликацию, включить, например, Semisynchronous Replication, когда у нас данные будут считаться сохранёнными только тогда, когда их копия будет принята на одном из slave’ов.

MongoDB не поддерживает транзакции, но он поддерживает атомарные операции над документом. Это значит, что с точки зрения одного документа операция у нас будет атомарна. Если у нас операция изменяет несколько документов, и во время этой операции произойдет какой-то сбой внутри, то какие-то из этих документов могут быть изменены, а какие-то — не изменены.

Консистентность тоже делается на уровне документов. В кластере мы можем выбирать гибкую консистентность. Мы можем указать, какие мы хотим гарантии — гарантии, что у нас данные были записаны только на один узел, или они были реплицированы на все узлы кластеров. Чтение консистентности тоже происходит на уровне документа.

Есть такой вариант обновления isolated, который позволяет выполнить обновление изолированно от других транзакций, но он очень неэффективен — он переключает базы данных в монопольный режим доступа, поэтому он используется достаточно редко. На мой взгляд, если говорить про транзакции и консистентность, то MongoDB достаточна убогая.

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

Это результаты бенчмарка, который делал Марк Каллаган. Здесь видно, что с точки зрения использования процессора, ввода/вывода MySQL — как InnoDB, так и MyRocks — использует значительно меньше процессора и дискового ввода/вывода на операции бенчмарка Linkbench от Facebook.

Масштабируемость.

Что такое масштабируемость в данном контексте? То, насколько легко нам взять наше маленькое приложение и масштабировать его на многие миллионы, может быть, даже на миллиарды пользователей.

Масштабируемость бывает разная. Она бывает средняя, в рамках одной машины, когда мы хотим поддерживать приложения среднего размера, либо масштабируемость на кластере, когда у нас приложения уже очень большие, когда понятно, что даже одна самая мощная машина не справится.

Также имеет смысл говорить о том, масштабируем ли мы чтение, запись или объем данных. В разных приложениях их приоритеты могут различаться, но в целом, если приложение очень большое, обычно им приходится работать со всеми из этих вещей.

В MySQL в новых версиях весьма хорошая масштабируемость в рамках одного узла для LTP-нагрузок. Если у нас маленькие транзакции, есть какое-нибудь железо, в котором 64 процессора, то масштабируется достаточно хорошо. Аналитика или сложные запросы масштабируются плохо, потому что MySQL может использовать для одного запроса только один поток, что плохо.

Традиционно чтение в MySQL масштабируется с репликацией, запись и размер данных — через шардинг. Если смотреть на все большие компании — Facebook, Twitter — они все используют шардинг. Традиционно шардинг в MySQL используется вручную. Есть некоторые фреймворки для этого. Например, Vitess — это фреймворк, который Google использует для scaling сервиса YouTube, они его выпустили в open source. До этого был framework Jetpants. Стандартного решения для шардинга MySQL не предлагает, часто переход на шардинг требует внимания от разработчиков.

В MongoDB фокус изначально был в масштабируемости на многих узлах. Даже в случаях с маленьким приложением многим рекомендуется использовать шардинг с самого начала. Может, всего пару replica set, потом вы будете расти вместе со своим приложением.

В шардинге MongoDB есть некоторые ограничения: не все операторы с ним работают, например, есть isolated-вариант для обеспечения консистентности. Она не работает если использовать шардинг. Но при этом многие основные операции хорошо работают в шардингом, поэтому людям позволяется scale’ить приложения значительно лучше. На мой взгляд, шардинг и вообще репликация в MongoDB сделаны куда лучше, чем MySQL, значительно проще в использовании для пользователя.

Администрирование – это все те вещи, о которых не думают разработчики. По крайней мере в первую очередь. Администрирование — это то, что нам приложение придётся бэкапить, обновлять версии, мониторить, восстановливать при сбоях и так далее.

MySQL достаточно гибок, у него есть много разных подходов. Есть хорошие open source реализации всего, но это множество вариантов порождает сложность. Я часто общаюсь с пользователями, которые только начинают изучать MySQL. Они говорят: «Ёлки-палки, сколько же у вас всего вариантов. Вот только репликация — какую мне использовать: statement-репликацию, raw-репликацию, или mix? А еще есть gtid и стандартная репликация. Почему нельзя сказать „просто работай“?»

В MongoDB всё больше ориентированно на то, что оно работает каким-то одним стандартным образом — есть минимизация администрирования. Но понятно, что это происходит при потере гибкости. Коммьюнити open source решений для MongoDB значительно меньше. Многие вещи в MongoDB с точки зрения рекомендаций достаточно жестко привязаны к Ops Manager — коммерческой разработке MongoDB.

Как в MongoDB, так и в MySQL есть мифы, которые были в прошлом, которые были исправлены, но у людей хорошая память, особенно если что-то не работает. Помню, в MySQL после того как появились транзакции с InnoDB, люди мне лет десять говорили: «А в MySQL нет же транзакций?»

В MongoDB было много разных проблем с производительностью MMAP storage engine: гигантские блокировки, неэффективное использование дискового пространства. Сейчас в стандартном движке WiredTiger уже нет многих из этих проблем. Есть другие проблемы, но не эти.

«Нет контроля схемы» — ещё такой миф. В новых версиях MongoDB можно для каждой коллекции определить на JSON структуру, где данные будут валидироваться. Данные, которые мы пытаемся вставить, и они не соответствуют какому-то формату, можно выкидывать.

«Нет аналога JOIN» — то же самое. В MongoDB это появилось, но нескольких ограниченных вещах. Только на уровне одного шарда и только если мы используем Aggregation Framework, а не в стандартных запросах.

Какие у нас есть мифы в MySQL? Здесь я буду говорить больше о поддержке NoMySQL решений в MySQL, об этом я буду говорить завтра. Следует сказать, что MySQL сейчас тоже можно использовать через интерфейс CRUD’a, использовать в NoSQL режиме примерно как MongoDB.

Типичный пример, где используется MySQL-решение — это сайт электронной коммерции. Когда у нас идёт вопрос о деньгах, часто мы хотим полноценные транзакции и консистентность. Для таких вещей хорошо подходит реляционная структура, которая была проработана, и commerce на реляционных базах данных уже делается многие десятилетия. Так что можно взять один из готовых подходов к структуре данных и использовать его.

Обычно с точки зрения e-commerce объем данных у нас не такой большой, так что даже достаточно большие магазины могут долго работать без шардинга. Приложения у нас постоянно разрабатываются и усовершенствуется на протяжении многих лет. И у этого приложения много компонент, которые работают с одними и теми же данными: кто-то рассчитывает, где цены поменять, кто-то ещё что-то делает.

MongoDB часто задействуется как бэкенд больших онлайн-игр. Electronic Arts для очень многих игр использует MongoDB. Почему? Потому что масштабируемость важна. Если какая-то игра хорошо выстрелит, её приходится масштабировать значительно больше, чем предполагалось.

С другой стороны, если не выстрелит, нам хотелось бы, чтобы инфраструктуру можно было бы уменьшить. Во многих играх это идет так: мы запустили игру, у нее есть какой-то пик, приходится делать большой кластер. Потом игра уже выходит из популярности, для неё бэкенд нужно сжимать, сохранять и использовать. В данном случае есть одно приложение (игра), база данных, с одной стороны, несложная, с другой — сильно привязанная к приложению, в котором хранятся все важные для игры параметры.

Часто консистентность базы данных на уровне объектов здесь достаточна, потому что многие вопросы консистентости решаются на уровне приложения. Например, данные одного игрока сохраняет только один application service.

Всем рекомендую это старое, древнее, но очень смешное видео http://www.mongodb-is-web-scale.com/ [YouTube]. На этом мы закончим.

MySQL и MongoDB — когда что лучше использовать?

MySQL шпаргалки / Habr

Часто, когда разрабатываешь сайт, замечаешь, как на одни и те же грабли наступают разработчики при проектировании базы данных.

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

Работа с бекапами

Делаем бекап
mysqldump -u USER -pPASSWORD DATABASE > /path/to/file/dump.sql

Создаём структуру базы без данных
mysqldump --no-data - u USER -pPASSWORD DATABASE > /path/to/file/schema.sql

Если нужно сделать дамп только одной или нескольких таблиц
mysqldump -u USER -pPASSWORD DATABASE TABLE1 TABLE2 TABLE3 > /path/to/file/dump_table.sql

Создаём бекап и сразу его архивируем
mysqldump -u USER -pPASSWORD DATABASE | gzip > /path/to/outputfile.sql.gz

Создание бекапа с указанием его даты
mysqldump -u USER -pPASSWORD DATABASE | gzip > `date +/path/to/outputfile.sql.%Y%m%d.%H%M%S.gz`

Заливаем бекап в базу данных
mysql -u USER -pPASSWORD DATABASE < /path/to/dump.sql

Заливаем архив бекапа в базу
gunzip < /path/to/outputfile.sql.gz | mysql -u USER -pPASSWORD DATABASE
или так
zcat /path/to/outputfile.sql.gz | mysql -u USER -pPASSWORD DATABASE

Создаём новую базу данных
mysqladmin -u USER -pPASSWORD create NEWDATABASE

Удобно использовать бекап с дополнительными опциями -Q -c -e, т.е.
mysqldump -Q -c -e -u USER -pPASSWORD DATABASE > /path/to/file/dump.sql, где:

• -Q оборачивает имена обратными кавычками
• -c делает полную вставку, включая имена колонок
• -e делает расширенную вставку. Итоговый файл получается меньше и делается он чуть быстрее

Для просмотра списка баз данных можно использовать команду:
mysqlshow -u USER -pPASSWORD

А так же можно посмотреть список таблиц базы:
mysqlshow -u USER -pPASSWORD DATABASE

Для таблиц InnoDB надо добавлять —single-transaction, это гарантирует целостность данных бекапа.
Для таблиц MyISAN это не актуально, ибо они не поддерживают транзакционность.

Подробнее

Общие факты

• Полезно под каждую базу на боевом сервере создавать своего пользователя
• Кодировка базы может быть любой, если она UTF8
• В большинстве случаев лучше использовать движок InnoDB
• В php лучше забыть про сильно устаревшее расширение mysql и по-возможности использовать pdo или mysqli
• Новую копию MySQL всегда можно настроить и оптимизировать
• Без особой нужды не стоит открывать MySQL наружу. Вместо этого можно сделать проброс портов
  ssh -fNL LOCAL_PORT:localhost:3306 REMOTE_USER@REMOTE_HOST

Работа с данными

Числа

• На 32-битных системах практически нет смысла ставить для типа INTEGER свойство UNSIGNED, так как такие большие числа в php не поддерживаются.
  На 64-битных системах, php поддерживает большие числа, вплоть до MySQL BIGINT со знаком.
• Связанные таблицы («Foreign keys») должны иметь полное сходство по структуре ключей. Т.е. если у нас на одной таблице для поля указано «INTEGER UNSIGNED DEFAULT 0 NOT NULL» то и на другой должно быть указано аналогично
• Для хранения булевых значений, нужно использовать TINYINT(1)
• А деньги лучше хранить в DECIMAL(10, 2), где первое число обозначает количество всех знаков, включая запятую, а второе — количество знаков после запятой. Итого, у нас получится что DECIMAL(10,2) может сохранить 9999999,99

Строки

• В старых версиях (до 5.0.3) VARCHAR была ограничена 255 символами, но сейчас можно указывать до 65535 символов
• Помните, что тип TEXT ограничен только 64 килобитами, поэтому что бы сохранять «Войну и Мир» пользуйтесь «LONGTEXT»
• Самая правильная кодировка для вашей БД UTF8

Даты

Не забывайте, что

• DATE, TIME, DATETIME — выводятся в виде строк, поэтому поиск и сравнение дат происходит через преобразование
• TIMESTAMP — хранится в виде UNIX_TIMESTAMP, и можно указать автоматически обновлять колонку
• Сравнивая типы данных DATETIME и TIMESTAMP, не забывайте делать преобразование типов, например:
  SELECT * FROM table WHERE `datetime` = DATE(`timestamp`)

Перечисления

• Для перечислений правильно использовать тип ENUM
• Правильно пишется так: ENUM(‘мама’, ‘мыла’, ‘раму’)
• Можно ставить значение по-умолчанию, как и для любой строки
• В базе поле с перечислением хранится как число, поэтому скорость работы — потрясающе высокая
• Количество перечислений ~ 65 тысяч

dev.mysql.com/doc/refman/4.1/en/storage-requirements.html
help.scibit.com/mascon/masconMySQL_Field_Types.html

Отладка

• Если запросы тормозят, то можно включить лог для медленных запросов в /etc/mysql/my.cnf
• А потом оптимизировать запросы через EXPLAIN
• И наблюдать за запросами удобно через программу mytop

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

Разница между mysqli и mysql? PHP Lang

Я создаю большую базу данных и задаюсь вопросом, что лучше всего использовать?

Я сейчас дезинфицирую свои ценности и избегая символов для обеспечения безопасности, но я хотел бы узнать различные преимущества этих запросов mysql в php?

Благодарю.

Используйте MySQLi над более старыми функциями MySQL. «I» означает «улучшено». Список улучшений можно найти в документах .

Прежде всего, вам лучше использовать PDO (как предлагал Lior) или промежуточный уровень (закодированный вами) между вашим кодом и функциями базы данных, предоставляемыми PHP, так что вы можете легко изменить mysql с помощью mysqli или любым другим, что вам нравится, без повторного редактирования весь ваш код.

Что касается различий, mysqli имеет больше функциональных возможностей (есть множество новых функций), а также объектно-ориентированный.

Почему бы не использовать PDO? У вас есть преимущество подготовленных заявлений среди других функций там, и это будет разумным решением, если вы решите переехать в другую БД один день.

http://php.net/manual/en/book.pdo.php

Если вы настаиваете на использовании одного из вышеперечисленных вариантов, MySQLi в основном является более объектно-ориентированным подходом к стандартному расширению mysql. По большей части они функционально одинаковы. Если вы создаете приложение на основе ООП, MySQLi, вероятно, будет более мудрым и более последовательным выбором.

С моей точки зрения, основное отличие (улучшение) заключается в том, что mysqli позволяет выполнять несколько запросов; что, в свою очередь, позволяет выполнять (и извлекать результаты) хранимые процедуры с параметрами out или возвращать результаты.

Я согласен с другими, что использование PDO – лучший выбор.

Для всех, кто говорит, чтобы использовать PDO. Это только для подготовленных заявлений? Потому что вы можете делать подготовленные инструкции в mySQLi без PDO . Просто FYI.

PHP: критика перехода с оригинального API MySQL на mysqli и PDO

Оригинальный API MySQL (функции mysql_*() — например, mysql_query() и пр.) с версии PHP 5.5.0 объявлен устаревшим. Вместо него разработчики PHP рекомендуют использовать модуль mysqli или объекты данных PHP (PDO). Эти средства обладают расширенным по сравнению с традиционным API функционалом, но действительно ли они удобнее в повседневной практике?

mysqli

mysqli — «MySQL improved extension» («улучшенный модуль MySQL») — прямой наследник оригинального API MySQL, обладающий более широкими возможностями. Чтобы почувствовать разницу, достаточно посмотреть на список его методов и сравнить с таковым оригинального модуля. Однако нужно отметить, что отличие в реальных возможностях на самом деле только одно: mysqli имеет возможность отправки множественных запросов¹. Хотя иметь такую возможность и удобно, на практике её наличие ощутимой роли не играет².

Другими словами, разницы в реальных возможностях обычного и улучшенного модулей практически нет. Зато есть разница в интерфейсе. Рассмотрим, как в простейшем случае выглядит самая обычная операция — установление соединения с сервером MySQL и выполнение запроса:

// оригинальный модуль
mysql_connect(‘host’, ‘user’, ‘password’);
mysql_query(«SELECT 1»);

// улучшенный модуль, процедурный интерфейс
$mysqli = mysqli_connect(‘host’, ‘user’, ‘password’);
mysqli_query($mysqli, «SELECT 1»);

// улучшенный модуль, объектный интерфейс
$mysqli = new mysqli($host, $user, $password);
$mysqli->query(«SELECT 1»);    

Здесь важно заметить, что функция mysql_query() не требует передавать в явном виде указатель на соединение (хотя и позволяет это делать). В подавляющем большинстве случаев для работы требуется только одно соединение с MySQL, и, однажды установив его, вполне удобно и естественно просто вызывать mysql-функции, не ссылаясь на соединение в явном виде каждый раз.

Функция же mysqli_query(), напротив, требует передавать объект, указывающий на соединение. Этот объект потребуется во всех местах, где нужно будет делать запрос. Это означает, что в коде с локальной областью видимости — функциях и классах — придется либо заводить глобальную переменную, либо передавать этот объект явно.

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

Резюмируя сказанное, приходится констатировать, что на практике модуль mysqli не обладает какой-то дополнительной полезностью по сравнению с оригинальным. Пользоваться же им менее удобно.

PDO

PHP Data Object (Объекты данных PHP) — расширение языка, определяющее абстрактный интерфейс доступа к базам данных (это означает, что одни и те же методы PDO могут использоваться для разных СУБД).

На практике реально ощутимым отличием PDO от других интерфейсов к MySQL является возможность легко делать следующие две операции:

• вставку в запрос параметров с экранированием
• получение результата запроса в виде ассоциативного массива

Работа с MySQL, в основном, и заключается именно в этих двух вещах, поэтому многие разработчики останавливают свой выбор на PDO.

Однако есть один нюанс. Рассмотрим, как в самом простом случае средствами PDO выполняется запрос:

$DBH = new PDO(‘mysql:host=…;dbname=…’, ‘user’, ‘password’); // соединяемся с БД
$query = $DBH->prepare(«SELECT 1»); // готовим запрос
$query->execute(); // выполняем запрос

Важно отметить, что для отправки запроса требуется вызывать не один метод, а два — prepare(), а затем execute(). На уровне механизма СУБД в данном случае задействуются т.н. prepared statements — специальный инструмент СУБД, позволяющий ускорить последовательное выполнение повторяющихся запросов, построенных по одному и тому же шаблону.

Вместе с тем, на практике идущие подряд однотипные запросы встречаются довольно редко. Напротив, обычно запросы разные, и это полностью нивелирует положительный эффект от предварительного разбора. Более того, в конечном итоге вместо одного запроса к MySQL делается два, в результате чего схема с prepare() и execute() оказывается даже медленнее обычного одиночного запроса.

PDO позволяет выполнить запрос и напрямую — для этого предназначен метод query(). Однако при использовании этого метода вставку в запрос параметров и их экранирование приходится проводить вручную, поэтому query() не пользуется популярностью и разработчики предпочитают связку из prepare() и execute() в любом случае, потому что это удобнее.

Следует также подчеркнуть, что при использовании PDO (как и в случае с mysqli) есть необходимость заводить объект, который в областях видимости функций и классов недоступен.

Резюмируя сказанное, нужно отметить, что по сравнению с другими модулями PDO предоставляет несколько более удобный функционал, однако реализация его выполнена неоптимально. Кроме того, высокий уровень абстракции интерфейса плохо сказывается на осведомлённости разработчиков о происходящем на стороне MySQL-сервера.

Что делать?

Одним из решений всех вышеперечисленных проблем является библиотека удобных функций MySQL, при разработке которой основной целью было сделать программирование самых распространенных операций при работе с MySQL (таких как сохранение результата запроса в виде ассоциативного массива, обработка ошибок, подстановка массива в запрос) максимально удобным. Вот несколько примеров:

// если в глобальной области видимости есть переменная $mysqli,
// библиотека будет пользоваться инструментами mysqli,
// в противном случае — оригинального модуля MySQL

// включаем mysqli
$mysqli = mysqli_connect(…);

// простая отправка запроса
mysql_q(«TRUNCATE sometable»);

// получение результата скалярного (один столбец, одна строка) запроса
$now = mysql_getcell(«SELECT NOW()»);

// получение строки таблицы:
$row = mysql_getrow(«
    SELECT *
    FROM watches
    WHERE id = 1052
    «);
   
// получение столбца в виде одномерного массива:
$ids = mysql_getcolumn(«
    SELECT id
    FROM watches
    WHERE mark = ‘Edox’ AND price > 5000
    «);

// получение записей таблицы с подстановкой в запрос параметров:
$sql = «
    SELECT *
    FROM watches
    WHERE mark = :mark AND price > :price
    «;
$params = array( ‘mark’ => ‘Edox’, ‘price’ => 5000 );
$data = mysql_gettable($sql, FALSE, $params);

// подстановку можно делать во всех вышеперечисленных функциях

Подробнее о библиотеке можно прочитать в соответствующей статье.

© Все права на данную статью принадлежат порталу webew.ru. Перепечатка в интернет-изданиях разрешается только с указанием автора и прямой ссылки на оригинальную статью. Перепечатка в печатных изданиях допускается только с разрешения редакции.

Разница между SQL и MySQL

Вы здесь: Главная — MySQL — MySQL Основы — Разница между SQL и MySQL

Прежде, чем приступить к статье, объяснющей разницу между SQL и MySQL, я поздравлю Вас с Новым годом, годом кролика. Желаю в Новом году Вам побольше удачи, побольше целеустремлённости и побольше упорства. Ведь главное в жизни — это достигать своих целей, а они достигаются только упорными людьми. Будьте упорны и настойчивы, и тогда в Новом году Вы будете победителем в любой сфере! А теперь вернёмся к делу.

Я достаточно часто встречаю вопрос: «Какая разница между SQL и MySQL«, и я решил ответить на этот вопрос, несмотря на всю его абсурдность. Ведь с тем же успехом можно спросить: «Какая разница между сервером Apache и PHP«, но это почему-то никто не спрашивает.

В общем, отвечаю на вопрос. SQL — это язык запросов для управления СУБД (система управления базами данных). А MySQL — это одна из таких СУБД. В частности, помимо MySQL существуют и другие СУБД: Oracle, MS SQL Server, PostgreSQL и много других. И чтобы работать (сделать выборку, вставить новую запись, добавить новую таблицу и так далее) с любой из этих СУБД необходим язык запросов, и таким языком и является SQL.

Резюме:

• SQL — язык запросов для управления СУБД.
• MySQL — это одна из множества других СУБД.

Надеюсь, я ответил на этот один из самых популярных вопросов среди новичков, которые только начинают заниматься базами данных. Хотя нет, Вы не новички, Вы молодцы! Как показывает практика, люди не двигаются дальше HTML и CSS (редко JavaScript). И если Вы решили заниматься базами данных, то Вы уже герой! Так что Вы не новички, а просто начинающие познавать действительно важные и, в общем-то, сложные вещи. Удачи Вам в этом!

Удачи и успеха в Новом году!

Ваш покорный слуга, Михаил Русаков!

• Создано 31.12.2010 16:01:29
• Михаил Русаков

Следующая статья

Копирование материалов разрешается только с указанием автора (Михаил Русаков) и индексируемой прямой ссылкой на сайт (http://myrusakov.ru)!

Добавляйтесь ко мне в друзья ВКонтакте: http://vk.com/myrusakov.
Если Вы хотите дать оценку мне и моей работе, то напишите её в моей группе: http://vk.com/rusakovmy.

Если Вы не хотите пропустить новые материалы на сайте,
то Вы можете подписаться на обновления: Подписаться на обновления

Если у Вас остались какие-либо вопросы, либо у Вас есть желание высказаться по поводу этой статьи, то Вы можете оставить свой комментарий внизу страницы.

Порекомендуйте эту статью друзьям:

Если Вам понравился сайт, то разместите ссылку на него (у себя на сайте, на форуме, в контакте):

1. Кнопка:
   <a href=»https://myrusakov.ru» target=»_blank»><img src=»https://myrusakov.ru/images/button.gif» alt=»Как создать свой сайт» /></a>

   Она выглядит вот так:

2. Текстовая ссылка:
   <a href=»https://myrusakov.ru» target=»_blank»>Как создать свой сайт</a>

   Она выглядит вот так: Как создать свой сайт

3. BB-код ссылки для форумов (например, можете поставить её в подписи):
   [URL=»https://myrusakov.ru»]Как создать свой сайт[/URL]