8
  1. 您用来确定频繁查询的模式是什么？
  2. 如何选择优化因子？
  3. 可以进行哪些类型的更改？
4

9 回答 9

12

这是一个很好的问题，如果相当广泛（并且没有更糟）。
如果我理解你，那么你问的是如何从头开始解决优化问题。

第一个要问的问题是：“有性能问题吗？ ”
如果没有问题，那么你就完成了。这种情况经常发生。好的。

另一方面...

确定频繁查询

日志记录将为您提供频繁的查询。
如果您使用某种数据访问层，那么添加代码来记录所有查询可能很简单。
记录查询的执行时间以及每个查询需要多长时间也是一个好主意。这可以让您了解问题所在。
另外，询问用户哪些位让他们烦恼。如果缓慢的响应不会惹恼用户，那么没关系。

选择优化因素？

（我可能误解了这部分问题）您正在寻找查询/响应时间中的任何模式。
这些通常是对大型表的查询或在单个查询中连接多个表的查询。...但是如果您记录响应时间，则可以按照这些时间进行指导。

可以做出哪些改变？

您专门询问优化表。
以下是您可以查找的一些内容：

  • 非规范化。这将几个表合并到一个更宽的表中，因此您不必将多个表连接在一起，而只需读取一个表即可。这是一种非常常见且功能强大的技术。注意。我建议保留原始规范化表并另外构建非规范化表 - 这样，您就不会丢弃任何东西。如何保持最新是另一个问题。您可以在基础表上使用触发器，或者定期运行刷新过程。
  • 归一化。这通常不被认为是一个优化过程，但有两种情况：
    • 更新。规范化使更新更快，因为每次更新都是最小的（您正在更新最小的 - 就列和行而言 - 可能的表。这几乎是规范化的定义。
    • 查询非规范化表以获取存在于更小（更少行）表上的信息可能会导致问题。在这种情况下，存储规范化的表以及非规范化的表（见上文）。
  • 水平分区。这意味着通过将一些行放在另一个相同的表中来使表更小。一个常见的用例是在表 ThisMonthSales 中包含本月的所有行，在表OldSales中包含所有较旧的行，其中两个表具有相同的架构。如果大多数查询是针对最近的数据，则此策略可能意味着 99% 的所有查询只查看 1% 的数据 - 巨大的性能优势。
  • 垂直分区。这是从表中切出字段并将它们放入一个新表中，该表通过主键连接回主表。这对于非常宽的表（例如，有几十个字段）很有用，并且如果表中填充的内容很少，可能会有所帮助。
  • 下降。我不确定您的问题是否涵盖这些，但是关于使用 indeces 的 SO 还有很多其他答案。为索引查找案例的一个好方法是：查找慢查询。查看查询计划并找到表扫描。该表上的索引字段，以便删除表扫描。如果需要，我可以写更多关于这个 - 发表评论。

你可能也喜欢我在这方面的帖子。

于 2008-09-26T11:48:17.267 回答
1

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

如果我们谈论的是 SQL Server：

  1. 使用动态管理视图。使用 SQL 事件探查器。安装 SP2 和性能仪表板报告。
  2. 在确定最昂贵的查询（即运行次数 x 一次查询成本）之后，检查它们的执行计划，并查看所涉及的表的大小，以及它们主要是读取还是写入，或两者兼而有之。
  3. 如果系统在您的完全控制之下（应用程序和数据库），您通常可以重写格式错误的查询（很常见），例如通常可以重写为派生表连接的深度相关子查询稍加思考。否则，您可以选择创建覆盖非聚集索引并确保统计信息保持最新。
于 2008-09-26T01:16:23.317 回答
1

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

例如，在 Oracle 中，企业管理器可以让您查看哪些查询占用的时间最多，让您比较不同的执行配置文件，并让您分析一段时间内的查询，这样您就不会添加有用的索引一个查询以您运行的所有其他查询为代价。

于 2008-09-26T01:17:27.840 回答
0
  1. 对于 MySQL，有一个称为日志慢查询的功能

其余的取决于您拥有的数据类型及其设置方式。

于 2008-09-26T01:20:29.843 回答
0

在 SQL Server 中，您可以使用跟踪来了解查询的执行情况。使用 ctrl + k 或 l

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

一个更具体的问题肯定会给你更好的答案。

于 2008-09-26T01:48:24.067 回答
0

如果您的表主要被读取，请在表上放置一个聚集索引。

于 2008-09-26T01:50:43.640 回答
0

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

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

例如，如果您有一个包含两列（日期和磁盘使用）的表 (x)，并且只有一个日期索引，则查询：

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

将非常有效，因为它可以使用索引。另一方面，查询

select date from x where diskusage > 90

不会那么高效。在前一种情况下，“解释计划”会告诉您它可以使用索引。在后者中，它会说它必须进行表扫描才能获取行（这基本上是查看每一行以查看它是否匹配）。

真正智能的 DBMS 还可以解释您应该如何提高性能（在这种情况下，在磁盘使用情况上添加索引）。

至于如何查看正在运行的查询，您可以从 DBMS 收集（如果允许的话）或强制每个人通过存储过程进行查询，以便 DBA 控制查询是什么 - 这是他们的工作，保持数据库高效运行。

于 2008-09-26T01:53:41.043 回答
0

PK 和 FK 上的索引以及总是有助于分区的一件事......

于 2008-09-26T11:57:38.943 回答
0

1.您使用什么模式来确定频繁查询？

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

2.如何选择优化因子？

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

它会被大量更新吗？更新发生在哪些领域？它有低基数的列吗？

值得索引吗？（如果通过索引访问非常小的表可能会减慢速度）

让它运行得更快值得多少维护/头痛？

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

等等

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

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

-- Normalization/De-Normalization 中的任何一个都可以根据表的使用情况来提高性能。我几乎总是规范化，然后只有当我无法以其他实际方式使查询更快时才会去规范化。对查询进行非规范化以及在您的情况允许时保持真实表规范化并创建具有物化视图的非规范化“表”的好方法。

——明智地索引。太多可能在许多层面上都不好。只要您不经常更新列并且该列的基数较低，位图索引在 Oracle 中就很棒。

-- 使用索引组织的表格。

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

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

-- 如果合适，将表固定在内存中（访问很多且相当小）

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

.....名单还在继续。=)

希望这对你有帮助。

于 2008-09-27T05:41:24.300 回答