艾銻知識 |Sql Server的一些知識點定義總結

2020-03-11 20:24 作者：admin 瀏覽量：

 
在過去的一個多月,中國是世界最大的疫情受災區,受感染的人數和死亡人數是2003年非典的10多倍,這個數據讓全世界震驚,但好在中國的領導者當即立刻,做出了ALL IN的行動,全力以赴的處理這一件事,當舉國上下,所有人的意識,焦點,能量全都聚焦處理這一件事的時候,很快這種靠空氣就能傳播的新型冠狀病毒得到了很好的控制.
 
近期中國受感染的人數在持續下降,很多地區連續數日新增為零,但萬萬沒想到中國鄰近的一些國家有些人被感染,同時這些國家的領導人沒有能快速反應,導致這幾天在世界迅速的傳播開來,從幾個人擴展到了近萬人的規模,本來只有一兩個國家,但因為人數短時間的增長和流動,現在已經在34個國家和地區傳播開來,這將導致整個世界的經濟降速和減緩,美國硅谷的全球最著名的互聯網公司全部放假在家辦公, 好萊塢的電影業也全部暫停,還有更多的行業在陸陸續續的停止中,這場全球性的疫情將會為世界的經濟帶來巨大的挑戰.
中國從剛開始的疫情輸出國將很快變成疫情的輸入國,所以我們接下來面臨的是更多的封閉性的政策,不然疫情就很難被徹底的控制,前幾天北京新增長的幾個人全是從國外回來的,如果每個國家都開始封閉,都開始停止商業的運作,經濟就會快速下滑,當世界的經濟受到嚴重影響時,中國作為世界第二大經濟體,自然也會受到重創.
 
受到最大影響的出口,中國向外出口主要有：
1．農產品：以水產品、蔬菜、水果、花卉．畜產品、糧食和食用油籽等為主。
2．通信產品：電子信息與通信技術領域
3．鋼鐵：焦炭．鋼坯．鐵合金．鋼絲及制品等。
4．陶瓷
5．機電
6．服裝．紡織品
7．冶金原料
8．我國高新技術產品出口最多的4 類技術領域是計算機與通信技術、電子技術、生命科學技術、光電技術。
9．汽車零部件
10．能源產品：煤
這些行業是中國的主體行業,有上億的勞動者都在這些行業中,如果產能下降,直接導致的就是員工失業的問題,這將是我們急切需要思考的,如何幫助全球快速控制疫情的擴展,把我們的經驗分享給這些疫情增長比較快的國家,從而讓全球開始互幫互助.
 
只有全球疫情消失,世界的經濟才能真正的恢復,鐘南山院士說,全球疫情結束可能要到六月,其實他說的非常保守,只有全球所有國家像中國一樣ALL IN 來處理這件事,才有可能六月結束全球疫情,如果不是這樣的話,今年也結束不了,因為它的傳播速度太快了,而且這種病毒它是一種細胞生命體,有生命體的細胞就具備變異的能力,一旦變異將會更難處理.
   
為什么中國能控制的這么好,大家看看自己的小區和出行就能明白,今天我們艾銻無限有位同事,進地鐵的時候,測出了37度體溫,立刻就被地鐵站準備好的專車送到了醫院全面檢查,當然最后的結果是沒有任何問題,可能是他趕地鐵狂奔后溫度升高的結果,但對于測量體溫的人來說是,寧可錯判一百,也不能放過一個,花點錢,花點時間,都是小事,如果真是因為疏忽大意,最終放進了一個新冠患者,那后果將會不堪設想,這也就是為什么中國能在這么大范圍的國家,這么多人口在疫情發展過程中這么快控制住的原因.也許這就是除中國以外的國家需要學習和效仿的.
   
之前我分享了八個字,可能很多人不太理解,萬物同體,能量合一,今天的世界將不在是分離的狀態,我們在同一個星球,就像是同一個身體,如果我們身體某個部位出現了問題,就會對全身造成破壞,所以一國有難,全球支援,我們不在是競爭和對立的關系,我們彼此之間如果有競爭也應該是為了讓我們變得更好,我們是合一的整體,只有共同變好,才會讓彼此在這個星球中活的更長,活的更久.
   
祝福中國,祝福世界,祝福我們這個美麗的星球,讓我們聯合起來,真正的去踐行習主席提出的”人類命運共同體”的愿景,讓我們的世界未來越來越好.
艾銻知識 |Sql Server的一些知識點定義總結
數據庫完整性：是指數據庫中數據在邏輯上的一致性、正確性、有效性和相容性
　　實體完整性（Entity Integrity 行完整性）：實體完整性指表中行的完整性。主要用于保證操作的數據（記錄）非空、唯一且不重復。即實體完整性要求每個關系（表）有且僅有一個主鍵，每一個主鍵值必須唯一，而且不允許為“空”（NULL）或重復。
　　域完整性（Domain Integrity 列完整性）：是指數據庫表中的列必須滿足某種特定的數據類型或約束。其中約束又包括取值范圍、精度等規定。表中的CHECK、FOREIGN KEY 約束和DEFAULT、 NOT NULL定義都屬于域完整性的范疇。
　　參照完整性（Referential Integrity）屬于表間規則：對于永久關系的相關表，在更新、插入或刪除記錄時，如果只改其一，就會影響數據的完整性。如刪除父表的某記錄后，子表的相應記錄未刪除，致使這些記錄稱為孤立記錄。
　　參照完整性規則（Referential Integrity）要求：若屬性組F是關系模式R1的主鍵，同時F也是關系模式R2的外鍵，則在R2的關系中，F的取值只允許兩種可能：空值或等于R1關系中某個主鍵值。
Sql Server的存儲結構，頁、區、堆
　　頁：用于數據存儲的連續的磁盤空間塊，SQL Server中數據存儲的基本單位是頁，磁盤I/O操作在頁級執行，頁的大小為8KB。每頁的開頭是96字節的頁頭，用于存儲有關頁的系統信息，包括頁碼、頁類型、頁的可用空間以及擁有該頁的對象的分配單元ID；其他便是存儲數據的數據行與剩下可用空間，結構圖如下(個人繪制)     區間：區是管理空間的基本單位，一個區是8個物理上連續的頁（即64KB)的集合，所有頁都存儲在區中。SQL Server有兩種類型的區：統一區和混合區。
        堆：堆是指不含聚集索引的表，它的數據不按任何順序進行存儲。
        聯系一個堆中的數據的唯一結構是被稱為索引分配映射（IAM）的一個位圖頁，當掃描對象時，SQl server使用IAM頁來遍歷該對象的數據。
　　 堆表內的數據頁和行沒有任何特定的順序，也不鏈接在一起。數據頁之間唯一的邏輯連接是記錄在IAM頁內的信息
假設某訂單明細表中有100萬條數據，需要查詢某個訂單的明細數據，如下：
?

1	select*fromT_EPZ_INOUT_ENTRY_DETAILwhereentry_apply_id='31227000034000090169'

如果在堆表中進行查詢，SQLServer通過掃描IAM頁對堆表進行全表掃描，對entry_apply_id比較100萬次，如果以entry_apply_id字段建立索引，則因為索引鍵值數據都必定以B-Tree有順序的擺放，所以可采用二分查找找數據。也就是2的N次方大于記錄數，就可以找到該條數據。而2的20次方大于100萬，因此最多找尋20次就可以找到該條記錄。20次與100萬次的比較，你可以輕松感受出性能的差異。
由此引出索引的概念
　　索引分為聚集索引與非聚集索引
　　聚集索引 ：聚集索引是指數據庫表行中數據的物理順序與鍵值的邏輯（索引）順序相同。一個表只能有一個聚集索引，因為一個表的物理順序只有一種情況，所以，對應的聚集索引只能有一個。如果某索引不是聚集索引，則表中的行物理順序與索引順序不匹配，與非聚集索引相比，聚集索引有著更快的檢索速度
　 非聚集索引：非聚集索引是一種索引，該索引中索引的邏輯順序與磁盤上行的物理存儲順序不同
　　聚集索引與非聚集索引的形象比喻
　　漢語字典的正文本身就是一個聚集索引。 比如，我們要查“安”字，就會很自然地翻開字典的前幾頁，因為“安”的拼音是“an”，而按照拼音排序漢字的字典是以英文字母“a”開頭并以“z”結尾的，那么“安”字就自然地排在字典的前部。如果您翻完了所有以“a”開頭的部分仍然找不到這個字，那么就說明您的字典中沒有這個字；同樣的，如果查“張”字，那您也會將您的字典翻到最后部分，因為“張”的拼音是“zhang”。也就是說，字典的正文部分本身就是一個目錄，您不需要再去查其他目錄來找到您需要找的內容。正文內容本身就是一種按照一定規則排列的目錄稱為“聚集索引”。每個表只能有一個聚集索引，因為目錄只能按照一種方法進行排序
　　如果您認識某個字，您可以快速地從自動中查到這個字。但您也可能會遇到您不認識的字，不知道它的發音，這時候，您就不能按照剛才的方法找到您要查的字，而需要去根據“偏旁部首”查到您要找的字，然后根據這個字后的頁碼直接翻到某頁來找到您要找的字。但您結合“部首目錄”和“檢字表”而查到的字的排序并不是真正的正文的排序方法，比如您查“張”字，我們可以看到在查部首之后的檢字表中“張”的頁碼是672頁，檢字表中“張”的上面是“馳”字，但頁碼卻是63頁，“張”的下面是“弩”字，頁面是390頁。很顯然，這些字并不是真正的分別位于“張”字的上下方，現在您看到的連續的“馳、張、弩”三字實際上就是他們在非聚集索引中的排序，是字典正文中的字在非聚集索引中的映射。我們可以通過這種方式來找到您所需要的字，但它需要兩個過程，先找到目錄中的結果，然后再翻到您所需要的頁碼。我們把這種目錄純粹是目錄，正文純粹是正文的排序方式稱為“非聚集索引”。　 　　如圖，表中存放的數據是雜亂無章的，沒有按照姓名進行排序。我們將數據的姓名提取出來按照姓名創建一個非聚集索引。索引中姓名是排好序的，且索引所占用的空間遠遠小于表中數據所占用的空間，當我們查詢表中某條數據時候，將不再進行全表掃描，而對索引進行掃描，得到想要的數據再定位到表中具體的數據。　　但是 在非聚集索引上，要掃描某個具體的姓名也得耗費一定的時間，進一步優化，在其上面在加一個Non-leaf level (非葉節點)可以B樹算法快速的定位。極大的提高了查詢速度 　　　聚集索引的查詢就是按B樹查詢
　　   如何查詢表中的索引？　　　　  inidex_id = 0 說明表中無索引 inidex_id = 1 表中為聚集索引， inidex_id = 2或者3.。。。。為非聚集索引。　　　　
運用索引遇到的問題以及技術
　　　　頁分裂、填充因子、碎片整理、索引統計
　　　　頁分裂：因為在非聚集索引中或者有序的數據中 如 在a b e f中要插入新的數據 c ，那么c在物理順序中將放入f的后面，成為 a b e f c這樣變造成了頁分裂。 　　　　
　　　　可以用索引整理、或者在建表時定義填充因子(就是頁創建之初，讓每個頁存儲的數據占頁的比列)解決頁分裂的情況
?

1 2 3 4 5 6 7 8 9 10 11

dbcc showcontig(Tstudent,non_sname) --Tstudent表明，PK_TStudent索引名 ，查詢頁分裂情況     dbcc indexdefrag(schoolDB,Tstudent,non_sname)--索引整理     create nonclustered index non_sname on TStudent(sname) with drop_existing,fillfactor = 50--重建索引，并且制定填充因子     dbcc show_statistics(tstudent,non_sname)--查看索引統計     update statistics schooldb.dbo.tstudent --人工更新表中所有索引的統計     update statistics schooldb.dbo.tstudent non_sname --人工更新表中non_sname索引統計

　 在實際情況中，有時候不同索引會比用索引的速度更快，在運用索引查詢的時候，但是sql server工具會自動幫你判斷