From: Евгений В. Жданов <eugene@protoplex.ru.>
Date: Mon, 26 Mar 2006 14:31:37 +0000 (UTC)
Subject: О грамотном использовании БД MySQL
Оригинал: http://design.protoplex.ru/?showid2=37
Многие мои друзья и знакомые часто спрашивают меня о том, как устроен
мой сайт, сколько у меня таблиц в базе данных, как я храню данные и по
каким полям веду поиск. Я, конечно, не выдаю все свои государственные
тайны, но всегда понимаю причину таких вопросов и пытаюсь помочь людям
построить быструю и надежную базу данных - т.е. тщательно продумать
структуру БД таким образом, чтобы при увеличении нагрузки или объема
таблиц динамический веб-сайт не превратился в тормозное усмертие. А
ведь многие новички (веб-строители) даже не догадываются о том, что
крупные динамические сайты тормозят вовсе не из-за нагрузки скриптов
на процессор, а в основном из-за неоптимизированного или дохленького
MySQL-сервера. При этом во многом все зависит от того, как устроена
ваша база данных.
Итак, начнем ликбез. Сразу всем вопрос: что делает MySQL во время
записи в таблицы типа INSERT или UPDATE? Правильно - БЛОКИРУЕТ ТАБЛИЦЫ
и пишет в них данные. Скорость записи и поиска может быть достаточно
низкой, поэтому статус таблиц запрещает другим процессам считывать из
них данные до окончания операции записи или обновления и снятия
блокировки. При этом может получиться так, что во время записи
единственного поля в длинные таблицы, ваш MySQL-сервер надолго
заблокирует доступ к таблице остальным скриптам.
Например, вы создали таблицу новостей такого типа:
ID - номер, первичный ключ
TEMA - тема новости
MESS - сообщение, сама новость
VIEWS - количество просмотров
При каждом обращении к новостям, скрипт будет выводить саму новость, а
потом увеличивать поле VIEWS запросом UPDATE table 'NEWS' set
VIEWS=VIEWS+1 where id=ID. При этом количество апдейтов будет довольно
высоким. При высокой посещаемости веб-ресурса или при "нападении" на
сайт поискового робота (эти ребята страдают многопоточностью и могут
запросто повесить ваш сайт своими запросами) несколько одновременных
процессов станут пытаться сделать UPDATE и SELECT. При каждом UPDATE
таблица будет блокироваться (на это уходит время) и все остальные
процессы будут ждать завершения операции. А если таблица достаточно
большая? Например, несколько тысяч записей. Ежу понятно, что
построится очередь из нескольких десятков скриптов, ожидающих ответа
MySQL-сервера. Каждый будет жрать память и держать остальные процессы.
В итоге все у вас зависнет и переглючит. Выход: делать вместо одной
таблицы несколько. Советую разделять поля по типу их использования.
Одну таблицу - только для вывода и редких обновлений или вставок.
Другую - для частых обновлений, но редкого вывода. Например, значения
счетчика обращений держать отдельно в таблицу вида:
ID - номер, первичный ключ
VIEWS - количество просмотров
Сами новости лучше держать в другой таблице, где нет поля VIEWS. При
этом таблица с новостями будет тяжелой (много текста, полей,
индексов), а таблица COUNT (счетчик) будет очень легкой и быстрой.
Таблица NEWS будет кешироваться и выводиться очень быстро при любых
объемах, а таблица COUNT будет быстро обновляться из-за того, что она
очень легкая (всего два целочисленных поля). Разделение данных по
нескольким таблицам существенно ускоряет работу MySQL-сервера. Гораздо
быстрее работают несколько мелких запросов по каждой таблице, чем один
длинный запрос по одной или нескольким таблицам. Имейте это в виду,
чтобы спать спокойно.
Дальше - круче. Чтобы не блокировать лишний раз свои таблицы
используйте при вставках директиву DELAYED. Пример: INSERT DELAYED
into STAT (ID,IP,UTIME) values (null,$ip,NOW()). Он позволяет серверу
ответвлять поток в режиме ожидания, а саму вставку производить тогда,
когда сервер освободится от других запросов или поступит следующий
аналогичный INSERT DELAYED. Обычно отложенный метод подходит для любых
операций с кумулятивными таблицами (когда в основном идут INSERTы, а
данные копятся, а не модифицируются), при которых не особо важно когда
именно подействуют изменения - мгновенно или через несколько секунд,
минут. Например, если хотите собирать IPадреса своих посетителей,
УРЛы, по которым они ходят или страницы, откуда пришли, время. При
добавлении с задержкой скрипт отработает почти мгновенно, еще до
выполнения операции.
Операция UPDATE идет в три этапа: поиск того, что будете менять, затем
запись данных, обновление индексов. При этом, чем больше таблица, тем
дольше поиск. Если есть индексы, то операция кешируется и выполняется
достаточно быстро. Но сам процесс очень емкий. И только дурак не
догонит, что большая таблица со множеством индексов и записей, будет
тормозить при UPDATE. INSERT же выполняется одним залпом, очень
быстро. Поэтому обычно используют аддитивные записи (вставками INSERT)
во временные таблицы, потом блокируют основные талицы, суммируют
обновления, и плюют их в основную таблицу. Получается, что в основном,
главные таблицы работают только в режиме вывода, а обновления идут
гораздо реже и быстрее. Например, можно копить данные о загрузках
новостей во временной таблице, а по крону или иным образом обновлять
счетчик каждые 10 минут (или реже). Это ускорит работу сервера.
При запросах SELECT * FROM таблица скрипт получит все поля данной
таблицы. А нужно ли это? Использование * ведет к лишнему расходу
ресурсов. Гораздо эффективнее использовать точные названия полей,
которые нужны скрипту. Например: SELECT id,name FROM таблица. При
таком запросе передача займет меньше времени и понадобится меньше
ресурсов. Старайтесь ограничивать вывод при помощи директивы LIMIT.
Это также ускоряет вывод.
Поиск по БД идет быстрее если вместо LIKE '%слово%', ставить 'слово%'.
Операции с шаблонами регулярных выражений кешируются только в том
случае, если в начале отсутствует символ %. Поэтому при построении
поисковых запросов с LIKE избегайте начинающих символов %.
При построении таблиц для наиболее используемых полей (при поиске,
сортировке и т.д.) обязательно создавайте индексы. Без индексов
таблицы будут сильно тормозить. Индексы служат для кеширования и
позволяют существенно ускорить вывод данных из таблиц. При этом
таблицы будут занимать больше места на диске и в памяти. Но это в наше
время не проблема.
Используйте надлежащий тип полей для своих записей. Тип TINYINT
занимает 1 байт - самый быстрый. Таблицы с MEDIUMINT быстрее таблиц с
INT. Если ставить полям свойство NOT NULL, то в целом их работа будет
быстрее. VARCHAR медленее CHAR, поэтому таблицы переменной длины (где
есть тип VARCHAR или TEXT) занимают меньше дискового пространства, но
работают медленнее.
По своему опыту скажу, что для большинства сайтов подходят изложенные
советы по работе с MySQL. Чтобы еще больше ускорить свой сервер,
советую частоиспользуемые операции проводить по крону выделенными
процессами и писать данные в различные файлы. Например, раз в 20 минут
запускать скрипт, который будет создавать файл с новостями. Или
например, генерить файл с новостями при их добавлениях или
обновлениях. Таким образом, вы экономите на каждом обращении к БД.
Интерактивность при этом не теряется, а производительность
увеличивается во много раз. Особенно, повторяю, при высокой
посещаемости ресурса. Старайтесь отделить интерактивные операции от
фоновых. Например, на ПротоПлексе работает один интерактивный движок,
но в фоне по заданиям трудятся с десяток различных роботов, которые
генерируют часто вызываемые страницы, рассылают письма и т.д. Крупный
сайт - это не только то, что вы видите, но и бек-енд (обратная
сторона). В фоновом режиме можно быстро и эффективно готовить контент,
освобождая основной движок от лишней работы.
В общем, основы должны быть всем понятны. Дробите все на мелочи, будь
то запросы, таблицы или операции. Структура БД должна быть такой,
чтобы не выполнялось ничего лишнего. Регулярно проводите OPTIMIZE на
таблицах с переменной длиной, особенно, если в них идут удаления
записей. Тестируйте свои запросы на скорость, упрощайте их. Ну а я уже
устал это писать :) Если будут вопросы, пишите, отвечу.
385 Прочтений • [О грамотном использовании БД MySQL (mysql)] [08.05.2012] [Комментариев: 0]
Vova
