В MySQL выборку с помощью JOIN можно производить разными способами. Мы постараемся рассмотреть все эти виды запросов. Вот список всех запросов с участием JOIN:
А вот иллюстрация к этим видам JOIN:
Я прикреплю к статье файлы нашего сайта, среди которых будет join.php в которых я буду выводить все записи с помощью разных операторов JOIN.
INNER JOINНачнем мы с этого оператора INNER JOIN, потому что этот оператор срабатывает по умолчанию, если вы пишите в запросе просто JOIN. Этот оператор выбирает все записи из двух таблиц, где выполняется условие идущее после оператора ON. У нас есть две таблицы Files и Messages:
Таблица Messages:
Запрос с JOIN будет следующий:
SELECT * FROM Messages INNER JOIN Files ON Messages.fid=Files.fid
В результате будут выведены такие записи
Таблица Files:
LEFT JOIN будет нужен когда выводим все записи сообщений, а есть или нет прикрепленный файл, мы проверим уже через PHP.
LEFT JOIN без пересечений с правой таблицейLEFT JOIN выводит все записи из левой таблицы, кроме тех в которых fid совпадают в правой таблице.
Таблица Messages:
Запрос с LEFT JOIN без пересечений будет следующий:
SELECT * FROM Messages LEFT JOIN Files ON Messages.fid=Files.fid WHERE Files.fid IS NULL
В результате мы получим вот такую вот выборку:
Таблица Files:
RIGHT JOIN будет нужен когда выводим все прикрепленные файлы без разницы используются они или нет, просто все файлы.
RIGHT JOIN без пересеченийRIGHT JOIN без пересечений выводит все записи из правой таблицы, кроме тех где есть пересечения с левой таблицей.
Таблица Messages:
Запрос с RIGHT JOIN без пересечений будет следующий:
SELECT * FROM Messages RIGHT JOIN Files ON Messages.fid=Files.fid WHERE Messages.fid IS NULL
Таким образом мы получим следующие данные:
| mid | bodytext | fid | path |
| NULL | NULL | 1 | /files/1.png |
RIGHT JOIN будет нужен когда выводим все прикрепленные файлы, которые не прикреплены ни к каким сообщениям. Например, если мы хотим вывести файлы которые не используются.
FULL OUTER JOINНесмотря на то что в языке SQL есть FULL OUTER JOIN, в MySQL этого оператора нет . Дело в том что подобный оператор это огромная нагрузка на сервер. Сейчас у нас 3 файла и 3 сообщения, при этом образуется 4 строк в результате выполнения запроса. Я не уверен, что это хорошая идея писать запрос, который дает в совокупности два запроса LEFT JOIN и RIGHT JOIN. Но все же есть возможность эмулировать запрос FULL OUTER JOIN.
Таблица Messages:
Эмуляция запроса с FULL OUTER JOIN будет следующей:
SELECT * FROM Messages LEFT JOIN Files ON Messages.fid = Files.fid UNION SELECT * FROM Messages RIGHT JOIN Files ON Messages.fid = Files.fid
В этом запросе мы используем оператор UNION, чтобы объединить два запроса LEFT JOIN и RIGHT JOIN.
В результате мы получим следующие записи:
| mid | bodytext | fid | path |
| 1 | Test | 2 | /files/2.png |
| 2 | Hi | NULL | NULL |
| 3 | Hello | 3 | /files/3.png |
| NULL | NULL | 1 | /files/1.png |
И здесь я уже затрудняюсь сказать зачем потребуется FULL OUTER JOIN. Но раз это есть в SQL, то видимо потребуется потом.
FULL OUTER JOIN без пересеченийЕще один вид JOIN еще более безумный, чем просто FULL OUTER JOIN, а именно FULL OUTER JOIN без пересечений. Я даже не могу предложить где можно использовать этот вид JOIN. Потому что в результате мы получаем файлы которые не используются и сообщения без файлов. И как вы наверно уже догадались этого оператора тоже нет в MySQL. Остается его только эмулировать с помощью двух операторов LEFT JOIN без перечений и RIGHT JOIN без пересечений.
Эмуляция запроса FULL OUTER JOIN без пересечений:
$sql = "SELECT * FROM Messages LEFT JOIN Files ON Messages.fid = Files.fid WHERE Files.fid IS NULL UNION SELECT * FROM Messages RIGHT JOIN Files ON Messages.fid = Files.fid WHERE Messages.fid IS NULL";
В результате (исходные таблицы те же что и в примере с FULL OUTER JOIN) мы получим:
| mid | bodytext | fid | path |
| 2 | Hi | NULL | NULL |
| NULL | NULL | 1 | /files/1.png |
Вот наверно и все, в следующих уроках мы начнем писать еще более сложные запросы к нескольким таблицам сразу.
Forms are part of virtually any web application today. They are the main method to receive input from people using the application. They range in size from one-field opt-in forms where you only enter your email address, to very long forms with tens or even hundreds of fields.
To make long forms user-friendlier, it is a good idea to span the form on multiple pages. This can make it easier to follow for the user, and we can also split the data in separate sections, based on the scope (for example separate personal customer information from payment data in a shopping cart checkout form).
One of the challenges that arise from splitting the form over multiple pages is passing the data from one page to another, as at the final point of the form, we have all the needed data ready for processing. We are going to look at two methods to do this: session variables and hidden input fields.
What are sessions anyway?A HTML session is a collection of variables that keeps its state as the user navigates the pages of a certain site. It will only be available to that domain that created it, and will be deleted soon after the user left the site or closed his browser.
So, the session has a semi-permanent nature, and it can be used to pass variables along different pages on which the visitor lands during a visit to the site.
Multi-page form using sessionsIn our example, we are going to create a three pages form, resembling a membership signup and payment form. The first page will ask for customer’s name and address, on the second page there is the choice for membership type, and on the third and final page, payment data must be entered. Final step is saving the data in MySQL.
The first file we are going to create (step 1 of the form) will contain just a simple form with two fields.
Ok, so nothing more than 2 input fields and a submit button to take us to step 2. In the following page, apart from the HTML form to gather membership data, we are going to need code to store the submitted data from step 1 in the session.
Now that we created step 3 of the form, what’s left is the final processing script that inserts the data in the MySQL database.
And we are done. Please note that in the final query, we are using data from the $_SESSION array, and also data from the $_POST array, that was posted from the last step of the form.
Последнее обновление: 1.11.2015
Одним из основных способов передачи данных веб-сайту является обработка форм. Формы представляют специальные элементы разметки HTML, которые содержат в себе различные элементы ввода - текстовые поля, кнопки и т.д. И с помощью данных форм мы можем ввести некоторые данные и отправить их на сервер. А сервер уже обрабатывает эти данные.
Создание форм состоит из следующих аспектов:
Создание элемента в разметке HTML
Добавление в этот элемент одно или несколько поле ввода
Установка метода передачи данных: GET или POST
Установка адреса, на который будут отправляться введенные данные
Итак, создадим новую форму. Для этого определим новый файл form.php , в которое поместим следующее содержимое:
Вход на сайт
Логин:
Пароль:
Атрибут action="login.php" элемента form указывает, что данные формы будет обрабатывать скрипт login.php , который будет находиться с файлом form.php в одной папке. А атрибут method="POST" указывает, что в качестве метода передачи данных будет применяться метод POST.
Теперь создадим файл login.php , который будет иметь следующее содержание:
Чтобы получить данные формы, используется глобальная переменная $_POST . Она представляет ассоциативный массив данных, переданных с помощью метода POST. Используя ключи, мы можем получить отправленные значения. Ключами в этом массиве являются значения атрибутов name у полей ввода формы.
Так как атрибут name поля ввода логина имеет значение login (), то в массиве $_POST значение этого поля будет представлять ключ "login": $_POST["login"]
И поскольку возможны ситуации, когда поле ввода будет не установлено, например, при прямом переходе к скрипту: http://localhost:8080/login.php . В этом случае желательно перед обработкой данных проверять их наличие с помощью функции isset() . И если переменная установлена, то функция isset() возвратит значение true .
Теперь мы можем обратиться к форме:
И по нажатию кнопки введенные данные методом POST будут отправлены скрипту login.php :
Необязательно отправлять данные формы другому скрипту, можно данные формы обработать в том же файле формы. Для этого изменим файл form.php следующим образом:
Вход на сайт
Логин:
Пароль:
Большое значение в PHP имеет организация безопасности данных. Рассмотрим несколько простых механизмов, которые могут повысить безопасность нашего веб-сайта.
Но вначале возьмем форму из прошлой темы и попробуем ввести в нее некоторые данные. Например, введем в поле для логина "alert(hi);", а в поле для пароля текст "пароль":
После отправки данных в html разметку будет внедрен код javascript, который выводит окно с сообщением.
Чтобы избежать подобных проблем с безопасностью, следует применять функцию htmlentities() :
If(isset($_POST["login"]) && isset($_POST["password"])){
$login=htmlentities($_POST["login"]);
$password = htmlentities($_POST["password"]);
echo "Ваш логин: $login
Ваш пароль: $password";
}
И даже после ввода кода html или javascript все теги будут экранированы, и мы получим следующий вывод:
Еще одна функция - функция strip_tags() позволяет полностью исключить теги html:
If(isset($_POST["login"]) && isset($_POST["password"])){
$login=strip_tags($_POST["login"]);
$password = strip_tags($_POST["password"]);
echo "Ваш логин: $login
Ваш пароль: $password";
}
Результатом ее работы при том же вводе будет следующий вывод.
На протяжении немалого времени, в начале своей карьеры веб-разработчика, я работал с базой данный как умел, а умел я не многое. Составлял простые примитивные запросы, а порою даже вставлял запросы в циклы. На тот момент мне к сожалению не попалась в руки правильная книжка по mySQL и учить приходилось методом проб и ошибок. Множество статей в интернете как-то не сразу донесли до меня замечательный mySQL запрос — JOIN.
В этой публикации я расскажу о всех возможных вариантах работы с JOIN и более того, представлю принцип работы каждой команды — визуально.
Отдельно стоит отметить пункты 5,6 и 7. На самом деле эти запросы не соединяют две таблицы, а наоборот исключают из одной таблицы столбцы присутствующие в другой. На деле это может оказать очень полезным.
Inner JOIN
Один из самых распространенных запросов, встречается предельно часто. Этот запрос вернет все записи из левой таблицы (таб. А) и записи из (таб. В), но при этом возвращены будут только совпадающие столбцы.
Пример запроса:
Просмотр кода SQL
| SELECT < select_list> FROM Table_A A INNER JOIN Table_B B ON A. Key = B. Key |
Left JOIN
Данный запрос вернет все столбцы из левой таблицы (таб. А), а также все столбцы из правой таблицы (таб. В) но только которые совпадают со столбцами из левой таблицы.
Пример запроса:
Просмотр кода SQL
| SELECT < select_list> FROM Table_A A LEFT JOIN Table_B B ON A. Key = B. Key |
Right JOIN
Аналогичен предыдущему запросу, но уже вернет все столбцы из правой таблицы (таб. В), а также все столбцы из левой таблицы (таб. А) которые совпадают со столбцами из правой таблицы.
Пример запроса:
Просмотр кода SQL
| SELECT < select_list> FROM Table_A A RIGHT JOIN Table_B B ON A. Key = B. Key |
Outer JOIN
Часто данный запрос записывают как FULL OUTER JOIN или FULL JOIN, все вариации выполняют одно действие, а именно возвращают все столбцы из обоих таблиц, при этом совпадающие столбцы будут перекрыты столбцами из левой таблицы.
Пример запроса:
Просмотр кода SQL
| SELECT < select_list> FROM Table_A A FULL OUTER JOIN Table_B B ON A. Key = B. Key |
Left Excluding JOIN
Этот запрос вернет все столбцы из левой таблицы (таб. А), которые не совпадают со столбцами из правой таблицы (таб. В).
Пример запроса:
Просмотр кода SQL
Поводом для написания данной статьи послужили некоторые дебаты в одной из групп linkedin, связанной с MySQL, а также общение с коллегами и хабролюдьми:-)
В данной статье хотел написать что такое вообще JOINы в MySQL и как можно оптимизировать запросы с ними.
Что такое JOINы в MySQLВ MySQL термин JOIN используется гораздо шире, чем можно было бы предположить. Здесь JOINом может называться не только запрос объединяющий результаты из нескольких таблиц, но и запрос к одной таблице, например, SELECT по одной таблице - это тоже джоин.
Все потому, что алгоритм выполнения джоинов в MySQL реализован с использованием вложенных циклов. Т.е. каждый последующий JOIN это дополнительный вложенный цикл. Чтобы выполнить запрос и вернуть все записи удовлетворяющие условию MySQL выполняет цикл и пробегает по записям первой таблицы параллельно проверяя соответствия условиям описанных в теле запроса, когда находятся записи, удовлетворяющие условиям - во вложенном цикле по второй таблице ищутся записи соответствующие первым и удовлетворяющие условиям проверки и т.д.
Прмер обычного запроса с INNER JOIN
SELECTГде Р - условия склейки таблиц и фильтры в WHERE условии.
Можно представить такой псевдокод выполнения такого запроса.
FOR each row t1 in Table1 {Где конструкция t1||t2||t3 означает конкатенацию столбцов из разных таблиц.
Если в запросе встречаются OUTER JOINs, например, LEFT OUTER JOIN
SELECTТо алгоритм выполнения этого запроса MySQL будет выглядеть как-то так
FOR each row t1 in T1 {Итак, как мы видим, JOINы это просто группа вложенных циклов. Так почему же в MySQL и UNION и SELECT и запросы с SUBQUERY тоже джоины?
MySQL оптимизатор старается приводить запросы к тому виду к которому ему удобней обрабатывать и выполнять запросы по стандартной схеме.
С SELECT все понятно - просто цикл без вложенных циклов. Все UNION выполняются как отдельные запросы и результаты складываются во временную таблицу, и потом MySQL работает уже с этой таблицей, т.е. проходясь циклом по записям в ней. С Subquery та же история.
Приводя все к одному шаблону, например, МySQL переписывает все RIGHT JOIN запросы на LEFT JOIN эквиваленты.
Но стратегия выполнения запросов через вложенные циклы накладывает некоторые ограничения, например, в связи с такой схемой MySQL не поддерживает выполнение FULL OUTER JOIN запросов.
Но результат такого запроса можно получить с помощью UNION двух запросов на LEFT JOIN и на RIGHT JOIN
Пример самого запроса можно посмотреть по ссылке на вики.
В отличии от других СУРБД MySQL не генерирует байткод для выполнения запроса, вместо этого MySQL генерирует список инструкций в древовидной форме, которых придерживается engine выполнения запроса выполняя запрос.
Это дерево имеет следующий вид и имеет название «left-deep tree»
В отличии от сбалансированных деревьев (Bushy plan), которые применяются в других СУБД (например Oracle)
Теперь перейдем к самому интересному - к оптимизации джоинов.
MySQL оптимизатор, а именно та его часть, которая отвечает за оптимизацию JOIN-ов выбирает порядок в котором будет производиться склейка имеющихся таблиц, т.к. можно получить один и тот же результат (датасет) при различном порядке таблиц в склейке. MySQL оптимизатор оценивает стоимость различных планов и выбирает с наименьшей стоимостью. Единицей оценки является операция единичного чтения страницы данных размером в 4 килобайта из произвольного места на диске.
Для выбранного плана можно узнать стоимость путем выполнения команды
SHOW SESSION STATUS LIKE "Last_query_cost";
Оценка основана на статистике: количество страниц памяти, занимаемое таблицей и/или индексами для этой таблицы, cardinality (число уникальных значений) индексов, длинна записей и индексов, их распределение и т.д. Во время своей оценки оптимизатор не рассчитывает на то, что какие-то части попадут в кеш, оптимизатор предполагает, что каждая операция чтения это обращение к диску.
Иногда анализатор-оптимизатор не может проанализировать все возможные планы выполнения и выбирает неправильный. Например, если у нас INNER JOIN по 3м таблицам, то возможных вариантов у анализатора - 3! = 6, а если у нас склейка по 10 таблицам, то тут возможных вариантов уже 10! = 3628800… MySQL не может проанализировать столько вариантов, поэтому в таком случае он использует алгоритм "жадного " поиска.
Но не стоит применять этот хак ко всем запросам, расчитывая произвести оптимизацию на спичках и сэкономить время на составление плана выполнения запроса оптимизатором и добавлять STRAIGH_JOIN ко всем запросам с джоинами , т.к. данные меняются и склейка, которая оптимальна сейчас может перестать быть оптимальной со временем, и тогда запросы начнуть очень сильно лагать.
Также, как уже говорилось выше, результаты джоинов помещаются во временные таблицы, поэтому зачастую уместно применять «derived table» в котором мы накладываем все необходимые нам условия на выборку, а также указываем LIMIT и порядок сортировки. В данном случае мы избавимся от избыточности данных во временной таблице, а также проведем сортировку на раннем этапе (по результату одной выборки, а не финальной склейки, что уменьшит размеры записей которые будут сортироваться).
Стандартный пример подхода описанного выше. Простая выборка для отношения много к многим: новости и теги к ним.
SELECTНу и на последок небольшая задачка, которую я иногда задаю на собеседованиях:-)
Есть новостной блоггерный сайт. Есть такие сущности как новости и комментарии к ним.
Задача - нужно написать запрос, который выводит список из 10 новостей определенного типа (задается пользователем) отсортированные по времени издания в хронологическом порядке, а также к каждой из этих новостей показать не более 10 последних коментариев, т.е. если коментариев больше - показываем только последние 10.
Все нужно сделать одним запросом. Да, это, может, и не самый лучший способ, и вы вольны предложить другое решение:-)
Теги: Добавить метки
