WEBVTT

00:00:00.000 --> 00:00:10.560
[音乐]。

00:00:10.560 --> 00:00:12.975
嘿，欢迎来到新
一集数据暴露。

00:00:12.975 --> 00:00:14.460
我叫佩德罗·洛佩斯

00:00:14.460 --> 00:00:16.920
我是
SQL 服务器工程团队。

00:00:16.920 --> 00:00:18.510
今天，我要谈谈

00:00:18.510 --> 00:00:20.670
关于智能
数据库，具体来说，

00:00:20.670 --> 00:00:23.809
智能查询处理
在 SQL Server 2019 中，

00:00:23.809 --> 00:00:25.925
以及 Azure SQL 数据库。

00:00:25.925 --> 00:00:29.390
因此，让我们去它。Sql
服务器 2019 介绍

00:00:29.390 --> 00:00:31.864
突破性查询
性能增强

00:00:31.864 --> 00:00:34.655
他们是智能
查询处理系列。

00:00:34.655 --> 00:00:37.820
这些构成最新的
微软的使命，以确保

00:00:37.820 --> 00:00:41.690
关键并行工作负载
大规模运行时改进，

00:00:41.690 --> 00:00:45.470
同时保持对
不断变化的数据世界，

00:00:45.470 --> 00:00:47.855
当数据移位时，
数据库外。

00:00:47.855 --> 00:00:49.670
在这段视频中，我将给你

00:00:49.670 --> 00:00:51.980
快速概述
智能数据库世界

00:00:51.980 --> 00:00:53.030
这真的需要一个飞跃

00:00:53.030 --> 00:00:56.150
前进与即将到来的
SQL 服务器 2019

00:00:56.150 --> 00:00:58.700
并向您介绍一个数字
我们将潜水的功能

00:00:58.700 --> 00:01:02.130
深入到其他更深
在本系列中的视频。

00:01:03.170 --> 00:01:07.510
智能查询处理
在 SQL Server 中，可通过

00:01:07.510 --> 00:01:11.245
默认在最新数据库上
兼容性级别设置。

00:01:11.245 --> 00:01:13.210
这意味着升级后，

00:01:13.210 --> 00:01:15.130
这可以通过

00:01:15.130 --> 00:01:18.000
翻转开关以使用
最新的兼容性设置。

00:01:18.000 --> 00:01:22.030
智能查询处理
也带来广泛的影响

00:01:22.030 --> 00:01:23.440
提高

00:01:23.440 --> 00:01:26.650
现有工作负载
最小的实施努力。

00:01:26.650 --> 00:01:28.390
这真的意味着大多数时间，

00:01:28.390 --> 00:01:30.965
没有需要
重构代码。

00:01:30.965 --> 00:01:33.310
智能查询处理改进

00:01:33.310 --> 00:01:36.190
关键并行工作负载
当大规模运行时，

00:01:36.190 --> 00:01:39.355
当数据流入 和
从数据库出来，

00:01:39.355 --> 00:01:41.380
我们将适应这一点，

00:01:41.380 --> 00:01:44.660
保持一个级别
可预测的性能。

00:01:44.660 --> 00:01:47.450
例如，通过引入

00:01:47.450 --> 00:01:49.880
反馈机制
到内存使用，

00:01:49.880 --> 00:01:53.630
我们可以确保您的工作量
以可预测的方式执行。

00:01:53.630 --> 00:01:58.190
如果给定的查询执行将
也许占用了太多的记忆

00:01:58.190 --> 00:01:59.750
我们可以纠正它，

00:01:59.750 --> 00:02:02.375
增加并发
数据库的因子。

00:02:02.375 --> 00:02:06.020
如果给定权益执行
没有得到足够的内存和

00:02:06.020 --> 00:02:09.560
最终使用其他 IO
整个被称为溢出，

00:02:09.560 --> 00:02:11.315
然后，我们也能找到，

00:02:11.315 --> 00:02:13.565
并纠正这种情况
使操作

00:02:13.565 --> 00:02:15.260
在内存中执行，

00:02:15.260 --> 00:02:18.200
按预期执行
后续执行。

00:02:18.200 --> 00:02:20.540
此功能现已为

00:02:20.540 --> 00:02:22.835
中的所有执行模式
数据库中心。

00:02:22.835 --> 00:02:27.170
更多数据仓库的批处理模式
和分析工作负载，

00:02:27.170 --> 00:02:31.410
和行模式
关键 OLTP 工作负载。

00:02:31.700 --> 00:02:34.640
我们还进入新的领域

00:02:34.640 --> 00:02:37.220
我们打电话
近似查询处理。

00:02:37.220 --> 00:02:40.640
例如，考虑一个场景
铁路公司在那里

00:02:40.640 --> 00:02:42.350
跟踪的门票数量

00:02:42.350 --> 00:02:44.935
购买和使用
整个铁路系统。

00:02:44.935 --> 00:02:47.030
他们跟踪这个
为了实施

00:02:47.030 --> 00:02:49.730
一些流量控制测量
当需要的时候

00:02:49.730 --> 00:02:52.610
也许通过适应
列车时刻表，

00:02:52.610 --> 00:02:53.630
或列车数量

00:02:53.630 --> 00:02:55.810
系统满足
此刻的需求。

00:02:55.810 --> 00:02:58.920
此信息也是
在仪表板中更新

00:02:58.920 --> 00:03:02.530
在市中心的乡亲
中央可以看看。

00:03:02.530 --> 00:03:04.220
现在，在此方案中，部分

00:03:04.220 --> 00:03:06.830
工作量肯定会
来运行查询

00:03:06.830 --> 00:03:09.020
不断寻找获得

00:03:09.020 --> 00:03:12.005
行计数的所有
出售和使用的门票，

00:03:12.005 --> 00:03:14.600
这可能是
来自一个非常

00:03:14.600 --> 00:03:17.605
大稳定也许与
数十亿和数十亿行。

00:03:17.605 --> 00:03:20.540
现在，这个重复查询
通常会采取

00:03:20.540 --> 00:03:23.735
相当的资源
服务器，即内存。

00:03:23.735 --> 00:03:25.639
如果重复执行，

00:03:25.639 --> 00:03:26.690
可以真正影响

00:03:26.690 --> 00:03:28.900
性能特征
数据库。

00:03:28.900 --> 00:03:30.670
但是，在这种情况下，

00:03:30.670 --> 00:03:32.750
铁路公司
不一定需要

00:03:32.750 --> 00:03:35.830
所有的实际计数
出售和使用的门票。

00:03:35.830 --> 00:03:37.790
但一个非常高的
近似就够了

00:03:37.790 --> 00:03:40.280
触发所有
所需的决策。

00:03:40.280 --> 00:03:42.935
这是近似
计数不同的进来，

00:03:42.935 --> 00:03:45.500
通过允许查询
重复获得

00:03:45.500 --> 00:03:48.185
近似计数
出售和使用的门票

00:03:48.185 --> 00:03:51.080
没有严重影响
数据库性能，

00:03:51.080 --> 00:03:55.420
正常计数查询
将采取今天。

00:03:55.640 --> 00:03:58.695
通过在行存储上启用批处理模式，

00:03:58.695 --> 00:03:59.950
我们有效地释放

00:03:59.950 --> 00:04:02.150
处理模式
特别优化

00:04:02.150 --> 00:04:05.975
用于分析工作负载
数据库上的任何表。

00:04:05.975 --> 00:04:08.180
这意味着，即使
对于

00:04:08.180 --> 00:04:10.385
列存储索引
不会是一个选项，

00:04:10.385 --> 00:04:14.395
数据库引擎仍然可以
以优化的方式执行此工作。

00:04:14.395 --> 00:04:17.375
反过来，这开启了

00:04:17.375 --> 00:04:20.630
自适应联接等功能
由您的工作负载使用。

00:04:20.630 --> 00:04:24.170
自适应联接，仅
在批处理模式下可用可以

00:04:24.170 --> 00:04:28.940
现在被利用所有
表和大部分工作负载。

00:04:29.590 --> 00:04:33.170
我们还处理了一些
最反复出现的反模式

00:04:33.170 --> 00:04:36.260
成为一个问题
托管 SQL Server 工作负载。

00:04:36.260 --> 00:04:38.150
表的使用
变量和使用

00:04:38.150 --> 00:04:40.105
例如，Scalar UF

00:04:40.105 --> 00:04:42.440
现在我们可以解锁新的水平

00:04:42.440 --> 00:04:46.375
查询优化
直到最近才可能。

00:04:46.375 --> 00:04:49.310
所有这一切，我们将
讨论更深和

00:04:49.310 --> 00:04:51.080
演示在即将到来的视频

00:04:51.080 --> 00:04:53.270
关于
智能数据库，

00:04:53.270 --> 00:04:56.020
特别智能
查询处理。

00:04:56.020 --> 00:04:59.505
但是如果你想知道
更多关于今天，

00:04:59.505 --> 00:05:04.200
然后请去这个aka.ms/IQP

00:05:04.200 --> 00:05:06.899
在其中查看所有 URL
文档

00:05:06.899 --> 00:05:09.535
关于智能查询
在 SQL 数据库中处理。

00:05:09.535 --> 00:05:13.100
如果你想尝试一些
这些现在由你自己，

00:05:13.100 --> 00:05:16.040
我们也有演示，
你可以看看，如果你

00:05:16.040 --> 00:05:18.980
转到我们的 GitHub 存储库
和短 URL 会

00:05:18.980 --> 00:05:22.430
aka.ms/IQPDemos，你会

00:05:22.430 --> 00:05:25.900
能够看到所有这些
功能和实验自己。

00:05:25.900 --> 00:05:27.795
所以，再次，小心。

00:05:27.795 --> 00:05:28.980
我马上就跟你谈。

00:05:28.980 --> 00:05:43.780
[音乐]。