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

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

另一方面…

确定频繁查询

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

选择优化因素？

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

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

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

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

您可能还喜欢我在此的帖子。