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

Question

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

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

Мой вопрос находится в 2-х частей:

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

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

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

Спасибо.

Edit:

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

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

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

Answer 1

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

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

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

Answer 2

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

Answer 3

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

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

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

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

Here's one article об индексах в доступе.

Answer 4

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

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

Answer 5

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

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

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

Answer 6

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

1) индексирование полей используются в том, где пункты (упомянутые уже)

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

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

Answer 7

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

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

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

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

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

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

Answer 8

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

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

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

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

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

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

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

Answer 9

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