• 我们用来确定频繁查询的模式是什么？
• 我们如何选择优化因素？
• 一个人可以做出哪些改变？

解决方案

问题有点含糊。哪个数据库平台？

如果我们在谈论SQL Server：

• 使用动态管理视图。使用SQL事件探查器。安装SP2和性能仪表板报告。
• 确定最昂贵的查询后(即运行次数x一个查询的成本)，检查其执行计划，并查看所涉及表的大小，以及它们主要是读还是写，或者两者兼而有之。
• 如果系统在完全控制下(应用程序和数据库)，则通常可以重写格式不正确的查询(很常见)，例如深度相关的子查询，这些子查询通常可以在派生表联接中重新编写。稍加思考。否则，我们可以选择创建覆盖非聚集索引，并确保统计信息是最新的。

如果不知道我们在谈论哪个系统，很难回答。

例如，在Oracle中，企业管理器使我们可以查看哪些查询花费了最多的时间，可以比较不同的执行配置文件，还可以分析一段时间内的查询，从而不必添加对我们有帮助的索引。一个查询会以我们每次运行的其他查询为代价。

• 对于MySQL，有一个称为日志慢查询的功能

其余的取决于我们拥有什么样的数据以及如何设置。

在SQL Server中，我们可以使用trace来查找查询的执行情况。使用ctrl + k或者l

例如，如果我们看到在具有大量记录的表中发生了全表扫描，则它可能不是一个很好的查询。

更具体的问题肯定会为我们带来更好的答案。

如果主要读取表，请在表上放置聚簇索引。

我的经验主要是DB2和早期的Oracle。

如果DBMS有任何优势，它将能够收集特定查询的统计信息，并解释其用于提取数据的计划。

例如，如果我们有一个具有两列(日期和磁盘使用率)的表(x)，并且仅具有日期索引，则查询：

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

由于它可以使用索引，因此效率很高。另一方面，查询

select date from x where diskusage > 90

不会那么有效率。在前一种情况下，"解释计划"将告诉我们可以使用索引。在后者中，它会说它必须进行表扫描以获取行(基本上是查看每一行以查看是否匹配)。

真正智能的DBMS可能还会解释提高性能的方法(在这种情况下，请在磁盘使用率上添加一个索引)。

至于如何查看正在运行的查询，我们可以从DBMS收集查询(如果允许)，也可以强迫每个人通过存储过程进行查询，以便DBA控制查询是他们的工作，并保持数据库有效运行。

这是一个很好的问题，如果范围很广的话(也不是更糟)。
如果我了解我们，那么我们在问如何从头开始解决优化问题。

要问的第一个问题是："是否存在性能问题？"
如果没有问题，那么我们就完成了。通常是这种情况。好的。

另一方面...

确定频繁查询

记录将使我们经常查询。
如果我们使用某种类型的数据访问层，则添加代码以记录所有查询可能很简单。
记录执行查询的时间以及每个查询需要多长时间也是一个好主意。这可以使我们了解问题出在哪里。
另外，询问用户哪些地方使他们烦恼。如果响应速度慢不会使用户烦恼，则没关系。

选择优化因素？

(我可能会误解问题的这一部分)
我们正在寻找查询/响应时间中的任何模式。
这些通常是对大型表的查询，或者是在单个查询中将许多表连接在一起的查询。 ...但是如果我们记录响应时间，则可以以此为指导。

一个人可以做出的改变类型？

我们是专门询问有关优化表的问题。
以下是我们可以寻找的一些东西：

• 非正规化。这会将多个表组合成一个更宽的表，因此，我们可以只读取一个表，而无需将多个表连接在一起的查询。这是一种非常常见且功能强大的技术。注意我建议我们保留原始规范化表并另外构建非规范化表-这样，我们就不会丢掉任何东西。我们如何保持最新状态是另一个问题。我们可以在基础表上使用触发器，或者定期运行刷新过程。
• 查询非规范化表以获取存在于小得多(较少的行)表上的信息，可能会引起问题。在这种情况下，请存储规范化表和非规范化表(请参见上文)。
• 水平分区。这意味着通过将一些行放在另一个相同的表中来缩小表的大小。一个常见的用例是在表ThisMonthSales中具有本月的所有行，在表OldSales中具有所有较旧的行，其中两个表具有相同的架构。如果大多数查询都针对最近的数据，则此策略可能意味着所有查询中的99％仅查看数据的1％-赢得了巨大的性能。
• 垂直分区。这是将表中的字段砍掉，然后将它们放入新表中，该表通过主键连接回主表。这对于非常宽的表(例如，具有数十个字段)很有用，如果表的填充稀疏，则可能会有所帮助。
• Indeces。我不确定问题是否涵盖了这些内容，但是关于索引的使用，SO上还有很多其他答案。查找索引大小写的一个好方法是：查找慢速查询。查看查询计划并找到表扫描。索引该表上的字段，以便删除表扫描。如果需要，我可以写更多内容-发表评论。

我们可能也喜欢我的帖子。

关于PK和FK的索引以及一件事总是对PARTITIONING有帮助...

1.我们用来确定频繁查询的模式是什么？

取决于我们处理数据库的级别。如果我们是DBA或者可以使用这些工具，则Oracle等数据库允许我们在指定的时间段内运行作业并生成统计信息/报告。如果我们是针对db编写应用程序的开发人员，则可以在应用程序中进行性能分析。

2.我们如何选择优化因素？

我尝试大致了解该表的使用方式及其包含的数据。我会回答以下问题。

它会大量更新吗？会在哪些字段上进行更新？
它具有低基数的列吗？

值得索引吗？ (如果由索引访问，则很小的表可能会减慢速度)

使其运行得更快，多少维护/头痛是值得的？

更新/插入与查询的比率？

等等。

3.一个人可以进行哪些类型的更改？

-如果使用Oracle，请保持最新统计信息！ =)

-Normalization / De-Normalization之一都可以根据表的使用情况来提高性能。我几乎总是规范化，然后只有在我无法以其他实用方式使查询速度更快的情况下，才会规范化。对查询进行非规范化的一种好方法是，在情况允许的情况下，使真实表保持规范化，并使用物化视图创建非规范化的"表"。

-明智地编制索引。在许多层面上太多可能是坏的。只要我们不经常更新列并且该列的基数较低，BitMap索引在Oracle中就非常有用。

-使用索引组织表。

-分区和子分区的表和索引

-使用存储过程来减少应用程序的往返行程，提高安全性并启用查询优化而不会影响用户。

-如果合适的话，将表固定在内存中(访问量非常小)

-索引和表数据库文件之间的设备分区。

.....清单继续。 =)

希望这对我们有帮助。