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
[音樂]。