Доступ к производительности базы данных

Question

По нескольким причинам один из моих проектов размещен на сервере общего хостинга. и разработан в asp.Net/C# с ​​ доступом к базам данных (не вариант, так что не смейтесь над этим ограничением, это не от меня).

Большинство моих запросов относятся к последним записям баз данных, к которым они обращаются.

Мой вопрос состоит из 2 частей:

1- Порядок записей в базе данных только визуальный или существует реальная разница внутри. Более конкретно, причина, по которой я спрашиваю, состоит в том, что в соответствии с тем, как это в настоящее время разработано, все записи (для всех баз данных в этом проекте) упорядочены по ключевому идентификатору строки (который является полем автоматического номера) по возрастанию, но так как более 80% моих запросов будут Запрашивать поля, которые должны быть ближе к концу таблицы, увеличит ли это производительность запросов, если я установлю в таблице отображение самой последней записи сверху, а не в конце?

2- Есть ли какие-либо другие настройки производительности, которые могут быть выполнены, чтобы помочь с таблицами доступа?

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

Спасибо.

Edit:

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

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

• Вы все говорите одно и то же, я уже делаю все, что можно сделать для повышения производительности доступа. Я дам вопрос «принятый ответ» тому, кто ответил быстрее всего. Спасибо всем.

Answer 1

Насколько я знаю ...

1 - Это изменение будет просто визуальным. Там не будет никакого воздействия.

2 - Убедитесь, что ваши поля проиндексированы. Если поля, к которым вы обращаетесь, уникальны, убедитесь, что вы сделали поля уникальным ключом.

Answer 2

Да, существует фактический порядок записей в базе данных. Установка значений по умолчанию в настройках таблицы не изменит этого.

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

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

Answer 3

Чтобы понять ответы здесь, полезно рассмотреть, как работает доступ, в неиндексированной таблице вряд ли будет какое-либо значение в организации данных так, чтобы последние доступные записи были в конце. Действительно, в силу того факта, что Access / JET является базой данных ISAM, все наоборот. (http://en.wikipedia.org/wiki/ISAM) Это довольно спорный вопрос, однако, как я никогда бы не предложить положить часто используемые значения в верхней части таблицы, то лучше всего, как говорят другие, чтобы полагаться на полезных индексов.

Answer 4

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

• Длина поля, создавайте поля настолько большими, насколько они вам нужны, но не перебирайте их - например, если у вас есть числовое поле и значение никогда не будет больше 1000 (ради аргумента ) затем не вводите его как длинное целое, что-то меньшее, например, целое, было бы более уместным, или используйте одинарное вместо двойного для десятичных чисел и т. д. Аналогичным образом, если у вас есть текстовое поле, которое не будет иметь более 50 символов, не устанавливать его на 255 и т. д. и т. д. Звучит очевидно, но это делается часто с мыслью, что «мне может понадобиться это место в будущем», и ваше приложение страдает в то же время .

• Чтобы не разбить предмет индексации до смерти ... , но , таблицы, которые вы объединяете в своих запросах, должны иметь установленные отношения, это создаст индексы для внешних ключей, которые значительно увеличивает производительность соединений таблиц (ПРИМЕЧАНИЕ. Дважды проверьте все внешние ключи, чтобы убедиться, что они действительно были проиндексированы, я видел случаи, когда их не было - так что, очевидно, связь явно не означает, что правильные индексы были создано)

• Очевидно, что регулярное сжатие вашей БД также может повысить производительность, это уменьшает внутреннюю фрагментацию файла и может ускорить процесс.

• На самом деле Access имеет анализатор производительности, под инструментами Анализ > Производительность , возможно, стоит запустить его на ваших таблицах и запросах, чтобы хотя бы посмотреть, что из этого получится. с. анализатор таблиц (доступный из того же меню) может помочь вам разделить таблицы с большим количеством избыточных данных, очевидно, используйте с осторожностью - но это может быть полезно.

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

http://office.microsoft.com/en-us/access/hp051874531033.aspx

Answer 5

Что касается порядка таблицы, Jet / ACE записывает фактическую дату таблицы в порядке PK. Если вы хотите другой заказ, измените PK.

Но это не должно быть серьезной проблемой.

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

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

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

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

Answer 6

Вы действительно испытываете проблемы с производительностью сейчас или это просто общий вопрос оптимизации? Также из вашего поста звучит так, будто вы говорите о БД с 1 таблицей, это точно? Если у вас уже есть проблема, и вы имеете дело с одновременным доступом, некоторые ответы могут быть:

1) поля индексации, используемые в предложениях where (уже упоминалось)

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

3) Если это сценарий отчетности, все запросы одинаковы или одинаковы, параллелизм несколько высок (очень относительное число предоставлено Access), и данные не очень изменчивы, рассмотрите возможность сохранения данных в файл, который может периодически обновляется, таким образом снимая нагрузку с запроса из механизма доступа.

Answer 7

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

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

Answer 8

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

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

По умолчанию в столбце первичного ключа будет только индекс, поэтому, если вы используете любой другой столбец (или комбинацию столбцов), вам следует создать один или несколько индексов.

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

Вот одна статья об индексах в Access.

Answer 9

Вы можете использовать индексы для полей, которые вы ищете (не вы уже?). http://www.google.com.br/search?q=microsoft+access+indexes