sql查询非11位非数字

It is a common misconception that you need real production data, or production like data, to effectively tune queries in SQL Server. I am going to explain how you can compile the same execution plans as what your production environment would compile, so that you can tune them in a non-production environment, gaining these benefits.

一个普遍的误解是，您需要真实的生产数据或类似生产的数据来有效地调优SQL Server中的查询。 我将解释如何编译与生产环境将编译的执行计划相同的执行计划，以便您可以在非生产环境中对其进行调整，从而获得这些好处。

• Keep sensitive data in production, such as personally identifiable information (PII). 在生产中保留敏感数据，例如个人身份信息（PII）。
• Save space by not duplicating any of the production data in lower environments. 通过在较低的环境中不复制任何生产数据来节省空间。
• Save server resources by keeping development machines small. 通过使开发机器保持较小规模来节省服务器资源。
• Speed up development machine provisioning by restoring smaller databases. 通过还原较小的数据库来加快开发计算机的配置。

Methods for tuning the execution plans is out of scope for this post. This post covers the configuration of your non-production server and cloning of your production databases.

调整执行计划的方法超出了本文的范围。 这篇文章介绍了非生产服务器的配置和生产数据库的克隆。

何时使用哪种方法 (Which method to use and when)

A lot of common tuning methodologies rely upon resource usages such as physical/logical reads/writes and elapsed time. There is a lot of validity to those methods. This post is going to focus on a different way of tuning but I am not putting down the usage based methods nor am I offering you an improvement or replacement. There are a time and a place for both tuning methods.

许多常见的调整方法依赖于资源使用，例如物理/逻辑读/写和经过的时间。 这些方法有很多有效性。 这篇文章将专注于另一种调优方式，但我不会放弃基于使用情况的方法，也不会为您提供改进或替换。 两种调整方法都有时间和地点。

Usage based tuning methods, which require that you execute the queries and measure their behavior, are best suited to a staging environment. A staging environment would be locked down to a similar degree as your production environment and would be refreshed regularly with actual production data. I have seen many IT shops handle this by restoring last night’s production backup to the staging environment each morning.

基于使用情况的调优方法要求您执行查询并衡量其行为，因此最适合登台环境。 暂存环境将被锁定到与您的生产环境类似的程度，并且会定期使用实际生产数据进行刷新。 我已经看到许多IT商店通过每天早晨将昨晚的生产备份恢复到暂存环境来解决此问题。

I advocate that 80% of your query performance problems can be dealt with from the execution plan alone. Execution plan tuning can be and should be, accomplished as far left as your development environment. Execution plans compiled in the development environment are usually very different than the ones generated in the production environment. This is the problem that will be solved in this post.

我主张仅通过执行计划就可以解决80％的查询性能问题。 执行计划调整可以而且应该在您的开发环境中完成。 在开发环境中编译的执行计划通常与在生产环境中生成的执行计划有很大不同。 这是本文将要解决的问题。

伪装您的硬件 (Faking out your hardware)

The first step in spoofing the production environment is to convince the query optimizer that the hardware you are working with in development is equivalent to the hardware that you have in production. To do that, use DBCC OPTIMIZER_WHATIF.

欺骗生产环境的第一步是使查询优化器确信您在开发中使用的硬件与生产中使用的硬件等效。 为此，请使用DBCC OPTIMIZER_WHATIF。

DBCC OPTIMIZER_WHATIF is an undocumented DBCC command which tells a single session to act as if the machine running SQL Server has different physical or virtual properties. It is session scoped, which is great. It means that you can have several different developers working on the same development server while spoofing different hardware. This becomes useful when consolidating the execution plan tuning onto a multi-tenanted development server. I will talk more about this in the next section.

DBCC OPTIMIZER_WHATIF是未记录的DBCC命令，该命令告诉单个会话以运行SQL Server的计算机具有不同的物理或虚拟属性的方式进行操作。 它是会话范围的，很棒。 这意味着您可以在欺骗不同硬件的同时让多个不同的开发人员在同一个开发服务器上工作。 当将执行计划调整整合到多租户开发服务器上时，这将变得很有用。 我将在下一节中进一步讨论这一点。

How it works

这个怎么运作

-- TF to enable help to undocumented commands
DBCC TRACEON (2588) WITH NO_INFOMSGS
-- DBCC help
DBCC HELP ('OPTIMIZER_WHATIF') WITH NO_INFOMSGS
dbcc OPTIMIZER_WHATIF ({property/cost_number | property_name} [, {integer_value | string_value} ])

By using trace flag 2588 and DBCC HELP, the syntax of the undocumented command can be viewed. DBCC OPTIMIZER_WHATIF accepts a simple key / value pair as parameters.

通过使用跟踪标志2588和DBCC HELP ，可以查看未记录命令的语法。 DBCC OPTIMIZER_WHATIF接受简单的键/值对作为参数。

-- TF to send output results to console
DBCC TRACEON(3604) WITH NO_INFOMSGS
-- Current and valid values
DBCC OPTIMIZER_WHATIF(0) WITH NO_INFOMSGS;

Using trace flag 3604 and passing in 0 as the only parameter into DBCC OPTIMIZER_WHATIF displays the possible keys and current values.

使用跟踪标志3604并将0作为唯一参数传入DBCC OPTIMIZER_WHATIF，将显示可能的键和当前值。

The three parameters that are most important are; CPUs, MemoryMBs, and Bits. As you can imagine, CPUs sets the number of cores that SQL Server believes it has and MemoryMBs sets the perceived memory. Bits sets the platform to 32 or 64 bit but this option is likely going to become less relevant as time goes on and 32-bit SQL Servers fall out of existence.

最重要的三个参数是： CPU，MemoryMB和位。 可以想象，CPU设置SQL Server认为拥有的内核数，而MemoryMB设置感知的内存。 位将平台设置为32位或64位，但是随着时间的流逝和32位SQL Server的消失，该选项的相关性可能会降低。

There are some functional examples of the impact of DBCC OPTIMIZER_WHATIF on an execution plan in this article.

还有的DBCC OPTIMIZER_WHATIF对执行计划的影响，一些功能性的例子这篇文章 。

What to expect

期待什么

Spoofing the hardware is the first half of the battle. These settings directly impact the decisions that the query optimizer makes during compilation. The CPUs option will impact the query’s potential for parallelism. When a plan is compiled, the optimizer only chooses whether the plan will be parallel or not. It does not determine the number of cores which will be used, that occurs at runtime. This means that the CPUs parameter is only important when one server has only a single core and the other has multiple cores. If both already have two or more cores, then a parallel plan will be an option in both cases.

欺骗硬件是战斗的前半部分。 这些设置直接影响查询优化器在编译过程中做出的决策。 CPUs选项将影响查询的并行性。 编译计划时，优化器仅选择计划是否并行 。 它不能确定运行时发生的内核数量。 这意味着，仅当一台服务器只有一个内核而另一台服务器有多个内核时，CPUs参数才重要。 如果两者都已经有两个或多个核心，则在两种情况下都可以选择并行计划。

The MemoryMBs option, has a much larger impact on the execution plan generated. This option impacts the size of the memory grants available in the execution plan which, in turn, affects the use of operators such as table spools.

MemoryMBs选项对生成的执行计划有更大的影响。 此选项影响执行计划中可用的内存授予的大小，进而影响表假脱机等运算符的使用。

伪造优化器 (Faking out the optimizer)

The second, and most important, step is to fake out the optimizer. This is accomplished by matching the database schema to the production environment and pulling down all the statistics from production into the development environment. The optimizer uses these two components to make the decisions necessary during execution plan compilation.

第二个也是最重要的一步是伪造优化器。 这是通过将数据库模式与生产环境进行匹配并将所有统计信息从生产中拉到开发环境中来完成的。 优化器使用这两个组件在执行计划编译期间做出必要的决策。

Schema and statistics

模式和统计

Matching the schema between the production database and the development database is important for comparing apples to apples. There are many objects which impact the query plans outside of the table structure itself. Indexes are, of course, very important but also options and objects such as SCHEMABINDING and FOREIGN KEYs have a significant impact on the plan generated.

在生产数据库和开发数据库之间匹配模式对于比较苹果与苹果很重要。 有许多对象会影响表结构本身之外的查询计划。 当然， 索引非常重要，但是选项和对象（例如SCHEMABINDING和FOREIGN KEY）也对生成的计划产生重大影响。

Naturally, it is important to tune queries after the schema has been changed but before the change is released into production. With that being said, for new development, you want to tune the state production will be in when you release, not the current state. Drift from the production schema is acceptable, assuming it was intentional.

自然，在更改模式之后但将更改发布到生产环境之前，对查询进行调优很重要。 话虽如此，对于新开发，您想要调整发布时的状态生产，而不是当前状态。 假设是有意的，则可以从生产模式中漂移。

The production statistics are the truly critical pieces of the puzzle, however. SQL Server statistics are comprised of the statistics header, density vector, and the histogram. DBCC SHOW_STATISTICS is used to display the details of a statistic.

然而，生产统计数据确实是难题的关键部分。 SQL Server统计信息由统计信息头，密度向量和直方图组成。 DBCC SHOW_STATISTICS用于显示统计信息的详细信息。

When an execution plan is compiled, information from the statistics from each table and/or index involved in the query is used, such as the row counts from the statistics header, the selectivity information from the density vector, and bucketized statistics from the histogram.

编译执行计划时，将使用来自查询所涉及的每个表和/或索引的统计信息，例如统计头中的行数，密度矢量中的选择性信息以及直方图中的存储统计。

DBCC CLONEDATABASE

DBCC CLONEDATABASE

The entire database schema, with all of the statistics, can be scripted out using the SQL Server Management Studio Generate Script Wizard. A simpler, and my preferred, method for creating an exact copy of the database, but without any data, is to use DBCC CLONEDATABASE.

可以使用SQL Server Management Studio 生成脚本向导编写包含所有统计信息的整个数据库架构。 创建数据库的精确副本但不包含任何数据的一种更简单（也是我的首选）的方法是使用DBCC CLONEDATABASE 。

USE Master
DBCC CLONEDATABASE ('AdventureWorks2014','AdventureWorks2014_clone')

DBCC CLONEDATABASE will generate a clone of the database and place it on the same instance with a different name.

DBCC CLONEDATABASE将生成数据库的克隆，并将其放置在具有不同名称的相同实例上。

DBCC CLONEDATABASE was first released in SQL Server 2014 SP2 and SQL Server 2016 SP1.

DBCC CLONEDATABASE最初在SQL Server 2014 SP2和SQL Server 2016 SP1中发布。

This clone will be in READ_ONLY mode by default. READ_ONLY mode protects the production statistics from being updated or deleted but prevents new indexes being created to test out different tuning scenarios and prevents you from deploying schema changes to be tuned. For that reason, I prefer to set the database back into READ_WRITE mode and disable AUTO_UPDATE_STATISTICS.

默认情况下，此克隆将处于READ_ONLY模式。 READ_ONLY模式可保护生产统计信息不被更新或删除，但可防止创建新索引来测试不同的调整方案，并防止您部署要调整的架构更改。 因此，我更愿意将数据库设置回READ_WRITE模式并禁用AUTO_UPDATE_STATISTICS。

ALTER DATABASE AdventureWorks2014_clone SET READ_WRITE
ALTER DATABASE AdventureWorks2014_clone SET AUTO_UPDATE_STATISTICS OFF

Once the database is in the desired state, backup it up and restore it to the development server. Since there are minimal resources required to compile execution plans, and the databases do not contain any data. It is convenient to maintain a single development server, with minimal resources, where many production clones can be stock piled for tuning. This would be an efficient means of server consolidation.

数据库处于所需状态后，请对其进行备份并将其还原到开发服务器。 由于编译执行计划所需的资源最少，并且数据库不包含任何数据。 使用最少的资源维护单个开发服务器很方便，可以在其中堆叠许多生产克隆以进行调整。 这将是服务器整合的有效方法。

汇集全部 (Bringing it all together)

With a cloned copy of the production database and access to DBCC OPTIMIZER_WHATIF, any query can be compiled by retrieving the estimated execution plan or running the query while collecting the actual execution plan.

使用生产数据库的克隆副本并访问DBCC OPTIMIZER_WHATIF，可以通过检索估计的执行计划或在收集实际执行计划的同时运行查询来编译任何查询。

The plan, retrieved in this manner, will be identical to the plan which would have been or has been generated in the production environment. At this point, begin execution plan tuning. Query modifications can be tested by generating a new plan. Confidence can be had that the new plan generated will be the same once the query modifications are deployed into the production environment.

以这种方式检索的计划将与在生产环境中已经或已经生成的计划相同。 此时，开始执行计划调整。 可以通过生成新计划来测试查询修改。 一旦将查询修改部署到生产环境中，就可以确信生成的新计划将是相同的。

Caveats and limitations

注意事项和限制

As mentioned above, this method can surface about 80% of your query problems. Resource based tuning is still important in a production-like environment because of the below factors.

如上所述，此方法可以解决大约80％的查询问题。 由于以下因素，基于资源的调整在类生产环境中仍然很重要。

• New tables and indexes have not yet existed in production yet. Therefore, there are no production statistics to copy down and tune based on. 新表和索引尚未在生产中存在。 因此，没有要复制和调整的生产统计信息。
• Modifying an existing index will invalidate the statistics which makes tuning it the same as a new index. 修改现有索引将使统计信息无效，这将使其与新索引相同。
• Locking, blocking, and other concurrency factors are not in play with this method since no query is actually being executed. 由于实际上没有执行任何查询，因此锁定，阻塞和其他并发因素没有作用。

翻译自: https://www.sqlshack.com/sql-query-performance-tuning-tips-non-production-environments/

sql查询非11位非数字