Как повысить производительность для базы данных MySQL - PullRequest
3 голосов
/ 16 января 2009

Как повысить производительность базы данных mysql, потому что мой сайт размещен на общем сервере, и они заблокировали мою учетную запись из-за "слишком большого количества запросов" материал спросил "индекс" или "кэш" или обрезать мою базу данных Я не знаю, что означает «индекс» и кеш и как это сделать на php спасибо

Ответы [ 8 ]

17 голосов
/ 17 января 2009

Что такое индекс:

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

Теперь представьте, что кто-то приходит к библиотекарю (программа базы данных) и говорит: «Я хотел бы знать, сколько книг Норы Робертс находится в библиотеке». Чтобы ответить на этот вопрос, библиотекарь должен пройти по проходам и посмотреть на каждую книгу в библиотеке, что очень медленно. Если библиотекарь получает много подобных запросов, стоит потратить время на создание карточного каталога по имени автора (указатель на имя) - тогда он сможет гораздо быстрее ответить на такие вопросы, обратившись к каталогу вместо того, чтобы ходить по полкам. По сути, индекс устанавливает «альтернативный порядок» книг - он обрабатывает их так, как если бы они были отсортированы по алфавиту по авторам.

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

Что такое кэширование:

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

В вашем сценарии это может применяться по-разному. Вы можете сохранить результаты запроса к базе данных или вычисления или части отображаемой веб-страницы; Вы можете сохранить его во вторичной таблице базы данных или в файле или в переменной сеанса или в службе памяти, такой как memcached. Вы можете сохранить предварительно проанализированный запрос к базе данных, готовый к запуску. Некоторые библиотеки, такие как Smarty, автоматически сохранят часть или всю страницу за вас. Сохраняя результат и используя его повторно, вы можете избежать выполнения одной и той же работы много раз.

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

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

6 голосов
/ 16 января 2009

Установите копию вашего приложения локально, включите журнал запросов mysql и настройте xdebug или какой-либо другой профилировщик. Начало сбора данных и тестирования вашего приложения. Есть много руководств и книг о том, как оптимизировать вещи. Важно потратить время на тестирование и сбор данных сначала , чтобы оптимизировать нужные вещи.

Используя собранные вами данные, постарайтесь сократить количество запросов на просмотр страницы. В идеале вы должны получить все необходимое за менее чем 5-10 запросов.

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

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

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

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

5 голосов
/ 16 января 2009

Есть несколько вещей, на которые вы можете посмотреть:

  1. Query Design - посмотрите на более продвинутые и быстрые решения
  2. Аппаратное обеспечение - бросьте лучшее и более быстрое оборудование в проблему
  3. Разработка базы данных - используйте индексы и практикуйтесь в правильном проектировании базы данных

Все это легче сказать, чем сделать, но это только начало.

2 голосов
/ 17 января 2009

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

Кстати, так как вы делаете деление в своей математике (почему я понятия не имею), вы должны Google целочисленная математика. Возможно, вы не получите правильные результаты.

2 голосов
/ 17 января 2009

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

Воспроизведите эту среду в своей лаборатории, в идеале, на том же оборудовании, что и на производстве; это включает в себя такие вещи, как контроллер RAID.

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

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

Увеличение объема ОЗУ обычно является самым дешевым способом повышения производительности - убедитесь, что MySQL настроен на его использование - что означает настройку параметров, специфичных для механизма хранения.

Я предполагаю, что у вас есть как минимум 100G данных; если нет, просто купите достаточно оперативной памяти, чтобы вся ваша БД поместилась в оперативной памяти, тогда производительность чтения по существу решена.


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


О, да - еще одна вещь - даже не думайте о развертывании сервера базы данных в 32-битной ОС, это разрушительная трата хорошего оперативного памяти.

1 голос
/ 16 января 2009

Вы не должны выбирать * никогда. Вместо этого выберите только те данные, которые вам нужны для этого конкретного вызова. И что ты собираешься здесь делать?

order by votes*1000+((1440 - ($server_date - date))/60)2+visites600 desc
0 голосов
/ 16 января 2009

уверен этот запрос для получения последних 3 сообщений

select * from posts where visible = 1 and date > ($server_date - 86400) and dont_show_in_frontpage = 0 order by votes*1000+((1440 - ($server_date - date))/60)*2+visites*600 desc limit 3

что ты думаешь?

0 голосов
/ 16 января 2009

У вас могут быть плохо написанные запросы и / или плохо написанные страницы, которые выполняют слишком много запросов. Не могли бы вы привести конкретные примеры запросов, которые вы используете, которые выполняются на регулярной основе?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...