подсказки для оптимизации sql базы данных только для чтения

Кортежи, будучи неизменными, являются большей эффективной памятью; списки, для эффективности, сверхвыделяют память для разрешения, добавляет без постоянного realloc с. Так, если Вы хотите выполнить итерации через постоянную последовательность значений в Вашем коде (например, for direction in 'up', 'right', 'down', 'left':), кортежи предпочтены, так как такие кортежи предварительно вычисляются во время компиляции.

скорости Доступа должны быть тем же (они оба хранятся как непрерывные массивы в памяти).

, Но, alist.append(item) очень предпочтен atuple+= (item,), когда Вы имеете дело с изменяемыми данными. Помните, кортежи предназначаются, чтобы рассматриваться как записи без имен полей.

10
задан Jason 9 December 2009 в 20:17
поделиться

7 ответов

Одна из стратегий состоит в том, чтобы добавить файловую группу только для чтения в вашу БД и поместить туда таблицы, доступные только для чтения. Файловая группа только для чтения позволяет SQL Server выполнять ряд оптимизаций, включая такие вещи, как снятие всех блокировок.

В дополнение к стандартной оптимизации БД:

  1. Убедитесь, что все таблицы и индексы имеют нулевую фрагментацию.
  2. Рассмотрите возможность добавления индексов, которые вы в противном случае можно было бы избежать из-за чрезмерных затрат на обновление
7
ответ дан 3 December 2019 в 14:34
поделиться

В базе данных:

  1. Денормализовать.
  2. При необходимости использовать больше индексов.
  3. Сгруппировать некоторые данные, если они вам нужны в отчетах.

В программе:

  1. Используйте уровень изоляции READ UNCOMMITTED.
  2. Используйте автоматическую фиксацию, чтобы избежать долгосрочных транзакций.
6
ответ дан 3 December 2019 в 14:34
поделиться

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

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

5
ответ дан 3 December 2019 в 14:34
поделиться

Я не уверен, что вы считаете «нормальными правилами», но вот несколько предложений.

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

  • Если у вас есть представления, используйте индексированные представления (создайте для них кластерные индексы). Поскольку их никогда не придется обновлять, снижение производительности сводится на нет.

  • Прочтите эту статью .

5
ответ дан 3 December 2019 в 14:34
поделиться
  1. Денормализовать данные.
  2. Применить соответствующие индексы.
  3. Предварительно рассчитать агрегаты.
  4. Реализовать базу данных на полосе диска.
  5. Я никогда не видел этого, но если бы вы могли каким-то образом загрузить все это в память (RAM-диск ???), это было бы очень быстро, верно?
4
ответ дан 3 December 2019 в 14:34
поделиться

Для таблицы, предназначенной только для чтения, рассмотрите возможность изменения индексов, чтобы использовать коэффициент заполнения 100%.

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

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

4
ответ дан 3 December 2019 в 14:34
поделиться

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

Также важно, как ваша база данных размещена на дисках. Для производительности только для чтения я бы рекомендовал Raid 10 с отдельными mdf и ldf для изолированных шпинделей. Обычно для производственной базы данных это Raid 5 для данных и Raid 1 для журналов. Убедитесь, что у вас есть файл tempdb для каждого процессора, используемый для сортировки, хороший начальный размер - 5 ГБ данных и 1 ГБ журнала для каждого процессора. Также убедитесь, что вы запускаете свои запросы или процессы через showplan, чтобы помочь оптимизировать их как можно лучше. Убедитесь, что в настройках сервера включен параллелизм.

2
ответ дан 3 December 2019 в 14:34
поделиться
Другие вопросы по тегам:

Похожие вопросы: