Как вы оптимизируете таблицы для конкретных запросов?

Question

1. Какие шаблоны вы используете для определения частых запросов?
2. Как вы выбираете факторы оптимизации?
3. Какие типы изменений можно сделать?

Answer 1

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

Первый вопрос, который нужно задать: « есть проблемы с производительностью? »
Если нет проблем, то все готово. Это часто бывает. Ницца.

С другой стороны ...

Определение частых запросов

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

Выберите факторы оптимизации?

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

Типы изменений, которые можно внести?

Вы специально спрашиваете об оптимизации таблиц.
Вот некоторые вещи, которые вы можете посмотреть:

• денормализация . Это объединяет несколько таблиц в одну более широкую таблицу, поэтому вместо того, чтобы объединить несколько таблиц, вы можете просто прочитать одну таблицу. Это очень распространенная и мощная техника. NB. Я советую сохранить исходные нормализованные таблицы и дополнительно построить денормализованные таблицы - таким образом, вы ничего не выбрасываете. Как вы держите это в актуальном состоянии это другой вопрос. Вы можете использовать триггеры для базовых таблиц или периодически запускать процесс обновления.
• Нормализация . Это не часто считается процессом оптимизации, но это происходит в 2 случаях:
  • Обновления. Нормализация делает обновления намного быстрее, потому что каждое обновление является наименьшим (вы обновляете наименьшую - с точки зрения столбцов и строк - возможную таблицу). Это почти само определение нормализации.
  • Запрос к денормализованной таблице для получения информации, которая существует в таблице намного меньшего размера (меньше строк), может вызывать проблемы. В этом случае сохраните как нормализованную таблицу, так и денормализованную (см. Выше).
• Горизонтальное разделение . Это означает уменьшение размеров таблиц путем помещения некоторых строк в другую, идентичную таблицу. Обычный вариант использования - все строки этого месяца в таблице ThisMonthSales и все более старые строки в таблице OldSales , где обе таблицы имеют одинаковую схему. Если большинство запросов относятся к последним данным, эта стратегия может означать, что 99% всех запросов обращаются только к 1% данных - огромный выигрыш в производительности.
• Вертикальное разделение . Это удаление полей из таблицы и помещение их в новую таблицу, которая присоединяется к основной таблице с помощью первичного ключа. Это может быть полезно для очень широких таблиц (например, с десятками полей) и может помочь, если таблицы заполнены редко.
• * 1060 индексов *. Я не уверен, покрывает ли это ваш вопрос, но на SO есть много других ответов, касающихся использования Indedes. Хороший способ найти регистр для индекса: найти медленный запрос. посмотрите на план запроса и найдите таблицу сканирования. Индекс полей в этой таблице, чтобы удалить сканирование таблицы. Я могу написать больше об этом, если потребуется - оставить комментарий.

Вам также может понравиться мой пост на этом .

Answer 2

Трудно ответить, не зная, о какой системе вы говорите.

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

Answer 3

Ваш вопрос немного расплывчатый. Какая платформа БД?

Если мы говорим о SQL Server:

1. Использовать представления динамического управления. Используйте SQL Profiler. Установите пакет обновления 2 и отчеты панели мониторинга производительности.
2. После определения наиболее дорогостоящих запросов (т. Е. Числа выполнений x, затрачиваемых на один запрос), изучите их планы выполнения и посмотрите размеры соответствующих таблиц, а также, являются ли они преимущественно для чтения или записи или смесь как.
3. Если система находится под вашим полным контролем (приложения и БД), вы часто можете переписывать плохо сформированные запросы (довольно распространенный случай), такие как глубоко коррелированные подзапросы, которые часто можно переписать как Производная таблица включается с небольшой мыслью. В противном случае вы можете создать покрывающие некластеризованные индексы и обеспечить актуальность статистики.

Answer 4

1. Какие шаблоны вы используете для определения частых запросов?

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

2. Как вы выбираете факторы оптимизации?

Я пытаюсь понять, как используется таблица и какие данные в ней содержатся. Я иду со следующими вопросами.

Будет ли обновляться тонна и на каких полях происходят обновления? Есть ли в нем столбцы с низкой кардинальностью?

Стоит ли индексировать? (очень маленькие таблицы могут быть замедлены при доступе по индексу)

Сколько стоит обслуживание / головная боль, чтобы он работал быстрее?

Соотношение обновлений / вставок и запросов?

и т.д.

3. Какие типы изменений можно сделать?

- При использовании Oracle обновляйте статистику! =) * * Тысяча двадцать-семь

- Нормализация / Денормализация может улучшить производительность в зависимости от использования таблицы. Я почти всегда нормализуюсь, и тогда, только если я не смогу каким-либо другим практическим способом ускорить запрос, будет нормализоваться. Хороший способ денормализации для запросов и когда ваша ситуация позволяет это сделать - это нормализовать реальные таблицы и создать денормализованную «таблицу» с материализованным представлением.

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

- Использование индексированных таблиц.

- Секционированные и секционированные таблицы и индексы

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

- Закрепить таблицы в памяти, если необходимо (доступно много и довольно мало)

- Разделение устройства между файлами базы данных индекса и таблицы.

..... список можно продолжить. =)

Надеюсь, это полезно для вас.

Answer 5

индексов на ПК и ФК и одна вещь, которая всегда помогает РАЗДЕЛИТЬ ...

Answer 6

Мой опыт в основном связан с DB2 и небольшим количеством Oracle в первые дни.

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

Например, если у вас есть таблица (x) с двумя столбцами (date и diskusage) и индекс только по дате, запрос:

select diskusage from x where date = '2008-01-01'

будет очень эффективным, так как он может использовать индекс. С другой стороны, запрос

select date from x where diskusage > 90

не будет таким эффективным. В первом случае «план объяснения» сказал бы вам, что он может использовать индекс. В последнем случае он сказал бы, что ему нужно выполнить сканирование таблицы, чтобы получить строки (это в основном просматривает каждую строку, чтобы увидеть, соответствует ли она).

Действительно интеллектуальные СУБД 'также могут объяснить, что вы должны сделать для повышения производительности (в этом случае добавьте индекс на дискус).

Что касается того, как увидеть, какие запросы выполняются, вы можете либо забрать их из СУБД (если это позволяет), либо заставить всех выполнять свои запросы с помощью хранимых процедур, чтобы администратор БД контролировал, какие запросы - это их работа, поддерживая работоспособность БД.

Answer 7

Если ваша таблица преимущественно читается, поместите в нее кластерный индекс.

Answer 8

На сервере SQL вы можете использовать трассировку, чтобы узнать, как выполняется ваш запрос. Используйте ctrl + k или l

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

Более конкретный вопрос наверняка принесет вам лучшие ответы.

Answer 9

1. Для MySQL есть функция под названием протокол медленных запросов

Все остальное зависит от того, какие у вас есть данные и как они настроены.