Question

我们可以获得一系列基本优化技术（从建模到查询，创建索引，视图到查询优化）。有一个列表，每个答案一个技术，这将是很好的。作为业余爱好者，我会发现这非常有用，谢谢。

为了不太模糊，让我们说我们正在使用一个maintstream数据库，如MySQL或Oracle，并且数据库将在~10个表中包含500,000-1m左右的记录，其中一些具有外键约束，所有使用最典型的存储引擎（例如：InnoDB for MySQL）。当然，还有PK等基础知识以及FK约束。

Answer 1

了解索引并正确使用它们。一般来说*，请遵循以下准则：

每个表都应该有一个聚集索引
用于过滤器和排序的字段是索引的理想选择
更多选择性字段是更好的索引编制
为了获得关键查询的最佳性能，请为这些查询设计“覆盖索引”
确保您的索引实际被使用，并删除那些不是
如果你的表有15个字段，并且你创建了15个索引，每个只有一个字段，那你就错了：）

*如果你知道自己在做什么，这些规则有一些例外。我的经验是Microsoft SQL Server，但我认为这些建议大部分仍适用于不同的RDMS。

Answer 2

IMO，到目前为止，最好的优化是使数据模型适合构建它的问题域。如果没有，则产生的症状是难以编写或复杂的查询，以便获得所需的信息，并且在针对数据库构建报告时通常会自行查找。因此，在设计数据库时，有助于了解用户希望从系统中获取的信息的类型和性质，例如报告。

Answer 3

在谈论数据库设计时，请检查数据库规范化，例如：维基百科文章：Normal forms。

如果您的设计很好，但仍需要针对性能进行优化，请尝试Denormalisation。

如果您有特定需求未被关系模型有效覆盖，请查看术语NoSQL涵盖的其他模型。

Answer 4

一些查询/架构优化：

使用DISTINCT或GROUP BY时请注意。我发现很多新开发人员会在不需要它的地方使用DISTINCT，或者可以使用Exists语句或派生查询更有效地重写。
留意左联盟。我经常发现新的SQL开发人员会忽略架构并使用Left Joins，而实际上并不是必需的。例如：

Select
From Orders
    Left Join Customers
        On Customers.Id = Orders.CustomerId

如果Orders.CustomerId是必填列，则无需使用左连接。

成为新功能的学生。目前，MySQL不支持公用表表达式，这意味着某些类型的查询很麻烦，并且写入速度可能比支持CTE时要慢。然而，这永远不会成真。了解MySQL中可能用于提高现有查询效率的新语法功能。
您无需在任何地方使用代理键。可能存在更适合智能密钥的表（例如，美国州缩写，货币代码等），这使得开发人员在许多情况下可以避免额外的连接。
如果可能，找到将数据存档到OLAP或报告服务器的方法。生产数据越小，运行速度就越快。

Answer 5

简洁地模拟您的问题的设计始终是一个良好的开端。过度概括数据模型可能会导致性能问题。例如，我听说有些项目正在努力实现超级灵活性，使用RDBMS作为一个愚蠢的“名称/价值”商店 - 结果表现令人震惊。

一旦有了良好的设计，就可以使用RDBMS提供的工具来帮助它实现良好的性能。单字段PK（无复合），但复合业务密钥作为具有唯一约束的索引，使用适当的数据类型，例如，使用适当的数字类型来表示数值而不是char或类似值。还应考虑运行RDBMS的硬件的物理属性，因为大量的查询时间通常是磁盘I / O--但当然不要认为这是理所当然的 - 使用分析器来查找时间的去向

根据更新/查询比率，物化视图/索引视图可用于提高慢速运行查询的性能。穷人的另一种选择是使用触发器调用一个过程来填充表，其中包含一个运行缓慢，不经常更改的视图。

查询优化有点像黑色艺术，因为它通常依赖于数据库，但这里给出了一些经验法则 - Optimizing SQL。

最后，尽管可能超出了您的问题的预期范围，但在您的应用程序中使用一个良好的数据访问层，并避免自己推出自己的诱惑 - 对于所有主要语言，肯定有经过测试和执行的实现。在数据访问层，中间层和应用程序层使用缓存有助于显着提高性能。

Answer 6

尽可能使用较少查询。使用“JOIN”，并对表进行分组，以便单个查询提供结果。

一个很好的例子是 Modified Preorder Tree Transversal （ MPTT ），以便在单个查询中获取所有树节点父节点。

Answer 7

采用整体方法进行优化。

考虑慢速磁盘，网络延迟，内存不足和服务器负载的影响。

业余爱好者的数据库优化技术

7 个答案: