SQL Server中的查询优化技术：数据库设计和体系结构

描述 (Description)

One of the best ways to optimize performance in a database is to design it right the first time! Making design and architecture decisions based on facts and best practices will reduce technical debt and the number of fixes that you need to implement in the future.

优化数据库性能的最佳方法之一是在第一时间进行正确设计！根据事实和最佳实践做出设计和体系结构决策将减少技术负担，并减少将来需要实施的修复程序数量。

While there are often ways to tweak queries, indexes, and server settings to make things faster, there are limits to what we can accomplish in a cost-efficient and timely manner. Those limits are dictated by database architecture and application design. It may often seem that prioritizing good design up-front will cost more than the ability to roll features out quickly, but in the long-run, the price paid for hasty or poorly-thought-out decisions will be higher.

尽管通常可以通过多种方法来调整查询，索引和服务器设置，以加快处理速度，但以经济高效且及时的方式来完成工作却受到了限制。这些限制由数据库体系结构和应用程序设计决定。通常看来，优先考虑良好的设计要比快速部署功能花费更多，但是从长远来看，为草率或考虑周全的决策付出的代价会更高。

This article is a fast-paced dive into the various design considerations that we can make when building new databases, tables, or procedural TSQL. Consider these as ways to improve performance in the long-term by making careful, well thought-out decisions now. Predicting the future of an application may not be easy when we are still nursing it through infancy, but we can consider a variety of tips that will give us a better shot at doing it right the first time!

本文是对构建新数据库，表或过程TSQL时可以进行的各种设计考虑的快速了解。现在考虑通过谨慎，周到的决策将这些方法视为长期改善性能的方法。在婴儿期仍在护理中的情况下，预测应用程序的未来可能并不容易，但是我们可以考虑各种技巧，这些技巧可以让我们在第一时间正确地进行操作！

“Measure twice, cut once” applies to application development in that regard. We need to accept that doing it right the first time will be significantly cheaper and less time-consuming than needing to rearchitect in the future.

在这方面，“两次测量，一次剪切”适用于应用程序开发。我们需要接受的是，与将来重新配置相比，第一次正确执行将大大便宜且耗时更少。

了解应用 (Understand the application)

Learn the business need behind the application and its database. In addition to a basic understanding of what an app will do, consider the following questions:

了解应用程序及其数据库背后的业务需求。除了对应用程序的功能有基本了解之外，请考虑以下问题：

What is it used for? What is the app and its purpose? What kind of data will be involved? 它是干什么用的？该应用程序及其用途是什么？将涉及哪种数据？
Who will access it? Will it be end-users on the web or internal employees? Will it be 5 people, 5,000 people or 5 million people? 谁将访问它？是网络上的最终用户还是内部员工？是5个人，5,000个人还是500万人？
How will they access it? Will it be a web page? Mobile app? Local software on a computer or private cloud? A reporting interface? 他们将如何访问它？会是网页吗？移动应用？计算机或私有云上的本地软件？报告界面？
Are there specific times of day when usage is heavier? Do we need to accommodate busy times with extra resources? Will quiet times allow for planned maintenance or downtime? What sort of uptime is expected? 有一天的特定时段使用量更大吗？我们需要额外的资源来适应繁忙的时间吗？安静的时间是否可以按计划进行维护或停机？预计什么样的正常运行时间？

Getting a basic idea of the purpose of a database will allow you to better forecast its future and avoid making any major mistakes in the beginning. If we know about application quirks, such as busy or quiet times, the use of ORMs, or the use of an API, we can better understand how it will interact with the database and make decisions to accommodate that usage.

了解数据库用途的基本概念将使您能够更好地预测数据库的未来，并避免在开始时犯任何重大错误。如果我们了解应用程序的怪癖，例如繁忙或安静的时间，ORM的使用或API的使用，我们将更好地了解它如何与数据库交互并做出适应该用法的决策。

Often, a good understanding of the app allows us to make simplifying assumptions and cut through a lot of the decisions we need to make. This conversation may involve both technical folks (architects, developers, engineers, and other DBAs) or it may involve business reps that have a strong understanding of the purpose of the app, even if they may not know much about the technical implementation of it.

通常，对应用程序有一个很好的了解，可以使我们做出简化的假设并简化许多需要做出的决定。这种对话可能涉及技术人员（架构师，开发人员，工程师和其他DBA），也可能涉及对应用程序用途有深刻理解的业务代表，即使他们可能不太了解应用程序的技术实现。

Here are some more details on the questions and considerations we should make when designing new database objects:

以下是有关在设计新数据库对象时应考虑的问题和注意事项的更多详细信息：

可扩展性 (Scalability)

How will the application and its data grow over time? The ways we build, maintain, and query data change when we know the volume will be huge. Very often we build and test code in very controlled dev/QA environments in which the data flow does not mirror a real production environment. Even without this, we should be able to estimate how much an app will be used and what the most common needs will be.

随着时间的流逝，应用程序及其数据将如何增长？当我们知道数据量将会很大时，我们构建，维护和查询数据的方式就会改变。通常，我们在受严格控制的dev / QA环境中构建和测试代码，在该环境中数据流不会反映真实的生产环境。即使没有这个，我们也应该能够估计将使用多少应用程序以及最常见的需求是什么。

We can then infer metrics such as database size, memory needs, CPU, and throughput. We want the hardware that we put our databases on to be able to perform adequately and this requires us to allocate enough computing resources to make this happen. A 10TB database will likely not perform well (or at all) on a server with 2GB of RAM available to it. Similarly, a high-traffic application may require faster throughput on the network and storage infrastructure, in addition to speedy SSDs. A database will only perform as quickly as its slowest component, and it is up to us to make sure that the slowest component is fast enough for our app.

然后，我们可以推断指标，例如数据库大小，内存需求，CPU和吞吐量。我们希望我们放置数据库的硬件能够充分发挥作用，这需要我们分配足够的计算资源来实现这一目标。 10TB数据库在具有2GB RAM的服务器上可能无法很好（或根本无法）运行。同样，高流量的应用程序除了需要快速的SSD之外，还可能需要在网络和存储基础结构上具有更快的吞吐量。数据库的运行速度仅与最慢的组件一样快，我们需要确保最慢的组件对我们的应用程序足够快。

How will data size grow over time? Can we easily expand storage and memory easily when needed? If downtime is not an option, then we will need to consider hardware configurations that will either provide a ton of extra overhead to start or allow for seamless expansions later on. If we are not certain of data growth, do we expect the user or customer count to grow? If so, we may be able to infer data or usage growth based on this.

数据大小将如何随着时间增长？是否可以在需要时轻松轻松地扩展存储和内存？如果不能选择停机，那么我们将需要考虑硬件配置，这些配置将提供大量额外的启动费用，或者允许以后进行无缝扩展。如果我们不确定数据的增长，那么我们期望用户或客户数量会增长吗？如果是这样，我们也许可以据此推断数据或使用量的增长。

Licensing matters, too as licensing database software isn’t cheap. We should consider what edition of SQL Server will function on and what the least expensive edition is that we are allowed to use. A completely internal server with no customer-facing customer access may be able to benefit from using Developer edition. Alternatively, the choice between Enterprise and Standard may be decided by features (such as AlwaysOn) or capacity (memory limitations, for example). A link is provided at the end of this article with extensive comparisons between editions of SQL Server.

许可也很重要，因为许可数据库软件并不便宜。我们应考虑将在哪个版本SQL Server上运行以及允许使用的最便宜版本。没有面向客户的客户访问权限的完全内部服务器可能会从使用Developer Edition中受益。或者，企业和标准之间的选择可以由功能（例如AlwaysOn）或容量（例如内存限制）决定。本文结尾处提供了一个链接，其中包含SQL Server版本之间的广泛比较。

High availability and disaster recovery are very important considerations early-on that often are not visited until it is too late. What is the expected up-time of the app? How quickly are we expected to recover from an outage (recovery time objective/RTO)? In addition, how much data loss is tolerated in the event of an outage or disaster (recovery point objective,/RPO)? These are tough questions as businesses will often ask for a guarantee of zero downtime and no data loss, but will back off when they realize the cost to do so is astronomically high. This discussion is very important to have prior to an application being released as it ensures that contracts, terms of service, and other documentation accurately reflect the technical capabilities of the systems it resides on. It also allows you to plan ahead with disaster recovery plans and avoid the panic often associated with unexpected outages.

高可用性和灾难恢复是非常重要的考虑因素，通常要等到太晚才进行访问。该应用程序的预期正常运行时间是多少？我们期望从中断中恢复的速度有多快（恢复时间目标/ RTO）？此外，如果发生中断或灾难（恢复点目标，/ RPO），可以容忍多少数据丢失？这些难题是棘手的，因为企业通常要求保证零停机时间且没有数据丢失，但是当他们意识到这样做的成本天文数字很高时，就会退缩。在发布应用程序之前进行此讨论非常重要，因为它可以确保合同，服务条款和其他文档准确反映其所驻留的系统的技术能力。它还使您可以提前计划灾难恢复计划，并避免经常因意外中断而引起的恐慌。

资料类型 (Data types)

One of the most basic decisions that we can make when designing a database is to choose the right data types. Good choices can improve performance and maintainability. Poor choices will make work for us in the future