Оптимальное использование MySQL - Все о хостинге. Полезные статьи и советы.

Меню :

Статьи :

Главная

Форум

Карта сайта

Полезные статьи :

О хостинге :

Новости хостинга :

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

Увеличивается число использующих Интернет в домашних условиях. В октябре 2008 года 56 процентов взрослых пользователей (против 42 процентов прошлого года) чаще всего подключались к Сети с помощью домашних компьютеров. Любопытно, что при этом число юзеров, применяющих для выхода рабочие PC, снизилось с 29 до 17 процентов.

Число семей, имеющих дома компьютеры, сегодня достигло 42 процентов. При этом все большую популярность медленно, но верно завоевывают ноутбуки. Сегодня уже четыре процента домохозяйств пользуется компактными и удобными компьютерами. Для сравнения: два года назад таких семей было в два раза меньше.
Другая сторона увеличения числа пользователей - это рост количества подключенных к Интернету семей. Если представить статистику в таком виде, то сегодня уже 19 из 100 домохозяйств имеют доступ к Всемирной сети. За прошедший год число онлайн-семей увеличилось на 23 процента.

Все о хостинге, как выбрать хостинг, полезные статьи и советы.

Оптимальное использование MySQL

Введение

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

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

Какие данные нужно хранить в MySQL

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

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

Оптимизация запросов

В ситуациях, когда реально требуется получить только определенную порцию данных из MySQL, можно использовать ключ LIMIT для функции SELECT. Это полезно, когда, например, нужно показать результаты поиска чего-либо в базе данных. Допустим, в базе есть список товаров, которые предлагает Ваш интернет-магазин. Выдавать весь список товаров в нужной категории несколько негуманно по отношению к пользователю - каналы связи с интернет не у всех быстрые и выдача лишних ста килобайт информации зачастую заставляет пользователей провести не одну минуту в ожидании результатов загрузки страницы. В таких ситуациях информацию выдают порциями по, допустим, 10 позиций. Неправильно делать выборку из базы всей информации и фильтрацию вывода скриптом. Гораздо оптимальнее будет сделать запрос вида

select good, price from books limit 20,10

В результате, MySQL "отдаст" Вам 10 записей из базы начиная с 20-й позиции. Выдав результат пользователю, сделайте ссылки "Следующие 10 товаров", в качестве параметра передав скрипту следующую позицию, с которой будет делаться вывод списка товаров, и используйте это число при генерации запроса к MySQL. Также следует помнить, что при составлении запросов к базе данных (SQL queries) следует запрашивать только ту информацию, которая Вам реально нужна. Например, если в базе 10 полей, а в данный момент реально требуется получить только два из них, вместо запроса

select * from table_name

используйте конструкцию вида

select field1, field2 from table_name

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

select title from books where author='Иванов'

Также есть ключ LIKE, который позволяет искать поля, значения которых "похожи" на заданный шаблон:

select title from books where author like 'Иванов%'

В данном случае MySQL выдаст названия книг, значения поля author у которых начинаются с 'Иванов'.

Ресурсоемкие операции

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