费老鼻子劲迁移到高版本 SQL 数据库后，性能变差了

//迁移高版本 SQL

//

高版本SQL，一定要迁移吗？

是的，必须的。数据库软件毕竟不是互联网的单体应用，UI一天一变，讨用户的巧。这类商用软件讲究的是稳定，可靠和安全。所以一个大版本的上线，带来的是无数企业客户提出的需求，可以是更好的支持硬件，支持更多的并发，也可以带来更好的优化器。相比成本来说，数据更有价值。

所以很多岗位都为项目迁移而设计。

这两天微信群有个朋友就碰到迁移中遇到的性能问题。非常有意思。还记得我之前怎么看待微信区和交流社区的吗？假如你一个人默默的学习、看书、做实验，始终碰到的困难和问题有限，一旦很多人聚集在一起学习和交流，那么问题就会有一堆。我很庆幸有读者愿意分享自己的经历，这是宝。让我提前接触了我没有遇到过的问题，将来某个时刻我遇到了，嗯，我就可以正经的说三道四了。

//正经的问题//

这位读者遇到的问题是这样的：

公司从SQLServer2012升级2016，升级过程很顺利，并没有太多曲折。但升级完后，打开CrystalReports就贼慢，比以前用SQL2012慢了很多。经分析执行计划，他机智的发现是很多查询都不走索引了。

之前我写过很多文章，都是讲索引失效的处理方法。

可能大家都没有怎么留意。所以这证实了我的一个想法，有些原理必须反复的讲解，从通俗易懂的概念讲起mssql数据库迁移，从案例实战讲起，从简单到复杂，深度剖析本质，才有可能把问题说清楚。否则很多读者朋友看过就是看过而已，并没有太放心上。根据费曼定理，只有7遍以上的重复，才能引起主观意识。而真正掌握，则是要自己动手去实践。

不看之前的文章，你能直接说出如何为优化器指定一个索引去生成执行计划吗？可以留言区写写你的看法。

//新概念 CE

//

我当时给的方案就是通过改写优化器，指定查询重走索引。

当后来仔细一想，有点问题。既然是很大面积的出现了这种问题，肯定是和新的databasecontext有关，即新版本的数据库软件，有某个设置，使得优化器判断失误，致使执行计划低效。

于是，我就Google了一把。

终于有个可疑的设置引起了我的注意。那就是新的数据库优化器组件，CardinalityEstimation,我将它翻译为“笛卡尔估算器”。这是我瞎翻的，并不是官方叫法。这份组件有个很重要的副作用，就是会产生Regression,即优化器生成的执行计划会回退至低效。

首先，我们看下CardinalityEstimation会不会引起执行计划改变？

在判断条件上，使用了不同的数据，导致执行计划更改：

用10来缩小范围和用100来缩小范围，虽然逻辑计划都是InnerJoin,但物理计划却一个是InnerJoin,另一个是HashMatch.这两个物理计划可是有着天然的速度对抗。

当我们点击顶层标签的时候，发现CEMV(CardinalityEstimationModelVersion）是70，如下：

CEMV是SQL2014的新组件，共有120和70两个级别。120是高版本，70是旧版本。而当数据库的compatibility级别是120以上时，120的CEMV才会起作用，如果此时CEMV为70就有可能引起不稳定或者Regression.

此时，我们就要检查数据库的compatibilitylevel了。如果是低于120的，那么CEMV即使120以上都不会起作用，只有70才能正确生成执行计划。

//结论//

这只是我的一个猜测，迁移高版本后，Regression发生了。如果要证实能不能通过修改CardinalityEstimation来解决这问题，还需要这位读者自行测试。

我想这就是集体智慧编程的益处。我们的星球欢迎你，一起探讨SQL以及其他数据栈技术。对，依旧是免费的，就差你的参与！

（编辑：威海站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!