- 您使用哪些模式来确定频繁查询？
- 如何选择优化因素？
- 人们可以做出哪些类型的改变？
这是一个很好的问题，虽然相当广泛（但也并不更糟）。
如果我理解你的意思，那么你是在问如何从头开始解决优化问题。
首先要问的问题是：“是否存在性能问题？"
如果没有问题，那么就完成了。这种情况经常发生。好的。
另一方面...
确定频繁查询
Logging将为您提供经常查询的信息。
如果您使用某种数据访问层，那么添加代码来记录所有查询可能很简单。
记录查询的执行时间以及每个查询需要多长时间也是一个好主意。这可以让您了解问题出在哪里。
Also, 询问用户哪些部分惹恼了他们。如果缓慢的响应不会让用户烦恼，那就没关系。
选择优化因素？
（我可能误解了问题的这一部分）
您正在寻找查询/响应时间中的任何模式。
这些通常是对大型表的查询或在单个查询中连接多个表的查询。 ...但是如果您记录响应时间，您就可以受到这些时间的指导。
一个人可以做出哪些类型的改变？
您特别询问有关优化表格的问题。
以下是您可以寻找的一些内容：
-
非规范化。这会将多个表合并为一个更宽的表，因此您可以只读取一张表，而不用将多个表连接在一起。这是一种非常常见且强大的技术。注意。我建议保留原始的规范化表并另外构建非规范化表 - 这样，您就不会扔掉任何东西。如何保持最新是另一个问题。您可以在基础表上使用触发器，或定期运行刷新过程。
-
Normalisation. This is not often considered to be an optimisation process, but it is in 2 cases:
- 更新。标准化使更新速度更快，因为每次更新都是最小的（您正在更新最小的 - 就列和行而言 - 可能的表。这几乎是标准化的定义。
- 查询非规范化表以获取存在于小得多（行数更少）的表上的信息可能会导致问题。在这种情况下，存储规范化表和非规范化表（见上文）。
-
水平分区。这意味着通过将一些行放入另一个相同的表中来缩小表。一个常见的用例是将本月的所有行都包含在表中本月销售，以及表中所有较旧的行OldSales，其中两个表具有相同的架构。如果大多数查询都是针对最近的数据，则此策略可能意味着 99% 的查询仅查看 1% 的数据 - 这是一个巨大的性能提升。
-
垂直分区。这是从表中删除字段并将它们放入一个新表中，该新表通过主键连接回主表。这对于非常宽的表（例如具有数十个字段）非常有用，并且如果表填充稀疏，则可能会有所帮助。
-
Indeces。我不确定你的问题是否涵盖这些，但是关于 indeces 的使用还有很多其他答案。查找索引案例的一个好方法是：查找慢速查询。查看查询计划并找到表扫描。对该表上的字段建立索引，以便消除表扫描。如果需要，我可以就此写更多内容 - 发表评论。
你可能还喜欢我的帖子.
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
