В процессе предоставления услуг хостинга мы обращаем интерес на более распространенные оплошности, тот или другой совершают юзеры при разработке собственных виртуальных серверов Один-одинешенек из \”томных\” участков для обычного интернет-профессионалы приходит служба с MySQL-сервером Традиционно исследование принципов функционирования SQL и способов службы с основаниями предоставленных ведется по литературе, из тот или другой выбираются лишь актуальные на фактор чтения вещи – как соединиться с основанием, как сделать запрос, как обновить информацию либо добавить новейшую запись в основание предоставленных и т д Таковой подход, естественно, приносит хотимый итог – интерфейсы интернет-веб-сайта юзера в итоге оказываются вставленными с основанием предоставленных Но не постоянно юзеры думают о том, как нормально действует их основание, как можнож улучшить происходящие при службе с MySQL процессы и каково будет функционирование виртуального сервера при приросшей перегрузке, \”наплывах\” юзеров в итоге, к примеру, \”раскрутки\” веб-сайта Эта статья сориентирует Для вас улучшить службу с СУБД MySQL Изложенный вещество не претендует на детализированное изображение оптимизации MySQL вообщем, а только уделяет свое внимание на более нередко совершаемые юзерами оплошности и ведает о том, как их недопустить Наиболее тщательно выяснить о тонкостях опции MySQL можнож на специализированных страничках, ссылки на тот или другой приведены в баста данной статьи Какие сведения необходимо беречь в MySQL Не пытайтесь поместить в основания предоставленных всю информацию, тот или другой у Вас грызть К примеру, не надо беречь там рисунки, хоть MySQL это и дозволяет Помещая в основание предоставленных двоичные образы графических файлов, Вы лишь замедлите службу собственного сервера Прочесть файл с картинкой с диска еще примитивнее и, с точки зрения употребляемых ресурсов, экономичнее, ежели соединиться из скрипта к SQL, сделать запрос, заработать образ, обработать его и, выдав нужные http-заглавия, изобразить гостю интернет-сервера Во втором случае операция выдачи рисунки востребует в пару раз преимущественно ресурсов процессора, памяти и диска Также заслуживает держать в голове о том, что есть механизмы кэширования интернет-документов, тот или другой разрешают юзеру экономить на трафике, а при динамической генерации контента Вы практически лишаете собственных гостей данной комфортной способности Заместо картинок лучше беречь в MySQL информацию, на базе тот или другой можнож генерировать ссылки на статические рисунки в динамически творимых скриптами документах В ситуациях, иногда реально требуется заработать лишь определенную порцию предоставленных из MySQL, можнож применять ключ LIMIT для функции SELECT Это полезно, иногда, к примеру, необходимо изобразить поисковые результаты чего же-или в основанию предоставленных Допустим, в основанию грызть перечень продуктов, тот или другой дает Ваш веб-магазин Выдавать целый перечень продуктов в подходящей категории немного негуманно по отношению к юзеру – каналы отношения с веб не у целых скорые и выдача излишних 100 кб инфы часто принуждает юзеров провести не одну минутку в ожидании результатов загрузки странички В таковых ситуациях информацию выдают дозами по, допустим, 10 позиций Некорректно мастерить подборку из основания целой инфы и фильтрацию решения скриптом Еще оптимальнее будет сделать запрос облика select good, price from books limit 20,10 В итоге, MySQL \”даст\” Для вас 10 записей из основания начиная с 20-й позиции Выдав итог юзеру, сделайте ссылки \”Последующие 10 продуктов\”, в качестве параметра передав скрипту последующую позицию, с тот или другой будет делаться решение перечня продуктов, и употребляйте это число при генерации запроса к MySQL Также идет держать в голове, что при составлении запросов к основанию предоставленных (SQL queries) идет запрашивать лишь ту информацию, тот или другой Для вас реально нужна К примеру, ежели в основанию 10 полей, а в этот фактор реально требуется заработать лишь два из их, заместо запроса Таковым образом, Вы не будете нагружать MySQL ненадобной службой, занимать излишнюю память и совершать доп дисковые операции Также идет применять ключ WHERE там, где необходимо зарабатывать информацию, попадающую под определенный шаблон К примеру, ежели необходимо заработать из основания поля с наименованиями книжек, создателем тот или другой приходит Иванов, идет применять ус
тановку облика select title from books where author=\’Иванов\’ Также грызть ключ LIKE, тот или другой дозволяет находить поля, значения тот или другой \”схожи\” на данный шаблон : select title from books where author like \’Иванов%\’ В предоставленном случае MySQL выдаст наименования книжек, значения поля author у тот или другой начинаются с \’Иванов\’ Совместно с тем идет держать в голове, что есть операции, исполнение тот или другой само по себе просит огромных ресурсов, чем для обыденных запросов К примеру, внедрение операции DISTINCT к функции SELECT вызывает потребление еще большего числа процессорного медли, чем обыденный SELECT DISTINCT пробует находить неповторимые значения, часто производя множество сопоставлений, подстановок и расплат При этом, чем преимущественно останавливается размер предоставленных, к тот или другой приспосабливается DISTINCT (ведь Ваша основание с течением времени растет), тем медленее будет выполняться таковой запрос и рост ресурсов, вызываемых для исполнения таковой функции, будет происходить не искренне пропорцонально размеру хранимых и обрабатываемых предоставленных, а еще скорее Индексы употребляют для наиболее скорого поиска по значению 1-го из полей Ежели индекс не создается, то MySQL исполняет поочередный просмотр целых полей с самой главной записи до самой крайней, исполняя сравнение избранного значения с начальным Чем преимущественно таблица и чем преимущественно в ней полей, тем подольше исполняется подборка Ежели же у предоставленной таблицы живет индекс для осматриваемого столбца, то MySQL сумеет сделать скорое размещение к физическому расположению предоставленных без необходимости исполнять полный просмотр таблицы К примеру, ежели таблица состоит из 1000 строк, то скорость поиска будет как минимум в сто разов скорее Эта скорость будет еще выше, ежели грызть необходимость обратиться сходу ко целым 1000 столбцам, т к в данном варианте не происходит издержек медли на размещение твердого диска В каких ситуациях творение индекса целенаправлено: Стремительный поиск строк при употреблении сборки WHERE Поиск строк из остальных таблиц при исполнении соединения Поиск значения MIN() либо MAX() для проиндексированного поля Сортировка либо сортировка таблицы в случае, ежели употребляется проиндексированное поле В неких вариантах на сто процентов пропадает необходимость обращаться к файлу предоставленных Ежели все употребляемые поля для некой таблицы цифровые и сформировывают левосторонний индекс для некого ключа, то значения могут иметься возвращены на сто процентов из индексного дерева с намного большей скоростью Ежели выполняются запросы облика и живет разнородный индекс для полей col1 и col2, то сведения будут возвращены впрямую Ежели же сделаны отдельные индексы для col1 и для col2, то оптимизатор испытает отыскать более ограниченный индекс методом определения того, какой из индексов может отыскать младше строк, и будет применять этот индекс для получения предоставленных Ежели у таблицы грызть разнородный индекс, то будет употребляться хоть какое левостороннее совпадение с имеющимся индексом К примеру, ежели грызть разнородный индекс 3-х полей (col1, col2, col3), то индексный поиск можнож исполнять по полям (col1), (col1, col2) и (col1, col2, col3) Как Вы наверное понимаете, для службы с MySQL-сервером нужно предварительно определить с ним соединение, предъявив логин и пароль Процесс агрегата соединения может длиться еще большее пора, ежели конкретная обработка запроса к основанию опосля агрегата соединения Должно логике, нужно избегать излишних соединений к основанию, не отсоединяясь от нее там, где это можнож сделать, ежели в предстоящем планируется продолжить службу с SQL-сервером К примеру, ежели Ваш скрипт определил соединение к основанию, сделал подборку предоставленных для анализа, не надо накрывать соединение к основанию, ежели в процессе службы этого же скрипта Вы планируете результаты анализа поместить в основание Также можнож поддерживать так именуемое persistent (неизменное) соединение к основанию, но это может быть в полном объеме при употреблении наиболее трудных сред программирования, чем php либо perl в обыкновенном CGI-режиме, иногда интерпретатор соответственного языка разово запускается интернет-сервером для исполнения пришедшего запроса Наиболее детально выяснить о том, как улучшить службу MySQL, Вы сможете на страничках, ссылки на тот или другой приведены гуще • Getting Maximum Performance from MySQL
