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

//迁移高版本 SQL
//

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

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

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

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

//正经的问题//

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

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

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

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

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

//新概念 CE
//

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

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

于是，我就 Google 了一把。

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

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

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

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

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

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

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

//结论//

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

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