Оптимизация базы данных MS SQL при помощи Database Engine Tuning Advisor для конечных пользователей. Оптимизация бд
Оптимизация базы данных mysql | Блог Короткова Николая
Привет всем!Сегодня мы с вами рассмотрим такое понятие, как оптимизация базы данных mysql! Об этом я сам узнал совсем недавно и спешу поделиться с вами, т.к. информация, которую я вам сейчас расскажу очень ценная!
Для чего все это нужно? На что влияет? Как воплотить в реальность? На все эти вопросы я постараюсь дать четкий ответ в этом посте!
А теперь небольшая предыстория. В общем, недавно получил письмо на свой e-mail адрес, следующего содержания:
В течение последних 3 дней средний уровень нагрузки, создаваемый Вашим аккаунтом *******, составил 119% от допустимого уровня Вашего тарифного плана. Мы рекомендуем Вам перейти на тарифы VPS. Обращаем Ваше внимание, что в случае регулярного превышения лимитов, мы оставляем за собой право заблокировать Ваш аккаунт согласно пункту Договора...
Оба на, приплыли — подумал я в тот момент! Согласитесь, не очень приятно получать такие письма. А так как с подобного рода проблемой я столкнулся впервые, представляете, в каком я был недоумении? Моему возмущению не было предела! Какой нафиг VPS? Я можно сказать только обжился на одном тарифе, а мне тут предлагают перейти на виртуальный хостинг, который в три раза дороже. Ну нет уж ребята, — думаю я, — еще рановато.
Пишу в обратку письмо моему хостеру, с просьбой пояснить мне, с какого это перепуга у меня зашкаливает нагрузка? Ведь моему блогу всего-то два с небольшим месяца от роду. Да и посещаемость не велика. В общем, пишу, что категорически против переходить на VPS, считаю, что это не целесообразно на столь раннем этапе развития ресурса и прошу указать мне на мои ошибки, что с ними делать и как в дальнейшем их контролировать!
В ответ получаю следующее:
Уважаемый абонент, мы вас не собираемся отключать именно сейчас, это банальное предупреждение, но мол надо с этим, что-то делать. Проблема превышения нагрузки не зависит напрямую от посещаемости, а в большей степени зависит от не правильной оптимизации вашего ресурса. Для отслеживания нагрузки мы вам вывели в панели управления счетчик, который обновляется каждые 10 минут:
Ну спасибо за разъяснения, — думаю про себя. Пойду изучать проблему. Набрав в интернете запрос «как снизить нагрузку на хостинг» понял, что я не один такой, а на самом деле проблема довольно актуальная. И рано или поздно коснется многих. Ознакомившись более детально с проблемой, понял, что у меня есть два выхода из данной ситуации:
- Обратиться за помощью к профессионалам (фрилансерам), заплатив им определенную сумму денег, что всегда успеется.
- Постараться устранить проблему самому.
Так вот, я выбрал второй вариант и скажу вам честно, пока что ни на грамм не пожалел. Мне удалось снизить нагрузку на хостинг в два-три раза. Вот посмотрите сами:
Разница, на лицо! Сейчас я вам покажу и расскажу, что я для этого сделал:
— оптимизировал базу данных mysql, что существенно отразилось на снижении нагрузки на хостинг и ускорении wordpress;— избавился от порядка 8 ненужных плагинов.— ускорил wordpress, отредактировав несколько файлов темы своего блога.
Так как материал довольно таки объемный, я решил разбить его на три части. Из этой статьи вы узнаете, как снизить нагрузку на хостинг за счет оптимизации базы данных. В следующей статье я вам расскажу, как заменить часть плагинов кодами. И последняя статья будет на тему ускорения блога. Когда я все это проделал со своим ресурсом, я был в шоке над тем, как мой блог стал грузиться! По сравнению с тем, что было — он стал летать.
В общем, материал, который вы почерпнете из этих трех постов, будет ну просто обалденным. Не пропустите, подпишитесь на обновления блога!
Оптимизация базы данных
Прежде чем вы начнете производить различные действия с базой данных, обязательно делайте резервную копию. Чтобы в случае возникновения проблем можно было все быстренько восстановить. База данных содержит всю историю вашего ресурса, в ней хранятся все записи, присутствующие на вашем блоге! А вообще, советую вам взять за правило сохранять базу данных каждый день! Это у вас займет буквально 1 минуту, но зато вы будете всегда спать спокойно. Сами понимаете может случится всякое.
1. Делаем резервную копию базы данных
Для удобства соединения с сервером и обработки данных я пользуюсь FTP — клиентом FileZilla. Очень классная штука, как-нибудь напишу об этом клиенте отдельный пост, не переключайтесь. В общем, вам нужно перейти на свой сервер и найти в нем вкладку «Базы данных» или «Базы данных MySQL», что-то в этом роде. На каждом сервере база данных есть, при переходе сервер может запросить пароль. Он у вас должен быть. При покупке хостинга пароль предоставляется.
В итоге вы должны оказаться вот на такой странице, phpMyAdmin:
Заходите в базу данных, кликнув по ее названию. Перед вами откроется таблица базы данных (кликните для увеличения):
Нажимаете «Экспорт» и «ОК». Сохраняете на своем ПК. Все, база данных сохранена, теперь можем приступать к ее оптимизации. Обратите внимание, если на вашем хостинге присутствует поле «Сохранить как файл» не забудьте напротив него поставить галочку! А также запомните, сколько весит в данный момент ваша база данных, а потом посмотрите сколько она будет весить после оптимизации.
У меня она весила до оптимизации 26 Mb — это УЖАС, а что сейчас? А сейчас она весит всего 2 Mb! Представляете, сколько всякого ненужного хлама она содержала в себе? Представляете, какую нагрузку она создавала на сервере? После оптимизации базы данных, мой блог стал летать, как реактивный самолет! В общем, после того как вы проделаете все ниже описанные действия, вы почувствуете существенную разницу!
2. Отключаем ревизии постов и устанавливаем минимальный срок хранения удаленных файлов в корзине
Что такое ревизия постов? Когда вы пишите пост в блог, wordpress автоматически, через определенный промежуток времени, сохраняет резервную копию каждого поста в базе данных, в общем, делает авто сохранение. А теперь представьте когда вы напишите 50 постов на блоге? Сколько копий постов у вас будет сохранено? Это ЖЕСТЬ! Пока вы пишите пост, у вас уже как минимум проходит 10 авто сохранений!
Плюс ко всему этому, если вы удаляете файлы, они у вас скапливаются в корзине, что также нагружает базу данных. Конечно, хорошо если вы сразу удалите файл и из корзины, но частенько случается, что многие про это забываю, а некоторые просто забивают! А это ой как не хорошо... База все растет, нагрузка на сервер все больше и больше, блог грузится все медленнее и медленнее... Вы задумывались, к каким последствиям это может привести?
Вот основная часть последствий, но далеко не всех: снижение индексации, частые отказы, ухудшение поведенческих факторов, понижение позиций в выдаче поисковиков... А дальше, автор в подает в отчаяние от не оправданных ожиданий. Желание вести блог со временем пропадает и все! КРАХ!
Все это я к чему говорю? За базой данных постоянно нужно следить и содержать ее в надлежащем состоянии. Поймите, база данных — это как сердце блога. При постоянной нагрузке на сердце не нужным хламом, со временем оно не выдержит и ОСТАНОВИТСЯ! Я думаю, вы меня поняли? Поэтому хватит ужастиков и переходим к оптимизации базы данных.
Итак, открываем файл wp-config.php, он находится в корне вашего блога, т.е. ваш хостинг/httpdocs или public_html (в зависимости от хостинга)/wp-config.php. И вставляем в него две строчки:
1 2 | define('WP_POST_REVISIONS', false); define('EMPTY_TRASH_DAYS', 1); |
Строка №1 отключает ревизию постов, строка №2 означает, сколько дней будут храниться удаленные файлы в вашей корзине. Как видите, я поставил «1», можно конечно поставить и «0», но если вдруг по неосторожности у вас дрогнет рука и вы нажмете на ссылку «удалить», все — КАПЕЦ!
А после просиживания за компом 5-8 часов, поверьте мне, это возможно! Так что я предпочитаю оставить циферку «1». Конечно, после удаления файла лучше сразу же почистить корзину вручную, но если даже вы забудете это сделать, спустя сутки файл из корзины автоматически удалится! Вот как это выглядит у меня:
С этим разобрались, идем дальше.
3. Удаляем ревизии постов
Если в предыдущем пункте мы отключили ревизию постов, то в этом пункте нам нужно удалить все ревизии постов, скопившиеся за все время ведения блога. Если вы этого не разу не делали, то у вас сохранилось их невероятно большое количество! Давайте это сделаем. Копируем вот эту строку:
DELETE FROM wp_posts WHERE post_type = "revision" |
Переходим снова в базу данных MySQL, как описано в первом пункте. Заходим во вкладку SQL, вставляем в поле скопированную строчку и нажимаем «ОК»:
База данных спросит:
Отвечаем «ОК» и смотрим, сколько не нужных ревизий постов содержала в себе ваша база данных, и сколько времени уходило на то, чтобы запрос обработать. А каждая частичка времени дает свою нагрузку:
Я делал чистку 3 дня назад, поэтому у меня она еще не обросла ревизиями. Когда я первый раз почистил базу, у меня было удалено аж 1800 с чем-то строк! Представляете, сколько копий ненужных постов в ней хранилось? Идем дальше.
4. Оптимизируем записи в wp-post
Папка wp-post содержит все записи блога. Точно так же как и в предыдущем пункте, копируем строку:
и вставляем в поле SQL запроса. Нажимаем «ОК», смотрим:
Все, запрос выполнен!
5. Чистим wp-postmeta
Что именно будем чистить? Папка wp-postmeta содержит в себе:
— время последнего редактирования какого-либо из постов. Значения никакого не имеет, а нагрузку на сервер, какую никакую, а дает;— содержание предыдущего ЧПУ (человека понятного урла). Если вы когда-нибудь меняли постоянную ссылку в любом посте. То при смене ее, она не удаляется, а оседает в папке wp-postmeta и нагружает вашу базу.
Делаем все тоже самое, копируем вот этот код:
DELETE FROM `wp_postmeta` WHERE `meta_key` IN('_edit_lock', '_edit_last','_wp_old_slug') |
Вставляем его в поле запроса SQL, и жмем «ОК». Смотрим на результат:
ЧПУ ссылки я не менял, а вот ошибки в постах находил и после редактирования делал повторное сохранение, отсюда и 6 строк.
6. Удаляем спам-комментарии
Делается аналогично, копируем код:
DELETE FROM wp_comments WHERE comment_approved = 'spam'; |
вставляем в поле SQL запроса, жмем «ОК», смотрим результат:
Как вы видите «0». После выполнения этого запроса, вы забудете про спам комментарии!
7. Удаляем пингбеки
Пингбеки — это уведомления о том, что на ваш пост или страницу кто-то ссылается. Нам это не нужно, лишняя нагрузка! Удаляем!
Копируем код:
DELETE FROM wp_comments WHERE comment_type = 'pingback'; |
Дальше, все тоже самое.
8. Отключаем пингбеки
Из прошлого пункта мы выяснили, что пингбеки не несут никакой пользы для нашего ресурса, а только его засоряют. Поэтому давайте их и вовсе отключим. Копируем этот код:
UPDATE wp_posts p SET p.ping_status = 'closed' |
а дальше вы уже знаете, что делать!
Ну как вам такая чистка? Понравилась? А теперь посмотрите, сколько стала весить ваша база данных после ее оптимизации? Заметно уменьшился размер? А я вам говорил! Посмотрите, как стал грузиться ваш блог! Он должен летать! Но и это еще не все на сегодня. Сейчас мы рассмотрим еще один последний пункт, который также существенно улучшит оптимизацию.
9. Устанавливаем плагин Optimize DB
Об этом плагине я уже вкратце упоминал в этом посте. Ну давайте более подробно рассмотрим, как им пользоваться. Данный плагин, как вы уже догадались, способствует оптимизации базы данных! Скачайте архив с плагином себе на ПК , вот ссылка и активируйте его:
Дальше переходим в панель «Инструменты», выбираем «Optimize DB» и нажимаем «Optimize Now»
Все, ваша база данных оптимизирована дополнительно при помощи плагина:
После оптимизации деактивируйте плагин, чтобы он не нес дополнительной нагрузки на ваш ресурс. И вообще, советую вам производить все выше описанные действия с периодичностью раз в месяц можно даже чаще. И тогда ваш блог будет грузиться молниеносно и нагрузка на сервер будет минимальной.
А в следующей части поста, я вам покажу, как заменить часть не ненужных плагинов кодами. Обязательно подпишитесь на обновления, чтобы ничего не пропустить. Это будет мощный пост, после которого ваш сервер будет легок как пушинка!
А на этом я с вами буду прощаться. На сегодня у меня все, желаю всем успехов, и помните оптимизация базы данных это колоссальное снижении нагрузки на ваш ресурс. Всем пока и до скорых встреч.
И на последок порция приколов:
Ну как вам статья? Я уверен, что вы останетесь довольны после ее прочтения и проделанных рекомендаций со своим ресурсом! Жду ваших комментариев!
С уважением, Николай Коротков
blogiseo.ru
Оптимизация Базы Данных - что это, зачем нужна и как провести? Экопарк Z
Оптимизация Базы Данных — это совершенно необходимая процедура приведения базы данных сайта в состояние, в котором из неё удалено почти всё лишнее и устаревшее.
Процедуру эту считаю весьма тонкой и ответственной. Чтобы, получив доступ к базе данных своего сайта, вносить в неё изменения вручную, нужно быть специалистом по базе данных. Специалисты хостинга не обязаны проводить эту процедуру, а искать посторонних специалистов нет никакого желания.
Доверять публикациям в Интернете, описывающим эту процедуру, весьма рискованно, ибо авторы публикаций не могут ничего гарантировать и не несут никакой ответственности за свои рекомендации.
К нашему счастью, на сайте WordPress есть несколько плагинов, которым можно доверить эту процедуру, ибо они скачаны и проверены сотни тысяч раз. Уже подобрал парочку таких плагинов, установил их, но пока не активировал ни одного. Просто пока нет на эту процедуру времени и решимости.
Даю информацию по этим двум плагинам:
1. Optimize Database after Deleting Revisions, как следует из названия, он проводит оптимизацию Базы Данных после удаления лишних редакций страниц. Отзывы об этом плагине в Рунете хорошие, сделан плагин в Нидерландах,
-
Версия: 2.7.7
-
Автор: CAGE Web Design | Rolf van Gelder, Eindhoven, The Netherlands
-
Обновление: 2 месяца назад
-
Требуемая версия WordPress: 2.0 или выше
-
Совместим вплоть до: 3.8.2
-
Скачан: 155 645 раз
2. BackWPup имеет не совсем удачное название, ибо этот плагин проводит не только бэкап, но и оптимизацию Базы Данных, а также многое другое:
-
Версия: 3.1.2
-
Автор: Inpsyde GmbH
-
Обновление: 1 месяц назад
-
Требуемая версия WordPress: 3.4 или выше
-
Совместим вплоть до: 3.8.2
-
Скачан: 1 230 264 раза
Прочие подробности смотрите сами перед инсталляцией плагинов. Надеюсь, что число скачиваний этих плагинов гарантирует их безошибочность и эффективность.
Так как WordPress регулярно обновляется (сейчас у меня установлена уже версия 3.9.1), перед активацией плагинов нужно будет проверить их совместимость с действующей версией WordPress.
Бэкап Базы Данных и всего сайта делаю регулярно, а оптимизацию Базы Данных наметил на 25.05.14 Когда проделаю её, опишу в подробностях эту процедуру и достигнутые изменения значений показателей сайта. Собираюсь применить оба плагина, надеясь, что второй дооптимизирует Базу Данных за первым или хотя бы подтвердит эффективность действий первого.
Пока что замечу лишь, что после проведения процедуры оптимизации Базы Данных плагин можно деактивировать: ему незачем быть постоянно активированным. Достаточно примерно раз в месяц его активировать, чтобы снова провести оптимизацию Базы Данных, а потом опять следует усыпить плагин до следующей оптимизации Базы Данных.
Наблюдение за значениями показателей на главной странице панели управления хостинга Timeweb показало, что в июне 2014-го года размер базы данных упал с 90-та мегабайт до 30-ти мегабайт. Считаю, что процедура оптимизации базы данных проведена или автоматически, или силами специалистов хостинга, поэтому сам не намерен в ближайшее время этим заниматься.
Приглашаю всех высказываться в Комментариях. Критику и обмен опытом одобряю и приветствую. В хороших комментариях сохраняю ссылку на сайт автора!
И не забывайте, пожалуйста, нажимать на кнопки социальных сетей, которые расположены под текстом каждой страницы сайта.Продолжение тут…
ep-z.ru
Оптимизация в базах данных
Оптимизация базы данных – создание таких условий, когда обеспечивается наибольшее быстродействие базы данных при минимальных затратах. (в принципе оптимизация без указания чего это очень расплывчатое понятие) Здесь понимается создание условий максимального быстродействия при возможно минимальных ресурсах.
Оптимизация может зависеть от многих факторов, которые условно можно разделить на 3 группы:1) оптимизация структуры базы данных (нормализация базы данных): см. в 5-ой лекции или Дейта;2) оптимизация запросов: в каждой базе данных есть в той или иной мере хороший автоматический оптимизатор), переделывает написанный вами запрос, так чтобы этот запрос выполнялся быстрее), который работает лучше человека, т.к. во-первых, несмотря на то, что в жизни встречаются специалисты, которые могут написать запрос лучше, чем оптимизатор, таких специалистов единицы, обычные люди не могут сразу написать хороший запрос, во-вторых, программа в отличие от человека не устает, в-третьих, программа в состоянии передрать большее число вариантов, чем человек, в-четвёртых, у программы есть доступ к дополнительной информации (статистика, которая в отличие от индексов собирается периодически), до которой человек не может добраться или не может её обработать за достаточно короткий срок и сделать правильные выводы. Оптимизатор в любом случае даст хороший вариант запроса;3) оптимизация приложений.
Обзор процессов оптимизацииФактически сам процесс оптимизации проходит в 4 этапа:1) преобразование написанного вами запроса во внутреннюю форму. При составление запроса можно использовать операторные диапазоны. (например: A between A1 and A2, как правило такого рода «between» он меняет на «»; или «in»-попадание во множество, он его тоже разделяет на части «=»тому-то, «=»тому-то и т.п.) Он преобразует некоторые операторы на уровень «and» и «or», чтобы потом заняться преобразование этих логических выражений (начинаются логические скреки).
2) преобразования в каноническую форму. Для каждого вида запроса есть шаблоны хороших запросов, фактически оптимизатор начинает искать подходящий вариант запроса (запрос с подзапросом, запрос с объединение и т. д.), подходящую каноническую форму, которая заведомо известна уже отлажена и хорошо выполняется.
3) выбирается потенциально низкоуровневая процедура для выполнения запроса, т.е. из канонической формы преобразуется в использование низкоуровневых процедур и функций, используемых в языке. (интерпретируемый язык преобразуется в исполняемый язык). Составляется текст запроса с учетом путей доступа, выбирается тот или иной индекс (здесь оптимизатор пользуется статистикой размещения данных на диске).
4) генерируется и выполняется план.Подбор низких процедур и план выполнения происходит на основе некоторых критериев, которые будут рассмотрены в следующем посте.
Оптимизация приложенийПроизводительность работы существенно зависит и от приложения.
Обычно в этой связи рассматривают 2 основных вопроса:1) минимизация соединения с базой данных. (потому что на соединение с базой данных тратиться большое время)2) перенос вычислительной работы на сервер с использованием встроенных или хранимых процедур и функций, потому что при выборки Вы не посылаете запрос по сети, а Вы посылаете вызов функции или процедуры (это небольшое имя с параметрами), она обращается к процедуре, которая на сервере, сервер обращается к данным и возвращает вам результат. (вместо того, чтобы гнать длинный текст туда и т. д.)
all4study.ru
Делаем оптимизацию таблиц базы данных MySQL
01/09/201602/09/201603/09/201604/09/201605/09/201606/09/201607/09/201608/09/201609/09/201610/09/201611/09/201612/09/201613/09/201614/09/201615/09/201616/09/201617/09/201618/09/201619/09/201620/09/201621/09/201622/09/201623/09/201624/09/201625/09/201626/09/201627/09/201628/09/201629/09/201630/09/201601/10/201602/10/201603/10/201604/10/201605/10/201606/10/201607/10/201608/10/201609/10/201610/10/201611/10/201612/10/201613/10/201614/10/201615/10/201616/10/201617/10/201618/10/201619/10/201620/10/201621/10/201622/10/201623/10/201624/10/201625/10/201626/10/201627/10/201628/10/201629/10/201630/10/201631/10/201601/11/201602/11/201603/11/201604/11/201605/11/201606/11/201607/11/201608/11/201609/11/201610/11/201611/11/201612/11/201613/11/201614/11/201615/11/201616/11/201617/11/201618/11/201619/11/201620/11/201621/11/201622/11/201623/11/201624/11/201625/11/201626/11/201627/11/201628/11/201629/11/201630/11/201601/12/201602/12/201603/12/201604/12/201605/12/201606/12/201607/12/201608/12/201609/12/201610/12/201611/12/201612/12/201613/12/201614/12/201615/12/201616/12/201617/12/201618/12/201619/12/201620/12/201621/12/201622/12/201623/12/201624/12/201625/12/201626/12/201627/12/201628/12/201629/12/201630/12/201631/12/201601/01/201702/01/201703/01/201704/01/201705/01/201706/01/201707/01/201708/01/201709/01/201710/01/201711/01/201712/01/201713/01/201714/01/201715/01/201716/01/201717/01/201718/01/201719/01/201720/01/201721/01/201722/01/201723/01/201724/01/201725/01/201726/01/201727/01/201728/01/201729/01/201730/01/201731/01/201701/02/201702/02/201703/02/201704/02/201705/02/201706/02/201707/02/201708/02/201709/02/201710/02/201711/02/201712/02/201713/02/201714/02/201715/02/201716/02/201717/02/201718/02/201719/02/201720/02/201721/02/201722/02/201723/02/201724/02/201725/02/201726/02/201727/02/201728/02/201701/03/201702/03/201703/03/201704/03/201705/03/201706/03/201707/03/201708/03/201709/03/201710/03/201711/03/201712/03/201713/03/201714/03/201715/03/201716/03/201717/03/201718/03/201719/03/201720/03/201721/03/201722/03/201723/03/201724/03/201725/03/201726/03/201727/03/201728/03/201729/03/201730/03/201731/03/201701/04/201702/04/201703/04/201704/04/201705/04/201706/04/201707/04/201708/04/201709/04/201710/04/201711/04/201712/04/201713/04/201714/04/201715/04/201716/04/201717/04/201718/04/201719/04/201720/04/201721/04/201722/04/201723/04/201724/04/201725/04/201726/04/201727/04/201728/04/201729/04/201730/04/201701/05/201702/05/201703/05/201704/05/201705/05/201706/05/201707/05/201708/05/201709/05/201710/05/201711/05/201712/05/201713/05/201714/05/201715/05/201716/05/201717/05/201718/05/201719/05/201720/05/201721/05/201722/05/201723/05/201724/05/201725/05/201726/05/201727/05/201728/05/201729/05/201730/05/201731/05/201701/06/201702/06/201703/06/201704/06/201705/06/201706/06/201707/06/201708/06/201709/06/201710/06/201711/06/201712/06/201713/06/201714/06/201715/06/201716/06/201717/06/201718/06/201719/06/201720/06/201721/06/201722/06/201723/06/201724/06/201725/06/201726/06/201727/06/201728/06/201729/06/201730/06/201701/07/201702/07/201703/07/201704/07/201705/07/201706/07/201707/07/201708/07/201709/07/201710/07/201711/07/201712/07/201713/07/201714/07/201715/07/201716/07/201717/07/201718/07/201719/07/201720/07/201721/07/201722/07/201723/07/201724/07/201725/07/201726/07/201727/07/201728/07/201729/07/201730/07/201731/07/201701/08/201702/08/201703/08/201704/08/201705/08/201706/08/201707/08/201708/08/201709/08/201710/08/201711/08/201712/08/201713/08/201714/08/201715/08/201716/08/201717/08/201718/08/201719/08/201720/08/201721/08/201722/08/201723/08/201724/08/201725/08/201726/08/201727/08/201728/08/201729/08/201730/08/201731/08/201701/09/201702/09/201703/09/201704/09/201705/09/201706/09/201707/09/201708/09/201709/09/201710/09/201711/09/201712/09/201713/09/201714/09/201715/09/201716/09/201717/09/201718/09/201719/09/201720/09/201721/09/201722/09/201723/09/201724/09/201725/09/201726/09/201727/09/201728/09/201729/09/201730/09/201701/10/201702/10/201703/10/201704/10/201705/10/201706/10/201707/10/201708/10/201709/10/201710/10/201711/10/201712/10/201713/10/201714/10/201715/10/201716/10/201717/10/201718/10/201719/10/201720/10/201721/10/201722/10/201723/10/201724/10/201725/10/201726/10/201727/10/201728/10/201729/10/201730/10/201731/10/201701/11/201702/11/201703/11/201704/11/201705/11/201706/11/201707/11/201708/11/201709/11/201710/11/201711/11/201712/11/201713/11/201714/11/201715/11/201716/11/201717/11/201718/11/201719/11/201720/11/201721/11/201722/11/201723/11/201724/11/201725/11/201726/11/201727/11/201728/11/201729/11/201730/11/201701/12/201702/12/201703/12/201704/12/201705/12/201706/12/201707/12/201708/12/201709/12/201710/12/201711/12/201712/12/201713/12/201714/12/201715/12/201716/12/201717/12/201718/12/201719/12/201720/12/201721/12/201722/12/201723/12/201724/12/201725/12/201726/12/201727/12/201728/12/201729/12/201730/12/201731/12/201701/01/201802/01/201803/01/201804/01/201805/01/201806/01/201807/01/201808/01/201809/01/201810/01/201811/01/201812/01/201813/01/201814/01/201815/01/201816/01/201817/01/201818/01/201819/01/201820/01/201821/01/201822/01/201823/01/201824/01/201825/01/201826/01/201827/01/201828/01/201829/01/201830/01/201831/01/201801/02/201802/02/201803/02/201804/02/201805/02/201806/02/201807/02/201808/02/201809/02/201810/02/201811/02/201812/02/201813/02/201814/02/201815/02/201816/02/201817/02/201818/02/201819/02/201820/02/201821/02/201822/02/201823/02/201824/02/201825/02/201826/02/201827/02/201828/02/201801/03/201802/03/201803/03/201804/03/201805/03/201806/03/201807/03/201808/03/201809/03/201810/03/201811/03/201812/03/201813/03/201814/03/201815/03/201816/03/201817/03/201818/03/201819/03/201820/03/201821/03/201822/03/201823/03/201824/03/201825/03/201826/03/201827/03/201828/03/201829/03/201830/03/201831/03/201801/04/201802/04/201803/04/201804/04/201805/04/201806/04/201807/04/201808/04/201809/04/201810/04/201811/04/201812/04/201813/04/201814/04/201815/04/201816/04/201817/04/201818/04/201819/04/201820/04/201821/04/201822/04/201823/04/201824/04/201825/04/201826/04/201827/04/201828/04/201829/04/201830/04/201801/05/201802/05/201803/05/201804/05/201805/05/201806/05/201807/05/201808/05/201809/05/201810/05/201811/05/201812/05/201813/05/201814/05/201815/05/201816/05/201817/05/201818/05/201819/05/201820/05/201821/05/201822/05/201823/05/201824/05/201825/05/201826/05/201827/05/201828/05/201829/05/201830/05/201831/05/201801/06/201802/06/201803/06/201804/06/201805/06/201806/06/201807/06/201808/06/201809/06/201810/06/201811/06/201812/06/201813/06/201814/06/201815/06/201816/06/201817/06/201818/06/201819/06/201820/06/201821/06/201822/06/201823/06/201824/06/201825/06/201826/06/201827/06/201828/06/201829/06/201830/06/201801/07/201802/07/201803/07/201804/07/201805/07/201806/07/201807/07/201808/07/201809/07/201810/07/201811/07/201812/07/201813/07/201814/07/201815/07/201816/07/201817/07/201818/07/201819/07/201820/07/201821/07/201822/07/201823/07/201824/07/201825/07/201826/07/201827/07/201828/07/201829/07/201830/07/201831/07/201801/08/201802/08/201803/08/201804/08/201805/08/201806/08/201807/08/201808/08/201809/08/201810/08/201811/08/201812/08/201813/08/201814/08/201815/08/201816/08/201817/08/201818/08/201819/08/201820/08/201821/08/201822/08/201823/08/201824/08/201825/08/201826/08/201827/08/201828/08/201829/08/201830/08/201831/08/201801/09/201802/09/201803/09/201804/09/201805/09/201806/09/201807/09/201808/09/201809/0
inter-net.pro
Оптимизация базы данных плагином Optimize DB
Сегодня у меня снова технические заморочки, точнее пост на техническую тему. Буду рассказывать о том, как оптимизировать базу данных блога с помощью плагина Optimize DB.
Приветствую дорогие друзья.
Оптимизация базы данных плагином Optimize DB
Что такое оптимизация базы данных? Зачем оптимизировать эту самую базу? В самом начале данного поста я постараюсь ответить на данные вопросы.
И прежде, чем я приступлю к ответам на данные вопросы, разрешите мне рассказать, что из себя представляет база данных.
База данных (БД) — это некий массив данных, который «жизненно» необходим для работы того или иного алгоритма, программы. А раз мы с Вами ведем речь о блогах, то таким алгоритмом является блог, весьма сложный механизм.
И можно вполне логично предположить, что таких массивов может быть несколько: одни хранят, к примеру информацию о комментариях, другие — о зарегистрированных пользователях…
Так для облегчения управления этим массивом информации (БД) и было придумана система управления базами данными (СУБД).
Тут я немного отвлекусь от темы повествования данного поста и хочу вспомнить о своих годах обучения в стенах военного училища Ракетных войск. Я писал об этом в разделе «О себе»…
Как нибудь напишу об этом более подробнее.
Думаю, ни для кого не секрет, что обучаясь в стенах данного заведения, мы были непосредственно связаны с ракетной техникой, ракетами и … системами управлениями ракет.
А какие системы управления чем либо, без базы данных и систем управления этими базами данными. У нас был целый отдельный факультет, который изучал именно эту дисциплину, что называется «от корки до корки».
Я учился на механическом факультете. Моя специальность — «железо» ракет, их устройство с технической части.
Так вот, в этих базах данных находилась информация (алгоритм) полета ракеты: скорость, высота, наклон к горизонту, температура, количество топлива, время полета, общее время…. И т.д.
Таких данных больше сотни. Если кому интересно узнать об этом — поступайте в стены Ракетного училища, Вас там этому обучат, уверен )))
Я лишь хотел сказать то, что принципиальной разницы в работе любой базе данных — один. И основная задача любой СУБД — правильно распорядится необходимым в данный отрезок времени массивом данных.
Если вернуться с «неба на землю», то можно с полной уверенностью сказать, что самой «продвинутой» СУБД для интернет технологий является MySQL. Именно она и лежит в основе CMS WordPress, если можно так выразиться.
Основные преимущества MySQL — быстрота, надежность. Но тут есть одно но… Как и любая система, это — довольно сложный механизм, а поэтому требует к себе периодического внимания и ухода.
Со временем база данных разрастается, ее массив становиться все больше и больше. Это вполне очевидно: не один «клик» мышкой в Вашем блоге, не обходится без ее внимания. Иначе бы он просто напросто не работал бы.
Происходит самое обычное засорение, падет производительность. Возникает необходимость в ее очистки, иначе говоря — оптимизации. И поможет нам в этом — плагин Optimize DB.
Качаем его http://wordpress.org/plugins/optimize-db/
Устанавливаем, активизируем — все как обычно.
Для тех, кто возможно, не знает, как это делать — читаем статью здесь
Плагин не требует никакой настройки и установки. В этом и заключается его ценность.
Единственное, что от нас будет требоваться — изредка заходить в админпанель блога, «Плагины» => «Установленные» и выбрав данный плагин, нажимать на надпись «Optimize«
Вам будет доступно следующее окно:
Там нажимаем «Optimize now», т.е. «Оптимизировать сейчас».
Все. Ваша база, буквально за несколько секунд, будет оптимизированна.
P.S. Что я еще хотел сказать… А, вспомнил. После того, как Вы проделаете все эти не сложные манипуляции, я советую Вам отключить данный плагин, т.е. нажать «Деактивировать».
Зачем Вам включенный и по сути не работающий плагин? Перегружать блог? Думаю, это не к чему. А раз в неделю (примерно) снова включать его и делать все то же самое: т.е. оптимизировать базу данных и снова отключать.
Все плагины, которые находятся в неактивном состоянии находятся вверху окна меню «Плагины».
Тут же и будет находится «Ваш» плагин.
Вот собственно, пожалуй и все, что я хотел рассказать по данной теме. В данном посту я Вам, что из себя представляет оптимизация базы данных с помощью «легкого для понятия» плагина Optimize DB.
Естественно, у тех ребят, которые читают данный пост может возникнуть вопрос — и это все что нужно для оптимизации базы данных WordPress?
Конечно же нет.
Это самый простой метод, который может проделать на своем блоге самый «зеленый» новичок. Впереди, на страницах моего блога Вас ожидает еще несколько постов на эту тему.В следующий раз мы с Вами поговорим о том, что необходимо сделать еще, чтобы ускорить и подчистить базу данных блога.
Подписывайтесь на обновления и не пропускайте этот материал.
Новость 1. Количество комментариев на блоге перевалило за 2000 человек. Ура, товарищи.Новый рубеж взят, впереди следующий: 3000 комментариев.Даешь, 3000 комментов !!!
Напоминаю, что я с большим удовольствием, награждаю самых активных комментаторов каждый месяц по условиям конкурса.
О условиях, проходящих конкурсах на моем блоге, Вы можете прочитать здесь.
Новость 2. Блог на прошлой недели перевалил рубеж в 250 посетителей за сутки. До 1000 осталось совсем не много ). В этом году, а то и раньше ))) — я это сделаю !
!--noindex-->alexandrbykadorov.ru
Оптимизация структуры баз данных MySQL / Песочница / Хабр
На самом деле оптимизировать работу MySQL можно с самого корня: с планирования структур и связей самих таблиц. При создании правильной и продуманной структуры вопрос об оптимизации вполне может и не встать.Я приведу несколько простых правил, которых постоянно придерживаюсь:
- Всегда нужно правильно указать тип полей для данных, что будут находиться в этой таблице. Не секрет, что если в поле записаны числовые данные, то и поле должно быть числового типа — это уменьшает размер данных, занимаемых полем.
- Всегда нужно правильно рассчитать размер поля.
- Каждая таблица должна иметь первичные индексы. Это даст более быстрый доступ к записи.
- Сделать объём данных как можно меньше. Этого можно достичь использованием правильной ссылочности и типов полей.
- Хранить даты и время, например вставки записи, либо её обновления, лучше типом integer. Дело в том, что когда сохраняешь дату типом datetime, поле занимает 13 байт, но если эту дату записать в UNIX формате, то запись будет занимать всего 9 байт.
- Хранить ip-адреса лучше не текстовым типом, а типом integer. Это достигается при помощи 2-х функций: INET_ATON(перевод ip-адреса в числовой вид) и INET_NTOA(перевод ip-адреса из числового вида). В таком случае экономия в 11 байт на 1 ip адрес.
- Не допускать избыточности информации. Стараться не хранить одинаковую информацию в нескольких таблицах, а объединять данные в этих таблицах числовыми ссылками.
- Хранить логи лучше в таблице типа ARCHIVE. В таком случае мы жертвуем скоростью на выборку данных из этой таблицы, т.к. затрачивается время на разархивирование данных, но при этом мы получаем экономию памяти почти в 40%.
- Временные данные, используемые только во время работы скрипта, лучше хранить в таблице типа MEMORY. В таком случае данные хранятся в оперативной памяти, а не на жёстком диске, благодаря этому достигается большая скорость доступа к данным. Но не стоит забывать о том, что при перезагрузке MySQL-сервиса, таблица типа MEMORY полностью очищается.
- Большие таблицы (более 50 миллионов записей) лучше разделять на несколько мелких. Часто этот вопрос встаёт при хранении тех же логов, т.к. при этом затрачивается немало времени на поиск данных в этой таблице. Но здесь будет важно знать, что для хранения редко-используемых таблиц лучше создать еще одну базу данных и копировать эти таблицы туда. Т.к. если в базе данных присутствует большое количество таблиц, то операции открытия, закрытия и создания будут медленными.
- Лучше сделать один вложенный запрос, чем несколько маленьких.
Спасибо за внимание. Надеюсь, статья поможет вам избежать проблем с большим размером и низкой скоростью БД.
habr.com
Оптимизация базы данных MS SQL при помощи Database Engine Tuning Advisor для конечных пользователей
Введение
Часто такая задача, как оптимизация быстродействия БД, оказывается за скобками разработки. Проект сдан, тесты выполняются и быстродействие на конкретных данных – уже проблема не разработчика, а клиента.К тому же, проповедование Agile всё больше склоняет команды к использованию ORM. А это ещё бОльшая абстракция от СУБД и такие вещи, как: индексы, кластерные индексы, статистика данных — разработчикам или не известны или забыты.
Подобную методику лично я успешно использовал на MS SQL Server 2005, 2008, 2008R2. Все эти версии уже имеют встроенные инструменты для профилирования и тюнинга.
Как это можно использовать
Разработчики смогут использовать методику для дополнительного “разгона” своего творения перед релизом. А конечные пользователи (например, владельцы магазинов) для поддержания жизни в уже введённой в эксплуатацию системе без дополнительных капиталовложений.Делай раз
Для начала нам придётся собрать статистику использования нашей БД. Для этого мы запускаем профайлер SQL Server Profiler. Открываем новую сессию и включаем фильтрацию запросов по нашей БД. Далее запускаем сбор статистики и ждём, пока наберётся достаточно запросов. Обычно, пары-тройки минут достаточно. В это время можно любоваться, как в БД летят всякие as Extent1 и SingleRowTable1. Заканчиваем сбор статистики кнопочкой Stop Selected Trace. Выделяем все записи и жмём File – Export – Extract SQL Server Events – Extract Transact-SQL events. Эта команда позволяет нам сохранить в файл именно SQL запросы, обрезав ненужные нам данные. Допустим, файл мы назвали “log1.sql”.Делай два
Теперь нам нужно запустить Database Engine Tuning Advisor. Это тоже стандартная утилита от Microsoft, доступная после установки MS SQL 2005, 2008[R2], 2012(?). У неё удобный wizard-подобный интерфейс. Для начала во вкладке General мы устанавливаем файл для имитации нагрузки “log1.sql” и указываем нашу БД “testBD” в качестве пациента для диагностики в 2х местах на форме. Таб Tuning Options мы не трогаем, его настройки по умолчанию нам подходят. По умолчанию там отключены опции анализа, которые потребуют не самых простых решений, например, нам не предложат сделать партиционирование. Всё, жмём заветную Start Analysis и смотрим, как Tuning Advisor имитирует нагрузку на БД.Профит
После окончания пяти обязательных пунктов для диагностики программа, в качестве результата, предлагает нам процент повышения быстродействия и действия, которые необходимо предпринять, чтобы его достичь. От нас требуется лишь выделить те пункты, которые мы считаем нужными реализовать, и через меню Actions – Apply Recommendations применить их. Просто, быстро, эффективно.habr.com