设为首页 收藏本站
查看: 880|回复: 0

[经验分享] [心得] SQL Server Partition(表分區) 資料分佈探討

[复制链接]

尚未签到

发表于 2017-7-13 06:29:16 | 显示全部楼层 |阅读模式
  最近在群裡有個朋友問了個問題是這樣的
  用户表有一千多万行,主键是用户ID,我做了分区。但经常查询时,其它的表根据用户ID来关联,这样跨区查询,reads非常高。有什么好的处理办法?不分区的话,索引维护要好久的时间
  在查看了他提供的分區資訊後,發現只有23個分區(包含一定要有的Null分區)
DSC0000.png

  Null分區在這裡的定義其實很簡單,當你的資料沒有辦法放到你先前建立的分區時,就會將該資料放到所謂的Null分區(預設分區)。
  因此如果在探尋分區規則時沒有依照現有的資料進行分區的設計,將會很容易導致資料偏斜(Data Bias),一但資料出現了偏斜時在查找時就會很容易在NULL區出現過多的讀取
  以今天的案例來看待,當要比對的ID不在這22個分區中時就會到NULL分區進行查找的動作。而在群友提供的資料中其實有出現了oGpI0w_ 、mGpI0w等字眼
  可以想見的是,該NULL分區的資料是相當多的
  以下就一個測試情境來探討在分區規則不同時的效能比較
  首先建立二張結構一樣的表,資料量約一千二百萬筆
DSC0001.png

  接下來分別建立給表Demo1與Demo2的表分區函數(請注意圖中的註解)
(注意,以下示範並沒有利用到分區FileGroup優化,當你用了分區時請一定要同時利用FileGroup進行優化)

  一個是利用UserID前五碼分區另一個則利用前一碼進行分區
  這裡要注意的是SQL Server 2016一個資料表或索引最多可以有 15,000 個資料分割
  SQL Server 2005 與 2008 則需為SP2才可使用 (否則只能合計有1000個分區)
  Refer : New Limit for Number of Partitions in SQL Server 2008 SP2
DSC0002.png

Demo1表分區函數

DSC0003.png

Demo2表分區函數

  而在表中不重複前五碼的資料筆數約9百多萬,如下圖
(可以想見的是在NULL區中會有大量的資料存放)
DSC0004.png

  接下來我們來看看分區後的Demo1與Demo2分區表資料分佈情形
   DSC0005.png
Demo1表分區資料分佈

DSC0006.png

DSC0007.png

Demo2表分區資料分佈

案例:當利用LIKE做前綴查找

這裡從前述的資訊可以知道在Demo1 a0%最少有6個區需要查找

而Demo2只有一個區需要查找

接下來我們先簡單的看一下兩張表在相同查詢時IO的差異 (可以看到第二張表較優)

DSC0008.png

接下來我們仔細看一下相關的執行計畫與查找的分區數
可以發現在執行時Demo1會查找七個分區,而Demo2只會從一個分區中進行查找

DSC0009.png

案例:當從預設分區查找

這次我們簡單的查找z開頭的UserID ,從先前的資訊可以知道。

表Demo1並沒有建立z開頭的分區,因此z相關的資料將會存放到預設分區(Null區)

表Demo1的預設分區統計約有643萬筆,而表Demo2的z分區約有45萬筆

由此可見在Demo2表上查找應該會優於Demo1的(當資料筆數再更多時,差異會更大)
見下圖

DSC00010.png

以上便是今天的表分區探討,替各位總結一下。

1.在規劃表分區時,首先要注意該表的相關查詢語句,以最常用在條件式的字段做為分區依據是較佳的。

2.承上,即使使用最常用的字段做為分區依據,仍然要確認資料是否適合做為分區。

例如:即使常用的查詢字段為姓別 (男、女),用此字段做為分區,僅能將資料最多分為三個區。在大資料時,性能並無法顯著的增加。簡單的評估可以用目前的資料筆數除以分區數,可得知每個分區的資料分佈進而做分區建立的評估依據

比如可以用下列這種簡單的語法計算每個分區數





SELECT COUNT(1) /
(
SELECT COUNT(1) FROM
(
SELECT 1 as Counts FROM Demo1 GROUP BY SUBSTRING(UserID,1,1)
) as X
)
FROM Demo1
  後記
在寫本篇時,還發現了一個需要注意的問題,當利用VARCHAR字段做為分區依據時。

在查詢時需要在該字段使用 LIKE 而不是一般的Equal (=)做為查找。
如果採用一般的Equal(=)做為查找時,該執行計畫會顯示查找了所有分區內容
具體原因如果有朋友知道,還請協助解答。

以下是查找的比較圖

DSC00011.png

使用Equal(=)查找

DSC00012.png

使用LIKE查找

本次用來查詢表分區相關資訊的語法




SELECT t.name AS TableName, i.name AS IndexName, p.partition_number,
p.partition_id, i.data_space_id, f.function_id, f.type_desc,
r.boundary_id, r.value AS BoundaryValue,p.rows
FROM sys.tables AS t  
JOIN sys.indexes AS i  
ON t.object_id = i.object_id  
JOIN sys.partitions AS p  
ON i.object_id = p.object_id AND i.index_id = p.index_id  
JOIN sys.partition_schemes AS s  
ON i.data_space_id = s.data_space_id  
JOIN sys.partition_functions AS f  
ON s.function_id = f.function_id  
LEFT JOIN sys.partition_range_values AS r  
ON f.function_id = r.function_id and r.boundary_id = p.partition_number  
WHERE t.name = '已分區表名稱' AND i.type <= 1  
ORDER BY p.partition_number;
  最後謝謝各位觀看囉!如果有問題歡迎在底下留言與我討論

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-393325-1-1.html 上篇帖子: SQL SERVER大话存储结构(4)_复合索引与包含索引 下篇帖子: SQL Server数据库(时间戳timestamp)类型
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表