访问数据库性能

Question

由于一些不同的原因，我的一个项目托管在共享托管服务器上 并使用访问数据库在asp.Net/C#中开发（不是一个选择，所以不要嘲笑这个限制，它不是来自我）。

我的大多数查询都在他们查询的数据库的最后几条记录中。

我的问题分为两部分：

1-数据库中记录的顺序是仅可视的还是内部存在实际差异。更具体地说，我问的原因是它当前设计的方式所有记录（对于该项目中的所有数据库）都按行标识键（自动编号字段）升序排序，但由于超过80％的查询将会如果我将表设置为在顶部而不是在最后显示最新记录，那么查询应该在表格末尾的字段会增加查询性能吗？

2-是否有任何其他性能调整可以帮助访问表？

“访问”和“性能”是一种委婉说法，但数据库类型不是一种选择 到目前为止，它还没有被证明是一个大问题，但如果我可以帮助表现 我当然希望尽我所能。

感谢。

编辑：

• 不，我目前没有遇到我当前设置的问题，只是试图展望并优化所有内容。

• 是的，我确实有索引，并且对每个表的唯一记录标识符都有一个主键（自动索引）。我绝对应该提到这一点。

• 你们都在说同样的话，我已经在为访问性能做了一切。我会向最快回答的问题提出“已接受答案”的问题。 谢谢大家。

Answer 1

据我所知......

1 - 这种变化只是视觉上的。没有影响。

2 - 确保您的字段已编入索引。如果您要查询的字段是唯一的，请确保将字段设为唯一键。

Answer 2

是的，数据库中的记录有实际订单。设置表首选项的默认值不会改变它。

我会确保所有where子句列都有索引。这是一条经验法则。它很少是最佳的，但您必须针对不同的数据库设置进行工作负载测试，以证明最佳解决方案。

我每天都使用传统访问系统，对于并发用户来说速度相当快，但仅适用于少数用户。

Answer 3

您可以在搜索的字段上使用索引（您不是吗？）。 http://www.google.com.br/search?q=microsoft+access+indexes

Answer 4

订单很可能不是问题。此外，我认为你无论如何都不能在Access中真正改变它。

重要的是您如何访问这些记录。您是否通过记录ID直接访问它们？无论您使用何种标准来查找所需的数据，都应该定义适当的索引。

默认情况下，主键列上只有一个索引，因此如果您正在使用任何其他列（或列的组合），则应创建一个或多个索引。

不要只为每一列创建索引。更多索引意味着当插入或更新新记录时，Access将需要全部维护它们，这会使它变慢。

Here's one article关于Access中的索引。

Answer 5

查看您用于查询数据的字段或字段，并确保在这些字段上有索引。如果它与SQL服务器相同，则不需要在索引中包含主键（假设它在此处聚类），因为它默认包含在内。

如果你在一个小的字段子集上运行查询，你可以通过包含所需的所有字段来使你的索引成为一个“覆盖”索引，这里有一个空间权衡，所以我真的只推荐它5个或更少的字段，取决于您的要求。

Answer 6

您实际上是在遇到性能问题还是仅仅是一般性优化问题？同样来自你的帖子听起来你正在谈论一个带有1个表的数据库，这是准确的吗？如果您遇到问题且正在处理并发访问，则可能会有以下答案：

1）在where子句中使用的索引字段（已经提到过）

2）拆分表。例如，如果只访问了80％的表行（如问题中所暗示的那样），请为较旧的记录创建存档表。或者，如果您的大部分性能点击来自读取（复杂报告），并且您不希望影响人们添加记录的性能，请创建一个单独的报告表结构并进行查询。

3）如果这是一个报告场景，所有查询都相似或相同，并发性有点高（给定Access的相对数量很大）并且数据不是非常易变，考虑将数据保存到可以定期的文件中更新，从而从Access引擎中卸载查询工作负载。

Answer 7

关于表顺序，Jet / ACE以PK顺序写入实际表日期。如果您想要不同的订单，请更改PK。

但这不应该是一个重大问题。

您排序的PK以外的字段上的索引应该使排序速度非常快。我的应用程序包含数以千计的记录，这些记录可以立即以非PK排序的顺序返回数据子集。

我认为你正在进行“过早优化”，在实际遇到问题之前担心某事。

我认为您遇到性能问题的唯一情况是，如果您有一张包含数千条记录的表，并且您试图将整个内容呈现给最终用户。这将是一个非常用户敌对的事情，所以我不认为这是你应该担心的事情。

如果它真的是一个问题，那么你应该考虑将你的PK从自动编号改为自然键（尽管这可能是有问题的，给定真实数据和禁止复合唯一索引中的非空字段）。

Answer 8

我有几件事要补充，我没有注意到这里被提及，至少没有明确说明：

• 字段长度，创建您需要的字段尽可能大但不要过去 - 例如，如果您有一个数字字段且值永远不会超过1000（为了参数的缘故） ）然后不要将它键入为Long Integer，像Integer更小的东西会更合适，或者使用单个而不是双倍的十进制数字等。同样的道理，如果你有一个文本字段不会有超过50个字符，不要设置为255等等，听起来很明显，但它已经完成了，通常是“我将来可能需要这个空间”的想法，你的应用程序同时受到影响

• 不要把索引的东西击败... 但是，你在查询中加入的表应该建立关系，这将在外键上创建索引大大提高了表连接的性能（注意：仔细检查任何外键以确保它们确实被编入索引，我已经看到它们没有被显示的情况 - 所以显然关系并不明确意味着正确的索引具有已创建）

• 显然，定期压缩数据库也可以提高性能，这可以减少文件的内部碎片，并可以加快速度。

• Access实际上有一个性能分析器，工具分析＆gt; 效果，可能值得在您的桌面上运行它查询至少看看它是什么。 表格分析器（可从同一菜单中获得）可以帮助您拆分包含大量冗余数据的表格，显然，请谨慎使用 - 但这可能会有所帮助。

这个链接在数据库，表格，查询，表格等几乎所有方面都有很多关于访问性能优化的东西 - 值得一试。“/ p>

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

Answer 9

要理解这里的答案，考虑访问如何工作是有用的，在未编制索引的表中，组织数据不太可能有任何价值，以便最近访问的记录在最后。事实上，由于Access / JET引擎是一个ISAM数据库，它是另一种方式。 （http://en.wikipedia.org/wiki/ISAM）这是没有实际意义的，因为我永远不会建议将经常访问的值放在表的顶部，最好是其他人说要依赖有用的索引。