Оптимизация запросов / базы данных MySQL - PullRequest
1 голос
/ 20 декабря 2010

У меня есть две таблицы ТАБЛИЦА А и ТАБЛИЦА В. ТАБЛИЦА A содержит 1 миллион (1 000 000) записей и 4 поля, а ТАБЛИЦА 2 содержит 60 000 и 3 поля. Я выполняю запрос, который объединяет эти две таблицы и использует предложение WHERE, чтобы найти конкретные продукты, такие как продукт WHERE, например «% Bags%», и продукт, например «Bags%», например,

.

Когда я запускаю запрос непосредственно в phpMyAdmin, он возвращает записи примерно через 1 или 2 секунды. Но когда они используются на веб-сайте, они иногда занимают 9 или 10 секунд в соответствии с журналом медленных запросов MySQL. На самом деле мой ответ на сайте иногда был очень медленным, поэтому после расследования я выяснил, что это связано с MySQL, когда я узнал о «медленном журнале запросов».

Журнал медленных запросов состоит из всех операторов SQL, выполнение которых заняло более long_query_time секунд, а для проверки потребовалось как минимум min_examined_row_limit строк.

Таким образом, согласно этому журналу «query_time» для вышеупомянутого запроса составлял 13 секунд, в то время как в некоторых случаях у них даже «query_time» превышал 50 секунд.

В обеих моих таблицах используются ПЕРВИЧНЫЕ ключи и ИНДЕКСЫ. Поэтому я хочу знать, как я могу оптимизировать их больше или есть ли способ оптимизировать настройки MySQL в целом?

Эта медлительность сайта происходит не всегда, а иногда (может быть, один раз в неделю) и длится около 1 или 2 минут. Он получает приличный объем трафика, и есть много других запросов, выше я разместил только один пример.

Спасибо

Ответы [ 4 ]

4 голосов
/ 20 декабря 2010

По всем вопросам, связанным с MySQL и производительностью, проверьте http://www.mysqlperformanceblog.com/

Проверьте свои запросы с помощью EXPLAIN, см. здесь и здесь для получения информации о том, как использоватьОБЪЯСНИТЕ как средство диагностики запросов.

Недостаточно просто иметь индексы.Индексируете ли вы поля, найденные в предложении WHERE?Также есть ли у вас индексы для полей, используемых в предложении WHERE (включая поля, которые вы упоминаете в предложениях ORDER BY, GROUP BY и HAVING, а также JOIN)?Если вы сгруппировали поля в одном индексе, этот индекс не будет обработан, если у вас нет запроса, который ищет все эти поля вместе.Если вы группируете поля в индексе, убедитесь, что он действительно будет использоваться в вашем запросе (EXPLAIN - ваш друг).

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

Здесь - это хороший обзор лучших рекомендаций по производительности от Jay Pipes из MySQL.

1 голос
/ 20 декабря 2010

like '%Bags%' запрос нельзя оптимизировать с помощью индексов.

Единственный способ повысить производительность - использовать полнотекстовые индексы или получить sphinx для поиска.

0 голосов
/ 20 апреля 2015

Существует множество способов оптимизации баз данных и запросов. Мой метод следующий.

Посмотрите на схему БД и посмотрите, имеет ли это смысл

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

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

Запросите только то, что вам действительно нужно

Отфильтруйте как можно больше

Предложение «Где» является наиболее важной частью оптимизации.

Выберите только те поля, которые вам нужны

Никогда не используйте «Выбрать *» - укажите только те поля, которые вам нужны; это будет быстрее и будет использовать меньшую пропускную способность.

Будьте осторожны с соединениями

Соединения дороги с точки зрения времени. Убедитесь, что вы используете все ключи, которые связывают две таблицы вместе, и не присоединяетесь к неиспользуемым таблицам - всегда пытайтесь присоединиться к индексированным полям. Также важен тип соединения (INNER, OUTER, ...).

Оптимизация запросов и хранимых процедур (Most Run First)

Запросы очень быстрые. Как правило, вы можете получить множество записей менее чем за секунду, даже с помощью объединений, сортировки и расчетов. Как правило, если ваш запрос длиннее секунды, вы, вероятно, можете его оптимизировать.

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

Добавление, удаление или изменение индексов

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

Вы особенно хотите использовать индексы для целых чисел, логических значений и чисел. С другой стороны, вы, вероятно, не хотите использовать индексы для BLOB-объектов, VarChars и длинных строк.

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

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

Перемещение запросов к хранимым процедурам (SP)

Хранимые процедуры обычно лучше и быстрее, чем запросы по следующим причинам:

Stored Procedures are compiled (SQL Code is not), making them faster than SQL code.
SPs don't use as much bandwidth because you can do many queries in one SP. SPs also stay on the server until the final results are returned.
Stored Procedures are run on the server, which is typically faster.
Calculations in code (VB, Java, C++, ...) are not as fast as SP in most cases.
It keeps your DB access code separate from your presentation layer, which makes it easier to maintain (3 tiers model).

Удалить ненужные виды

Представления - это особый тип запросов - они не являются таблицами. Они логические, а не физические, поэтому каждый раз, когда вы запускаете select * из MyView, вы запускаете запрос, который делает представление, и ваш запрос в представлении.

Если вам всегда нужна одна и та же информация, просмотры могут быть хорошими.

Если вам нужно отфильтровать представление, это похоже на выполнение запроса по запросу - это медленнее.

Настройки Tune DB

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

****> Использование анализаторов запросов ****

Во многих базах данных есть инструмент для запуска и оптимизации запросов.В SQL Server есть инструмент под названием Query Analyzer, который очень полезен для оптимизации.Вы можете писать запросы, выполнять их и, что более важно, видеть план выполнения.Вы используете выполнение, чтобы понять, что SQL Server делает с вашим запросом.

0 голосов
/ 20 декабря 2010

Это из-за некоторых других запросов выполняются в то время, когда вы собираетесь обновить страницу вашего сайта.так, например, если ваш веб-сайт будет выполнять 8-10 запросов во время обновления страницы, тогда это займет больше времени, чем вы выполняете один запрос в phpmyadmin.и если его выполнение занимает 1-1,5 мин, то это может не вызывать проблемы с запросом, но может также быть проблема со скоростью сервера.

и вы также можете использовать оператор MATCH() AGAINST() для оптимизации этого типа поисковых запросов.

В противном случае вы уже используете PRIMARY KEY, INDEXES and JOINS, поэтому вам не нужно беспокоиться о других вещах.

просто посмотрите.

Спасибо.

...