Оптимизация запросов MySQL. Меньшие столбцы – быстрее

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

1. Оптимизация таблиц . Необходима, когда было произведено много изменений в таблице: либо удалена большая часть данных, либо много изменений со строками переменной длины - text, varchar, blob. Дело в том, что удалённые записи продолжают поддерживаться в индексном файле, и при последующей вставке новых записей используются позиции старых записей. Чтобы дефрагментировать файл с данными, используюется команда OPTIMIZE.

   OPTIMIZE TABLE `table1`, `table2`…

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

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

ALTER TABLE `table1` ORDER BY `id`

Тип данных . Лучше не индексировать поля, имеющие строковый тип, особенно поля типа TEXT. Для таблиц, данные которых часто изменяются, желательно избегать использования полей типа VARCHAR и BLOB, так как данный тип создаёт динамическую длину строки, тем самым увеличивая время доступа к данным. При этом советуют использовать поле VARCHAR вместо TEXT, так как с ним работа происходит быстрее.

NOT NULL и поле по умолчанию . Лучше всего помечать поля как NOT NULL, так как они немного экономят место и исключают лишние проверки. При этом стоит задавать значение полей по умолчанию и новые данные вставлять только в том случае, если они от него отличаются. Это ускорит добавление данных и снизит время на анализ таблиц. И стоит помнить, что типы полей BLOB и TEXT не могут содержать значения по умолчанию.

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

Разделение данных. Длинные не ключевые поля советуют выделить в отдельную таблицу в том случае, если по исходной таблице происходит постоянная выборка данных и которая часто изменяется. Данный метод позволит сократить размер изменяемой части таблицы, что приведёт к сокращению поиска информации.
Особенно это актуально в тех случаях, когда часть информации в таблице предназначена только для чтения, а другая часть - не только для чтения, но и для модификации (не забываем, что при записи информации блокируется вся таблица). Яркий пример - счётчик посещений.
Есть таблица (имя first) с полями id, content, shows. Первое ключевое с auto_increment, второе - текстовое, а третье числовое - считает количество показов. Каждый раз загружая страницу, к последнему полю прибавляется +1. Отделим последнее поле во вторую таблицу. Итак, первая таблица (first) будет с полями id, content, а вторая (second) с полями shows и first_id. Первое поле понятно, второе думаю тоже - отсыл к ключевому полю id из первой таблицы.
Теперь постоянные обновления будут происходить во второй таблице. При этом изменять количество посещений лучше не программно, а через запрос:

А выборка будет происходить усложнённым запросом, но одним, двух не нужно:

SELECT first.id, first.content, second.first_id, second.shows FROM second INNER JOIN first ON (first.id = second.first_id)

Стоит помнить, что всё это не актуально для сайтов с малой посещаемостью и малым количеством информации.

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

Требовать меньше данных . При возможности избегать запросов типа:

SELECT * FROM `table1`

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

SELECT id, name FROM table1 ORDER BY id LIMIT 25

Тут же сделаю добавление о желательности использования LIMIT. Данная команда ограничивает количество строк, возвращаемых запросом. То есть запрос становится "легче" и производительнее.
Если стоит LIMIT 10, то после получения десяти строк запрос прерывается.
Если в запросе применяется сортировка ORDER BY, то она происходит не по всей таблице, а только по выборке.
Если использовать LIMIT совместно с DISTINCT, то запрос прервётся после того, как будет найдено указанное количество уникальных строк.
Если использовать LIMIT 0, то возвращено будет пустое значение (иногда нужно для определения типа поля или просто проверки работы запроса).

Ограничить использование DISTINCT . Эта команда исключает повторяющиеся строки в результате. Команда требует повышенного времени обработки. Лучше всего комбинировать с LIMIT.
Есть маленькая хитрость. Если необходимо просмотреть две таблицы на тему соответствия, то приведённая команда остановится сразу же, как только будет найдено первое соответствие.

Ограничить использование SELECT для постоянно изменяющихся таблиц .

2. Не забывайте про временные таблицы типа HEAP . Несмотря на то, что таблица имеет ограничения, в ней удобно хранить промежуточные данные, особенно когда требуется сделать ещё одну выборку из таблицы без повторного обращения. Дело в том, что эта таблица хранится в памяти и поэтому доступ к ней очень быстрый.
3. Поиск по шаблону . Зависит от размера поля и если уменьшить размер с 400 байтов до 300, то время поиска сократиться на 25%.

• Разместил Николай Коротков
• Дата: 8 декабря 2012 в 14:04

Для чего все это нужно? На что влияет? Как воплотить в реальность? На все эти вопросы я постараюсь дать четкий ответ в этом посте!

А теперь небольшая предыстория. В общем, недавно получил письмо на свой e-mail адрес, следующего содержания:

В течение последних 3 дней средний уровень нагрузки, создаваемый Вашим аккаунтом ******* , составил 119% от допустимого уровня Вашего тарифного плана. Мы рекомендуем Вам перейти на тарифы VPS. Обращаем Ваше внимание, что в случае регулярного превышения лимитов, мы оставляем за собой право заблокировать Ваш аккаунт согласно пункту Договора...

Оба на, приплыли — подумал я в тот момент! Согласитесь, не очень приятно получать такие письма. А так как с подобного рода проблемой я столкнулся впервые, представляете, в каком я был недоумении? Моему возмущению не было предела! Какой нафиг VPS? Я можно сказать только обжился на одном тарифе, а мне тут предлагают перейти на виртуальный хостинг, который в три раза дороже. Ну нет уж ребята, — думаю я, — еще рановато.

Пишу в обратку письмо моему хостеру, с просьбой пояснить мне, с какого это перепуга у меня зашкаливает нагрузка? Ведь моему блогу всего-то два с небольшим месяца от роду. Да и посещаемость не велика. В общем, пишу, что категорически против переходить на VPS, считаю, что это не целесообразно на столь раннем этапе развития ресурса и прошу указать мне на мои ошибки, что с ними делать и как в дальнейшем их контролировать!

В ответ получаю следующее:

Уважаемый абонент, мы вас не собираемся отключать именно сейчас, это банальное предупреждение, но мол надо с этим, что-то делать. Проблема превышения нагрузки не зависит напрямую от посещаемости, а в большей степени зависит от не правильной оптимизации вашего ресурса. Для отслеживания нагрузки мы вам вывели в панели управления счетчик, который обновляется каждые 10 минут:

Ну спасибо за разъяснения, — думаю про себя. Пойду изучать проблему. Набрав в интернете запрос «как снизить нагрузку на хостинг» понял, что я не один такой, а на самом деле проблема довольно актуальная. И рано или поздно коснется многих. Ознакомившись более детально с проблемой, понял, что у меня есть два выхода из данной ситуации:

1. Обратиться за помощью к профессионалам (фрилансерам), заплатив им определенную сумму денег, что всегда успеется.
2. Постараться устранить проблему самому.

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

Разница, на лицо! Сейчас я вам покажу и расскажу, что я для этого сделал:

— оптимизировал базу данных mysql, что существенно отразилось на снижении нагрузки на хостинг и ускорении wordpress;
— избавился от порядка 8 ненужных плагинов.
— ускорил wordpress, отредактировав несколько файлов темы своего блога.

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

В общем, материал, который вы почерпнете из этих трех постов, будет ну просто обалденным. Не пропустите, !

Оптимизация базы данных

Прежде чем вы начнете производить различные действия с базой данных, обязательно делайте резервную копию . Чтобы в случае возникновения проблем можно было все быстренько восстановить. База данных содержит всю историю вашего ресурса, в ней хранятся все записи, присутствующие на вашем блоге! А вообще, советую вам взять за правило сохранять базу данных каждый день! Это у вас займет буквально 1 минуту, но зато вы будете всегда спать спокойно. Сами понимаете может случится всякое.

1. Делаем резервную копию базы данных

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

В итоге вы должны оказаться вот на такой странице, phpMyAdmin:

Заходите в базу данных, кликнув по ее названию. Перед вами откроется таблица базы данных (кликните для увеличения):

Нажимаете «Экспорт» и «ОК». Сохраняете на своем ПК. Все, база данных сохранена, теперь можем приступать к ее оптимизации. Обратите внимание, если на вашем хостинге присутствует поле «Сохранить как файл» не забудьте напротив него поставить галочку! А также запомните, сколько весит в данный момент ваша база данных, а потом посмотрите сколько она будет весить после оптимизации.

У меня она весила до оптимизации 26 Mb — это УЖАС, а что сейчас? А сейчас она весит всего 2 Mb! Представляете, сколько всякого ненужного хлама она содержала в себе? Представляете, какую нагрузку она создавала на сервере? После оптимизации базы данных, мой блог стал летать, как реактивный самолет! В общем, после того как вы проделаете все ниже описанные действия, вы почувствуете существенную разницу!

2. Отключаем ревизии постов и устанавливаем минимальный срок хранения удаленных файлов в корзине

Что такое ревизия постов? Когда вы пишите пост в блог, wordpress автоматически, через определенный промежуток времени, сохраняет резервную копию каждого поста в базе данных, в общем, делает авто сохранение. А теперь представьте когда вы напишите 50 постов на блоге? Сколько копий постов у вас будет сохранено? Это ЖЕСТЬ! Пока вы пишите пост, у вас уже как минимум проходит 10 авто сохранений!

Плюс ко всему этому, если вы удаляете файлы, они у вас скапливаются в корзине, что также нагружает базу данных. Конечно, хорошо если вы сразу удалите файл и из корзины, но частенько случается, что многие про это забываю, а некоторые просто забивают! А это ой как не хорошо... База все растет, нагрузка на сервер все больше и больше, блог грузится все медленнее и медленнее... Вы задумывались, к каким последствиям это может привести?

Вот основная часть последствий, но далеко не всех: снижение , частые отказы, ухудшение , понижение позиций в выдаче поисковиков... А дальше, автор в подает в отчаяние от не оправданных ожиданий. Желание вести блог со временем пропадает и все! КРАХ!

Все это я к чему говорю? За базой данных постоянно нужно следить и содержать ее в надлежащем состоянии. Поймите, база данных — это как сердце блога. При постоянной нагрузке на сердце не нужным хламом, со временем оно не выдержит и ОСТАНОВИТСЯ! Я думаю, вы меня поняли? Поэтому хватит ужастиков и переходим к оптимизации базы данных.

Итак, открываем файл wp-config.php, он находится в корне вашего блога, т.е. ваш хостинг/httpdocs или public_html (в зависимости от хостинга)/wp-config.php. И вставляем в него две строчки:

Строка №1 отключает ревизию постов, строка №2 означает, сколько дней будут храниться удаленные файлы в вашей корзине. Как видите, я поставил «1», можно конечно поставить и «0», но если вдруг по неосторожности у вас дрогнет рука и вы нажмете на ссылку «удалить», все — КАПЕЦ!

А после просиживания за компом 5-8 часов, поверьте мне, это возможно! Так что я предпочитаю оставить циферку «1». Конечно, после удаления файла лучше сразу же почистить корзину вручную, но если даже вы забудете это сделать, спустя сутки файл из корзины автоматически удалится! Вот как это выглядит у меня:

3. Удаляем ревизии постов

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

Переходим снова в базу данных MySQL, как описано в первом пункте. Заходим во вкладку SQL, вставляем в поле скопированную строчку и нажимаем «ОК»:

База данных спросит:

Отвечаем «ОК» и смотрим, сколько не нужных ревизий постов содержала в себе ваша база данных, и сколько времени уходило на то, чтобы запрос обработать. А каждая частичка времени дает свою нагрузку:

Я делал чистку 3 дня назад, поэтому у меня она еще не обросла ревизиями. Когда я первый раз почистил базу, у меня было удалено аж 1800 с чем-то строк! Представляете, сколько копий ненужных постов в ней хранилось? Идем дальше.

4. Оптимизируем записи в wp-post

Папка wp-post содержит все записи блога. Точно так же как и в предыдущем пункте, копируем строку:

И вставляем в поле SQL запроса. Нажимаем «ОК», смотрим:

Все, запрос выполнен!

5. Чистим wp-postmeta

Что именно будем чистить? Папка wp-postmeta содержит в себе:

— время последнего редактирования какого-либо из постов. Значения никакого не имеет, а нагрузку на сервер, какую никакую, а дает;
— содержание предыдущего (человека понятного урла). Если вы когда-нибудь меняли постоянную ссылку в любом посте. То при смене ее, она не удаляется, а оседает в папке wp-postmeta и нагружает вашу базу.

Делаем все тоже самое, копируем вот этот код:

Вставляем его в поле запроса SQL, и жмем «ОК». Смотрим на результат:

6. Удаляем спам-комментарии

Делается аналогично, копируем код:

Вставляем в поле SQL запроса, жмем «ОК», смотрим результат:

Как вы видите «0». После выполнения этого запроса, вы забудете про спам комментарии!

7. Удаляем пингбеки

Пингбеки — это уведомления о том, что на ваш пост или страницу кто-то ссылается. Нам это не нужно, лишняя нагрузка! Удаляем!

8. Отключаем пингбеки

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

Ну как вам такая чистка? Понравилась? А теперь посмотрите, сколько стала весить ваша база данных после ее оптимизации? Заметно уменьшился размер? А я вам говорил! Посмотрите, как стал грузиться ваш блог! Он должен летать! Но и это еще не все на сегодня. Сейчас мы рассмотрим еще один последний пункт, который также существенно улучшит оптимизацию.

9. Устанавливаем плагин Optimize DB

Об этом плагине я уже вкратце упоминал . Ну давайте более подробно рассмотрим, как им пользоваться. Данный плагин, как вы уже догадались, способствует оптимизации базы данных! Скачайте архив с плагином себе на ПК, вот и активируйте его:

Все, ваша база данных оптимизирована дополнительно при помощи плагина:

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

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

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

И на последок порция приколов:

Ну как вам статья? Я уверен, что вы останетесь довольны после ее прочтения и проделанных рекомендаций со своим ресурсом! Жду ваших комментариев!

Понравилась статья? Поделись с друзьями!

Каждому комментатору книга в подарок!

Книга включает в себя подробное описание самых эффективных методов продвижения вашего ресурса!

60 комментариев

1. Александр 8 декабря 2012 15:18

   А я знаю почему у Тебя нагрузка так выросла. Просто я тут у Тебя прижился, и постоянно что то изучаю. А что делать если инфа здесь классная. А если серьезно, то все вышеперечисленные советы рекомендую сделать всем блоговодам в первую очередь. Я это давно сделал, поэтому сплю спокойно. И еще, плагин Optimize DB, это вообще обязательный атрибут любого Блога. Спасибо Коля, как всегда, все полезно и актуально. А вот следующий пост вообще жду с нетерпением. Так что давай, пиши

2. 9 декабря 2012 16:19

   Я в базе данных ковыряться побаиваюсь, но после установки и чистки плагином WP-Cleanup она у меня уменьшилась с почти 50 до 7Mb. Блог действительно стал грузиться намного быстрее.

3. 9 декабря 2012 20:39

   Строго говоря, спрашивает при операциях с базой данных не сама БД (СУБД вообще все действия одинаковы, ничего не спрашивает), а клиент, phpMySql.

   Касательно пингбэков, «Из прошлого пункта мы выяснили, что пингбеки не несут никакой пользы для нашего ресурса, а только его засоряют.» — строго говоря, ничего не выяснили.

   Вы просто сказали, не аргументируя, что они не нужны, вот и всё. На самом деле, польза от них вполне может быть, просто употреблять этот инструмент нужно по назначению. Например, ключевое слово «семантическая сеть» вам говорит что-нибудь?

4. 10 декабря 2012 08:36
5. Юрий 16 декабря 2012 23:49

   Привет, дружище!

   Твой пост и в самом деле классный. В Интернете столько много бредни написано, что информацию приходится искать по крупицам. А здесь я зашел, и на тебе, все доходчиво и понятно. У меня как раз началась проблема с нагрузкой на сервер. Еще советую установить плагин WP Super Cache. Только его нужно грамотно настроить. Классный плагин! Может у тебя в остальных постах о нем что-то и сказано, но я еще не читал. Спешу перейти ко второй части оптимизации. Удачи тебе и твоему блогу

6. 25 декабря 2012 11:40
7. 28 января 2013 11:24

   Добрый день! Очень интересно, а как быть мне с блогом на Blogger? Все плагины для WP не годятся для Блогспот, нужно искать методы оптимизации самостоятельно в инете.

   С уважением, Вадим.

8. Антон 2 апреля 2013 20:34

   Спасибо, пост действительно добротный. У меня, кстати, после проделывания пункта №3 — «Удалено 4145 строк. (Запрос занял 7.0269 сек.)»

9. 14 июля 2013 19:04

   Интересно, а как-то можно почистить базу от старых плагинов? наверняка там от них тоже следы какие-то остались?

10. 14 июля 2013 19:06

    Вдогонку: а еще очень похоже на ваш текст вот тут dayafternight.ru/wordpress/baza-dannih-mysql-optimizacia

11. 12 сентября 2013 12:57

    Спасибо Николай, нужная вещь.

    Все доступно и понятно написано.

    А статья про коды уже вышла?

12. 12 сентября 2013 13:05

    Николай забыла спросить, подскажите пожалуйста. Когда делала оптимизацию обнаружила у себя в PhpMyadmin новую базу данных information_schema

    Подскажите откуда она могла появиться?

    в последнее время только код яндекс-метрики вставляла.

    Наталья Гегер

    Не обращайте на это внимание... На большинстве современных серверов она есть! Связано это с выходом MySQL версии 5.0 и выше...

    INFORMATION_SCHEMA — это виртуальная база, которая формируется во время запуска сервера и содержит в себе метаданные всех баз данных, т.е. информацию о структуре баз данных. Доступна она только для чтения.

13. 27 октября 2013 01:06

    ох, почистил базу по вашему методу + от себя ручками, результат на лицо. Раньше база весила 20мб, сейчас 5мб

14. 29 октября 2013 23:34

    Спасибо огромное за статью. Сегодня тоже получил втык от хостера. В результате действий, база из 25Мб стала 5,2. Есть 2 вопроса, эти все манипуляции надо делать периодически? И второй вопрос, установил плагин, нажимаю оптимизировать, в результате напротив каждой строки пишется,

    note: Table does not support optimize, doing recreate + analyze instead

    Не похоже, что всё хорошо?!

    Пожалуйста! Да, я делаю все эти манипуляции, примерно один раз в месяц. А вот насчет плагина пока не могу ничего сказать, видимо вы что-то сделали не правильно. Попробуйте поискать информацию в интернет по этому поводу. Но есть и приятные события. Вы оставили на моем блоге 2100-й комментарий и за это вам полагается приз в размере 100 рублей:

    

    Присылайте номер своего wmr-кошелька и я перечислю вам деньги.

15. 30 октября 2013 13:27

    Спасибо, приз получен. Как я оказался на Вашем сайте?! Вчера очередной раз сайт перестал работать, а на экране писалось «Ошибка соединения с базой данных». Написал хостеру, там подтвердили что большая нагрузка на MySQL и что-то с этим делайте, а пока перевели на тариф выше. Сразу же начал искать, что же делать и нашёл Вашу статью, которая уменьшила базу в 5 раз. Плагин который сначала не хотел работать, всё таки заработал, но основная проблема, убрать лишние запросы, так и не была решена. У меня уже стоит плагин WP Super Cache, но он кеширует страницы, а не запросы к БД. И вот я до четырёх часов утра искал плагин, который мне сможет помочь с запросами и нашёл. WP File Cache кеширует запросы, количество запросов и МБ памяти, уменьшается в разы. На страницах где до этого было 40 запросов и 35МБ, теперь запросов 9 и 12МБ. Единственное, скорость загрузки вроде чуток увеличилось, но незначительно, учитывая что скорость загрузки страниц у меня, в среднем 0,15-0,5 секунды. Может кому то данная информация будет интересна.

16. 7 декабря 2013 15:41

    выше указанные действия могут повлиять на работу плагина nrelate-flyout ?

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

1. Оптимизируйте запросы для кэша запросов

У большинства MySQL серверов включено кэширование запросов. Один из наилучших способов улучшения производительности — просто предоставить кэширование самой базе данных. Когда какой-либо запрос повторяется много раз, его результат берется из кэша, что гораздо быстрее прямого обращения к базе данных. Основная проблема в том, что многие просто используют запросы, которые не могут быть закэшированны:

Причина в том, что в первом запросе используется функция CURDATE(). Это относиться ко всем функциям, подобным NOW(), RAND() и другим, результат которых недетерминирован. Если результат функции может измениться, то MySQL не кэширует такой запрос. В данном примере это можно предотвратить вычислением даты до выполнения запроса.

2. Используйте EXPLAIN для ваших запросов SELECT

13. Небуферизованные запросы

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

«mysql_unbuffered_query() отправляет SQL-запрос в MySQL, не извлекая и не автоматически буферизуя результирующие ряды, как это делает mysql_query() . С одной стороны, это сохраняет значительное количество памяти для SQL-запросов, дающих большие результирующие наборы. С другой стороны, вы можете начать работу с результирующим набором срезу после получения первого ряда: вам не нужно ожидать выполнения полного SQL-запроса»

Однако есть определенные ограничения. Вам придется считывать все записи или вызывать mysql_free_result() прежде, чем вы сможете выполнить другой запрос. Так же вы не можете использовать mysql_num_rows() или mysql_data_seek() для результата функции.

14. Храните IP в UNSIGNED INT

Многие программисты хранят IP адреса в поле типа VARCHAR(15), не зная что можно хранить его в целочисленном виде. INT занимает 4 байта и имеет фиксированный размер поля.
Убедитесь, что используете UNSIGNED INT, т.к. IP можно записать как 32 битное беззнаковое число.
Используйте в запросе INET_ATON() для конвертирования IP адреса в число, и INET_NTOA() для обратного преобразования. Такие же, такие функции есть и в PHP — ip2long() и long2ip() (в php эти функции могут вернуть и отрицательные значения. замечание от хабраюзера The_Lion).

15. Таблицы фиксированного размера (статичные) — быстрее

Если каждая колонка в таблице имеет фиксированный размер, то такая таблица называется «статичной» или «фиксированного размера». Пример колонок не фиксированной длины: VARCHAR, TEXT, BLOB. Если включить в таблицу такое поле, она перестанет быть фиксированной и будет обрабатываться MySQL по-другому.
Использование таких таблицы увеличит эффективность, т.к. MySQL может просматривать записи в них быстрее. Когда надо выбрать нужную строку таблицы, MySQL может очень быстро вычислить ее позицию. Если размер записи не фиксирован, ее поиск происходит по индексу.
Так же эти таблицы проще кэшировать и восстанавливать после падения базы. Например, если перевести VARCHAR(20) в CHAR(20), запись будет занимать 20 байтов, вне зависимости от ее реального содержания.
Используя метод «вертикального разделения», вы можете вынести столбцы с переменной длиной строки в отдельную таблицу.

16. Вертикальное разделение

Вертикальное разделение — означает разделение таблицы по столбцам для увеличения производительности.
Пример 1. Если в таблице пользователей хранятся адреса, то не факт что они будут нужны вам очень часто. Вы можете разбить таблицу и хранить адреса в отдельной таблице. Таким образом, таблица пользователей сократиться в размере. Производительность возрастет.
Пример 2. У вас есть поле «last_login» в таблице. Оно обновляется при каждом входе пользователя на сайт. Но все изменения в таблице очищают ее кэш. Храня это поле в другой таблице, вы сведете изменения в таблице пользователей к минимуму.
Но если вы будете постоянно использовать объединение этих таблиц, это приведет к ухудшению производительности.

17. Разделяйте большие запросы DELETE и INSERT

Если вам необходимо сделать большой запрос на удаление или вставку данных, надо быть осторожным, чтобы не нарушить работу приложения. Выполнение большого запроса может заблокировать таблицу и привести к неправильной работе всего приложения.
Apache может выполнять несколько параллельных процессов одновременно. Поэтому он работает более эффективно, если скрипты выполняются как можно быстрее.
Если вы блокируете таблицы на долгий срок (например, на 30 секунд или дольше), то при большой посещаемости сайта, может возникнуть большая очередь процессов и запросов, что может привести к медленной работе сайта или даже к падению сервера.
Если у вас есть такие запросы, используйте LIMIT, чтобы выполнять их небольшими сериями.

18. Маленькие столбцы быстрее

Для базы данных работа с жестким диском, возможно, является самым слабым местом. Маленькие и компактные записи обычно лучше с точки зрения производительности, т.к. уменьшают работу с диском.
В документации к MySQL есть список требований к хранилищам данных для всех типов данных.
Если ваша таблица будет хранить мало строк, то не имеет смысла делать основной ключ типом INT, возможно лучше будет сделать его MEDIUMINT, SMALLINT или даже TINYINT. Если вам не нужно хранить время, используйте DATE вместо DATETIME.
Однако будьте осторожны, что бы не вышло как с Slashdot .

19. Выбирайте правильный тип таблицы

20. Используте ORM

21. Будьте осторожны с постоянными соединениями

Постоянные соединения предназначены для уменьшения расходов на установление связи с MySQL. Когда соединение создается, оно остается открытым после завершения работы скрипта. В следующий раз, этот скрипт воспользуется этим же соединением.
mysql_pconnect() в PHP
Но это звучит хорошо только в теории. Из моего личного опыта (и опыта других), использование этой возможности не оправдывается. У вас будут серьезные проблемы с ограничением по числу подключений, памятью и так далее.
Apache создает много параллельных потоков. Это основная причина, почему постоянные соединения не работаю так хорошо, как бы хотелось. Перед использованием mysql_pconnect() посоветуйтесь с вашим сисадмином.

Как оптимизировать MySQL запросы?

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

Почему MySQL?

Сегодня идет много разговоров о Dig Data и других новых технологиях. NoSQL и облачные решения это супер, но много популярного софта (такого как WordPress, phpBB, Drupal) до сих пор работает на MySQL. Миграция на новейшие решения может вылиться не только в изменении конфигурации на серверах. К тому же, эффективность MySQL до сих пор на уровне, особенно версия Percona.

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

Хорошее понимание SQL это важнейший инструмент для веб-разработчика, именно он позволит эффективно оптимизировать и использовать реляционные базы данных. В этой статье мы сфокусируемся на популярной открытой базе данных, часто используется в связке с PHP, и это MySQL.

Для кого эта статья?

Для веб-разработчиков, архитекторов и разработчиков баз данных и системных администраторов, хорошо знакомых с MySQL. Если раньше вы не использовали MySQL, эта статья может не принести вам пользы, но я все равно буду стараться быть как можно более информативным и полезным даже для новичков в MySQL.

Сначала бэкап

Я рекомендую делать следующие шаги на базе MySQL, с которой вы работаете, однако не забудьте сделать резервную копию. Если у вас нет базы данных, с которой вы можете работать, я буду предоставлять примеры для создания собственной базы данных, где это будет уместно.

Делать бэкапы MySQL просто, используя утилиту mysqldump:

$ mysqldump myTab > myTab-backup.sql Вы можете узнать больше о mysqldump .

Что делает запрос медленным?

Вот общий список факторов, влияющих на скорость выполнения запросов и нагрузки сервера:

• индексы таблиц;
• условие WHERE(и использования внутренних функций MySQL, например, таких как IF или DATE);
• сортировка по ORDER BY;
• частое повторение одинаковых запросов;
• тип механизма хранения данных (InnoDB, MyISAM, Memory, Blackhole);
• не использование версии Percona;
• конфигурации сервера (my.cnf / my.ini);
• большие выдачи данных (более 1000 строк);
• нестойкое соединение;
• распределенная или кластерная конфигурация;
• слабое проектирование таблиц.

Что такое индексы?

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

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

Нестойкое соединение?

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

Уменьшаем частое повторение одинаковых запросов

Наиболее быстрый и эффективный способ, который я нашел для этого - это создание хранилища запросов и результатов их выполнения с помощью Memcached или Redis. С Memcache вы можете легко положить в кэш результат выполнения вашего запроса, например, следующим образом:

connect("localhost",11211); $cacheResult = $cache->get("key-name"); if($cacheResult){ //не нуждаемся в запросе $result = $cacheResult; } else { //запускаем ваш запрос $mysqli = mysqli("p:localhost","username","password","table"); //добавляйте p: для договременного хранения $sql = "SELECT * FROM posts LEFT JOIN userInfo using (UID) WHERE posts.post_type = "post" || posts.post_type = "article" ORDER BY column LIMIT 50"; $result = $mysqli->query($sql); $memc->set("key-name", $result->fetch_array(), MEMCACHE_COMPRESSED,86400); } //Пароль $cacheResult в шаблон $template->assign("posts", $cacheResult); ?> Теперь тяжелый запрос, использующий LEFT JOIN, будет выполняться только раз за каждые 86 400 секунд (то есть раз в сутки), что значительно уменьшит нагрузку MySQL сервера, оставив ресурсы для других соединений.

Примечание: Допишите p: в начале аргумента хоста MySQLi для создания постоянного соединения.

Распределенная или кластерная конфигурация

Когда данных становится все больше, и скорость вашего сервиса идет под уклон, паника может овладеть вами. Быстрым решением может стать распределения ресурсов (sharding). Однако я не рекомендую делать это, если вы не обладаете хорошим опытом, поскольку распределение по своей сути делает структуры данных сложнейшими.

Слабое проектирование таблиц

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

Обеспечение правильного проектирования для нужного использования является первостепенным в создании вашего приложения. Храните различные данные в различных таблицах (например, категории и статьи) и убедитесь, что отношения к другу (many to one) и один ко многим (one to many) могут быть легко связаны с идентификаторами (ID). Использование FOREIGN KEY в MySQL идеально подходит для хранения каскадных данных в таблицах.

При создании таблицы помните следующее:

• Создавайте эффективные таблицы для решения ваших задач, а не заполняйте таблицы лишними данными и связями.
• Не ожидайте от MySQL выполнения вашей бизнес логики или програмности - данные должны быть готовы к вставке строки вашей скриптовым языком. Например, если вам нужно отсортировать список в случайном порядке, сделайте это в массиве PHP, не используя ORDER BY из арсенала MySQL.
• Используйте индексные типы UNIQUE для уникальных наборов данных и применяйте ON DUPLICATE KEY UPDATE, чтобы хранить дату обновленной, например, для того, чтобы знать, когда строка была в последний раз изменена.
• Используйте тип данных INT для сохранения целых чисел. Если вы не укажете размер типа данных, MySQL сделает это за вас.

Для эффективной оптимизации мы должны применять три подхода к вашему приложению:

1. Анализ (логирование медленных запросов, изучение системы, анализ запросов и проектирование базы данных)
2. Требования к исполнению (сколько пользователей)
3. Ограничения технологий (скорость железа, неправильное использование MySQL)

Колонки, вы видите, сохраняют важную информацию о запросе. Колонки, на которые вы должны обратить наибольшее внимание это possible_keys и Extra.

Колонка possible_keys покажет индексы, в которые MySQL имел доступ, чтобы выполнить запрос. Иногда нужно назначить индексы, чтобы запрос выполнялся быстрее. Колонка Extra покажет, были ли использованы дополнительные WHEREили ORDER BY. Наиболее важно обратить внимание, есть ли Using Filesort в выводе.

Что делает Using Filesort, указано в справке MySQL:

MySQL должен выполнить дополнительный проход, чтобы понять, как вернуть строки в отсортированном виде. Это сортировка происходит проходом по всем строкам в соответствии с типом объединения и сохраняет ключ к сортировке и указатель на строку для всех строк, совпадающих с условным выражением WHERE. Ключи сортируются и строки возвращаются в нужном порядке.

Чтобы избежать проблемы с Using Filesort мы должны увериться, что MySQL использует INDEX. Сейчас указано несколько ключей в possible_keys, из которых можно выбирать, но MySQL может выбрать только один индекс для финального запроса. Также индексы могут быть составлены из нескольких колонок, также вы можете ввести подсказки (хинты) для оптимизатора MySQL, указывая на индексы, что вы создали.

Хинтинг индексов

Оптимизатор MySQL будет использовать статистику, основанную на запросах таблиц, чтобы выбрать лучший индекс для выполнения запроса. Он действует достаточно просто, основываясь на встроенной статистической логике, поэтому имея несколько вариантов, не всегда делает правильный выбор без помощи хинтинга. Чтобы убедиться, что был использован правильный (или неправильный) ключ, воспользуйтесь ключевым словам FORCE INDEX, USE INDEX и IGNORE INDEX в вашем запросе. Вы можете прочитать больше о хинтинге индексов в справке MySQL .

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

В дополнение к EXPLAIN существует ключевое слово DESCRIBE. Вместе с DESCRIBE можно просматривать информацию из таблицы следующим образом:

Добавляем индекс

Для добавления индексов в MySQL надо использовать синтаксис CREATE INDEX. Есть несколько видов индексов. FULLTEXT Применяется для полнотекстового поиска, а UNIQUE - для хранения уникальных данных.

Чтобы добавить индекс в вашу таблицу, используйте следующий синтаксис:

Mysql> CREATE INDEX idx_bookname ON `books` (bookname(10)); Это создаст индекс на таблице books, которая будет использовать первые 10 букв из колонки, которая хранит названия книг и имеет тип varchar. В этом случае, любой поиск с запросом WHERE на название книги с совпадением до 10 символов будет давать такой же результат, как и просмотр всей таблицы от начала до конца.

Композитные индексы

Индексы имеют большое влияние на скорость выполнения запросов. Только назначения главного уникального ключа недостаточно - композитные ключи являются реальной областью применения в настройке MySQL, что иногда требует некоторых A/B проверок с использованием EXPLAIN.

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

Mysql> CREATE INDEX idx_composite ON users (username, active); Как только мы создали ключ на основе колонки username, в котором хранится имя пользователя и колонки active типа ENUM, определяющий, активен ли его аккаунт. Теперь все оптимизировано для запроса, который будет использовать WHERE для поиска валидного имени пользователя с активным аккаунтом (active = 1).

Насколько быстра ваша MySQL?

Включим профилирование, чтобы подробнее рассмотреть MySQL запросы. Это можно сделать, выполнив команду set profiling=1, после чего для просмотра результата надо выполнить show profiles.

Если вы используете PDO, выполните следующий код:

$db->query("set profiling=1"); $db->query("select headline, body, tags from posts"); $rs = $db->query("show profiles"); $db->query("set profiling=0"); // отключить профилирование после выполнения запроса $records = $rs->fetchAll(PDO::FETCH_ASSOC); // получить результаты профилирования $errmsg = $rs->errorInfo(); //Отлавливаем некоторые ошибки здесь То же самое можно сделать с помощью mysqli:

$db = new mysqli($host,$username,$password,$dbname); $db->query("set profiling=1"); $db->query("select headline, body, tags from posts"); if ($result = $db->query("SHOW profiles", MYSQLI_USE_RESULT)) { while ($row = $result->fetch_row()) { var_dump($row); } $result->close(); } if ($result = $db->query("show profile for query 1", MYSQLI_USE_RESULT)) { while ($row = $result->fetch_row()) { var_dump($row); } $result->close(); } $db->query("set profiling=0"); Это вернет вам профилированные данные, содержащие время выполнения запроса во втором элементе ассоциативного массива.

Array(3) { => string(1) "1" => string(10) "0.00024300" => string(17) "select headline, body, tags from posts" } Этот запрос выполнялся 0.00024300 секунд. Это довольно быстро, поэтому не будем беспокоиться. Но когда числа становятся большими, мы должны смотреть глубже. Перейдите к вашему приложению, чтобы потренироваться на рабочем примере. Проверьте константу DEBUG в конфигурации вашей базы данных, а затем начните изучать систему, включив вывод результатов профилирования с помощью функций var_dump или print_r. Так вы сможете переходить со страницы на страницу в вашем приложении, получив удобное профилирование системы.

Полный аудит работы базы вашего сайта

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

Чтобы включить логирование в MySQL 5.1.6 используйте глобальную переменную log_slow_queries, также вы можете отметить файл для логирования с помощью переменной slow_query_log_file. Это можно сделать, выполнив следующий запрос:

Set global log_slow_queries = 1; set global slow_query_log_file = /dev/slow_query.log; Также это можно указать в файлах конфигурации /etc/my.cnf или my.ini вашего сервера.

После внесения изменений не забудьте перезагрузить MySQL сервер необходимой командой, например service mysql restart, если вы используете Linux.

В версиях MySQL после 5.6.1 переменная log_slow_queries обозначена как устаревшая и вместо нее используется slow_query_log. Также для более удобного дебаггинга можно включить вывод в таблице, задав переменной log_output значение TABLE, однако эта функция доступна только с MySQL 5.6.1.

Log_output = TABLE; log_queries_not_using_indexes = 1; long_query_time = 1; Переменная long_query_time определяет количество секунд, после которых выполнение запроса считается медленным. Значение это 10, а минимум это 0. Также можно указать миллисекунды, используя дробь; сейчас я указал одну секунду. И теперь каждый запрос, который будет выполняться дольше 1 секунды, записывается в логи в таблице.

Логирование будет вестись в таблицах mysql.slow_log и mysql.general_log вашей MySQL базы данных. Чтобы выключить логирование, измените log_output на NONE.

Логирование на рабочем сервере

На рабочем сервере, который обслуживает клиентов, лучше применять логирование только на короткий период и для мониторинга нагрузки, чтобы не создавать лишней нагрузки. Если ваш сервис перегружен и необходимо безотлагательное вмешательство, попробуйте выделить проблему, выполнив SHOW PROCESSLIST, или обратитесь к таблице information_schema.PROCESSLIST, выполнив SELECT * FROM information_schema.PROCESSLIST;.

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

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

Логирование множества запросов

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

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

Горячий и холодный кэш

Количество запросов и нагрузка сервера имеет сильное влияние на исполнение, также может повлиять на время выполнения запросов. При разработке вы должны взять за правило, что выполнение каждого запроса должно быть не более доли миллисекунды (0.0xx или быстрее) на свободном сервере.

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

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

Исправление медленных запросов

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

Если вы пока не нашли медленного запроса, проверьте настройки long_query_time, если вы пользуетесь этим методом логирования. Иначе, проверив все ваши запросы профилирования (set profiling=1), составьте список запросов, отнимают больше времени, чем доля миллисекунд (0.000x секунд) и начнем из них.

Распространенные проблемы

Вот шесть самых распространенных проблем, которые я находил, оптимизируя MySQL запросы:

ORDER BY и filesort

Предотвращение filesort иногда невозможно из-за выражения ORDER BY. Для оптимизации сохраните результат в Memcache, или выполните сортировку в логике вашего приложения.

Использование ORDER BY вместе с WHERE и LEFT JOIN

ORDER BY очень замедляет выполнение запросов. Если это возможно, старайтесь не использовать ORDER BY. Если же вам необходима сортировка, то используйте сортировку по индексам.

Применение ORDER BY по временным колонками

Просто не делайте этого. Если вам нужно объединить результаты, сделайте это в логике вашего приложения; не используйте фильтрацию или сортировку во временной таблице запроса MySQL. Это требует много ресурсов.

Игнорирование индекса FULLTEXT

Использование LIKE это самый лучший способ сделать полнотекстовый поиск медленным.

Беспричинный выбор большого количества строк

Забыв о LIMIT в вашем запросе можно сильно увеличить время выполнения выборки из базы данных в зависимости от размера таблиц.

Чрезмерное использование JOIN вместо создания композитных таблиц или представления

Когда в одном запросе вы пользуетесь больше чем тремя-четырьмя операторами LEFT JOIN, спросите себя: все ли здесь верно? Продолжайте, если у вас есть на то веская причина, например - запрос используется не часто для вывода в панели администратора, или результат вывода может быть сохранен в кэше. Если же вам нужно выполнять запрос с большим количеством операций объединения таблиц, тогда лучше задуматься о создании композитных таблиц из необходимых столбиков или использовать представления.

Итак

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

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

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

Зачем оптимизировать запросы к базе данных

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

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

Некоторые действия можно выполнить разными способами, например, посчитать количество найденных в таблице записей можно при помощи функции mysql_num_rows (но делать этого не рекомендуется), а можно и при помощи конструкции SELECT COUNT(). Нами лично было проведено исследование, в котором мы создали огромную таблицу данных, содержащую несколько сотен тысяч записей и весящую более одного гигабайта, а затем попробовали посчитать количество строк указанными способами.

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

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

Как оптимизировать запросы к базе данных

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

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

CREATE TABLE `test` (`ID` INT NOT NULL AUTO_INCREMENT , `TITLE` VARCHAR(100) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL , `ANNOUNCEMENT` TEXT CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL , `TEXT` TEXT CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL , PRIMARY KEY (`ID`)) ENGINE = MYISAM ;

Теперь, когда тестовая таблица у нас уже есть, нужно наполнить ее абстрактными данными. Как видно из структуры только что созданной нам таблицы, нам потребуются следующие данные для заполнения:

• Заголовок
• Анонс
• Полный текст

За абстрактными текстами мы по привычке пойдем на сервис Яндекс.Рефераты , созданный как раз для подобных целей. Нам посчастливилось наткнуться на тему «Торсионный фотон в XXI веке», ее и возьмем.

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

Получившийся запрос мы сюда копировать не будем, т. к. это будет более 4000 символов не уникального текста, взятого у самого Яндекса, что довольно дерзко, да и вам это тоже не нужно. Лучше мы набросаем простейший цикл на PHP, который быстро добавит в базу данных столько записей, сколько мы захотим. Для начала это будет 100000 статей.

Чем меньше запросов к базе данных, тем лучше

Уже на этом этапе мы покажем вам распространенную ошибку, которую сами же сейчас специально и допустим.

For($i=1;$i<100000;$i++) { mysql_query("INSERT INTO `test` (`ID`, `TITLE`, `ANNOUNCEMENT`, `TEXT`) VALUES (NULL, "Заголовок", "Анонс", "Полный текст")"); }

В качестве запроса мы вставили скопированный из phpmyadmin код, который был отображен на экране после единичного добавления первой статьи вручную. Сразу хочется отметить, что таким образом запросы к базе данных строить не стоит. Мы это сделали лишь потому, что нам просто нужно было быстро наполнить таблицу случайными данными, а этот запрос пишется быстрее, чем тот, который более оптимален. В этом цикле у нас получилось 99999 отдельных обращений к базе данных (первое мы осуществили вручную из phpmyadmin), что является очень плохим тоном.

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

INSERT INTO `test` (`ID`, `TITLE`, `ANNOUNCEMENT`, `TEXT`) VALUES (NULL, "Заголовок", "Анонс", "Полный текст"), (NULL, "Заголовок", "Анонс", "Полный текст"), (NULL, "Заголовок", "Анонс", "Полный текст"), …

Если вернуться к нашему первому способу, то он бы выглядел вот так:

INSERT INTO `test` (`ID`, `TITLE`, `ANNOUNCEMENT`, `TEXT`) VALUES (NULL, "Заголовок", "Анонс", "Полный текст") INSERT INTO `test` (`ID`, `TITLE`, `ANNOUNCEMENT`, `TEXT`) VALUES (NULL, "Заголовок", "Анонс", "Полный текст") INSERT INTO `test` (`ID`, `TITLE`, `ANNOUNCEMENT`, `TEXT`) VALUES (NULL, "Заголовок", "Анонс", "Полный текст") …

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

Производить выборку только необходимых скрипту полей

Здесь все очень просто – та или иная функция нуждается в определенных данных из целевой таблицы. Очень часто оказывается так, что нужно вытащить вообще все поля, особенно, если таблица довольно большая и этих полей больше 10.

SELECT * FROM `test`

В данном запросе звездочка означает то, что будут извлечены данные из всех полей таблицы test. А что, если этих полей в таблице 20-30 штук или больше? Скрипту скорее всего необходимы лишь некоторые из них, а все остальные, которые не будут никак использоваться, будут выбраны зря. Такая операция будет выполняться медленнее, чем если бы вы указали через запятую только те поля, которые вам действительно нужны в данный момент.

SELECT `ID`, `TITLE` FROM `test`

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

Объединение нескольких запросов в один

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

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

Допустим, вам нужно вывести на экран какую-нибудь случайную статью, а снизу подписать ее именем автора. Связь таблиц между собой в данном случае очевидна и происходит по идентификатору пользователя, т. е. ID пользователя в таблице users должен соответствовать полю USER_ID в таблице posts. Данная связь является стандартной и должна быть понятна всем, без исключения.

Итак, чтобы выбрать случайную статью, вы пишете запрос следующего вида:

$rs_post = mysql_query("SELECT `ID`, `USER_ID`, `TITLE`, `TEXT` FROM `posts` ORDER by RAND() LIMIT 1");

Из таблицы posts случайным образом выберется одна статья. После чего наши действия будут иметь примерно такой вид:

$row_post = mysql_fetch_assoc($rs_post); $userID = $row_post["USER_ID"];

Теперь переменная $userID содержит идентификатор пользователя, являющегося автором этой статьи и для того, чтобы получить его данные, например NAME (имя) и SURNAME (фамилию), вы будете обращаться к таблице users и запрос будет выглядеть примерно так:

$rs_user = mysql_query("SELECT `NAME`, `SURNAME` FROM `users` WHERE `ID` = "".$row_post["USER_ID"]."" LIMIT 1");

Кстати, не забывайте обрамлять одинарными кавычками переменные в запросах, особенно это нужно делать, когда данные поступают извне, при помощи GET или POST. Это создаст дополнительное препятствие для злоумышленников и является одной из мер, направленных на защиту от SQL-инъекций . Итак, вернемся к нашему примеру. После того, как запрос к базе данных был сделан, далее все просто – получаем имя и фамилию и выводим в качестве подписи к статье. Задача выполнена.

Но эти два запроса можно оптимизировать, превратив в один. Для этого мы воспользуемся конструкцией LEFT JOIN:

SELECT `posts`.`ID`, `posts`.`USER_ID`, `posts`.`TITLE`, `posts`.`TEXT`, `users`.`NAME`, `users`.`SURNAME` FROM `posts` LEFT JOIN `users` ON `posts`.`USER_ID` = `users`.`ID` ORDER by RAND() LIMIT 1

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

Заключение

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

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