『壹』 sql Server 怎樣使用SQL輸出建表語句
方法/步驟
1
首先找到這個資料庫，右擊-》任務-》生成腳本
2
然後就進入了生成腳本的向導，點擊下一步。
這里會有很多個資料庫，我們選擇自己想要建表的那個資料庫，選擇以後點擊下一步。
這里可以選擇編寫所有腳本，也可以不選直接下一步。
在這里，因為我們只是建表，所以我們把表勾上，不要勾選全部，不然下面就不能繼續了。
這里我們選擇要導出sql語句的表，勾上以後點擊下一步。
在這個界面，我們選擇將腳本保存到文件，然後瀏覽要存放的位置，還能選擇文本的編碼方式，一般默認是Unicode編碼方式。。
選擇生成的文件的名字，並選擇保存的路徑。
點擊瀏覽選擇保存後，點擊完成。
在這個界面你什麼都不用管，點擊完成就行。
點擊完成後，會看到生成腳本的進度，生成的狀態。
最後我們在保存的路徑下找到這個文件，用記事本打開看看，可以看到這個建表的sql語句。證明我們導出的建表語句是成功的。
『貳』 sql中OLTP和ALTP表示什麼
OLAP是聯機分析處理
OLTP是聯機事務處理
OLAP是數據倉庫系統的主要應用，支持復雜的分析操作，側重決策支持，並且提供直觀、易懂的查詢結果。
OLTP是傳統的關系型資料庫的主要應用模式，主要面對基本的、日常的事務處理；比如資料庫記錄的增、刪、改、查。
『叄』 SQL Server 2014 的集成內存 OLTP 有什麼戰略意義
SQL Server 2014 的集成內存 OLTP 有什麼戰略意義
Hekaton 的主要創新是：
1. MVCC取代了latch, 讓交易阻塞的時間盡可能短
2. 使用了一種在內存上性能更好的Bw-Tree實現
『肆』 Microsoft SQL Server和Sybase ASE及Sybase ASE哪些是OLTP資料庫啊
Sybase ASE的早期版本為SYBASE 10 及SYABSE 11，隨後改為Sybase ASE。MS的SQL SERVER 的早期版本也是由Sybase演化而來的，他們都是OLTP型資料庫。
『伍』 如何寫出高性能SQL語句
優化SQL查詢：如何寫出高性能SQL語句
1、首先要搞明白什麼叫執行計劃？
執行計劃是資料庫根據SQL語句和相關表的統計信息作出的一個查詢方案，這個方案是由查詢優化器自動分析產生欀如一條SQL語句如果用來從一個10萬條記錄的表中查1條記錄，那查詢優化器會選擇「索引查找」方式，如果該表進行了歸檔，當前只剩下5000條記錄了，那查詢優化器就會改變方案，採用 「全表掃描」方式。
可見，執行計劃並不是固定的，它是「個性化的」。產生一個正確的「執行計劃」有兩點很重要：
(1) SQL語句是否清晰地告訴查詢優化器它想干什麼？
(2) 查詢優化器得到的資料庫統計信息是否是最新的、正確的？
2、統一SQL語句的寫法
對於以下兩句SQL語句，程序員認為是相同的，資料庫查詢優化器認為是不同的。
select * from al
select * From al
其實就是大小寫不同，查詢分析器就認為是兩句不同的SQL語句，必須進行兩次解析。生成2個執行計劃。
所以作為程序員，應該保證相同的查詢語句在任何地方都一致，多一個空格都不行！
3、不要把SQL語句寫得太復雜
我經常看到，從資料庫中捕捉到的一條SQL語句列印出來有2張A4紙這么長。一般來說這么復雜的語句通常都是有問題的。我拿著這2頁長的SQL語句去請教原作者，結果他說時間太長，他一時也看不懂了。可想而知，連原作者都有可能看糊塗的SQL語句，資料庫也一樣會看糊塗。
一般，將一個Select語句的結果作為子集，然後從該子集中再進行查詢，這種一層嵌套語句還是比較常見的，但是根據經驗，超過3層嵌套，查詢優化器就很容易給出錯誤的執行計劃。因為它被繞暈了。像這種類似人工智慧的東西，終究比人的分辨力要差些，如果人都看暈了，我可以保證資料庫也會暈的。
另外，執行計劃是可以被重用的，越簡單的SQL語句被重用的可能性越高。而復雜的SQL語句只要有一個字元發生變化就必須重新解析，然後再把這一大堆垃圾塞在內存里。可想而知，資料庫的效率會何等低下。
4、使用「臨時表」暫存中間結果
簡化SQL語句的重要方法就是採用臨時表暫存中間結果，但是，臨時表的好處遠遠不止這些，將臨時結果暫存在臨時表，後面的查詢就在tempdb中了，這可以避免程序中多次掃描主表，也大大減少了程序執行中「共享鎖」阻塞「更新鎖」，減少了阻塞，提高了並發性能。
5、 OLTP系統SQL語句必須採用綁定變數
select * from orderheader where changetime > 』2010-10-20 00:00:01′
select * from orderheader where changetime > 』2010-09-22 00:00:01′
以上兩句語句，查詢優化器認為是不同的SQL語句，需要解析兩次。
如果採用綁定變數
select * from orderheader where changetime > @chgtime
@chgtime變數可以傳入任何值，這樣大量的類似查詢可以重用該執行計劃了，這可以大大降低資料庫解析SQL語句的負擔。一次解析，多次重用，是提高資料庫效率的原則。
6、綁定變數窺測
事物都存在兩面性，綁定變數對大多數OLTP處理是適用的，但是也有例外。
比如在where條件中的欄位是「傾斜欄位」的時候。
「傾斜欄位」指該列中的絕大多數的值都是相同的，一張人口調查表，其中「民族」這列，90%以上都是漢族。那麼如果一個SQL語句要查詢30歲的漢族人口有多少，那「民族」這列必然要被放在where條件中。這個時候如果採用綁定變數@nation會存在很大問題。
試想如果@nation傳入的第一個值是「漢族」，那整個執行計劃必然會選擇表掃描。然後，第二個值傳入的是「布依族」，按理說「布依族」占的比例可能只有萬分之一，應該採用索引查找。但是，由於重用了第一次解析的「漢族」的那個執行計劃，那麼第二次也將採用表掃描方式。這個問題就是著名的「綁定變數窺測」，建議對於「傾斜欄位」不要採用綁定變數。
7、 只在必要的情況下才使用begin tran
SQL Server中一句SQL語句默認就是一個事務，在該語句執行完成後也是默認commit的。其實，這就是begin tran的一個最小化的形式，好比在每句語句開頭隱含了一個begin tran，結束時隱含了一個commit。
有些情況下，我們需要顯式聲明begin tran，比如做「插、刪、改」操作需要同時修改幾個表，要求要麼幾個表都修改成功，要麼都不成功。begin tran 可以起到這樣的作用，它可以把若干SQL語句套在一起執行，最後再一起commit。好處是保證了數據的一致性，但任何事情都不是完美無缺的。Begin tran付出的代價是在提交之前，所有SQL語句鎖住的資源都不能釋放，直到commit掉。
可見，如果Begin tran套住的SQL語句太多，那資料庫的性能就糟糕了。在該大事務提交之前，必然會阻塞別的語句，造成block很多。
Begin tran使用的原則是，在保證數據一致性的前提下，begin tran 套住的SQL語句越少越好！有些情況下可以採用觸發器同步數據，不一定要用begin tran。
8、一些SQL查詢語句應加上nolock
在SQL語句中加nolock是提高SQL Server並發性能的重要手段，在oracle中並不需要這樣做，因為oracle的結構更為合理，有undo表空間保存「數據前影」，該數據如果在修改中還未commit，那麼你讀到的是它修改之前的副本，該副本放在undo表空間中。這樣，oracle的讀、寫可以做到互不影響，這也是oracle 廣受稱贊的地方。
SQL Server 的讀、寫是會相互阻塞的，為了提高並發性能，對於一些查詢，可以加上nolock，這樣讀的時候可以允許寫，但缺點是可能讀到未提交的臟數據。
使用 nolock有3條原則。
(1) 查詢的結果用於「插、刪、改」的不能加nolock ！
(2) 查詢的表屬於頻繁發生頁分裂的，慎用nolock ！
(3) 使用臨時表一樣可以保存「數據前影」，起到類似oracle的undo表空間的功能，
能採用臨時表提高並發性能的，不要用nolock 。
9、聚集索引沒有建在表的順序欄位上，該表容易發生頁分裂
比如訂單表，有訂單編號orderid，也有客戶編號contactid，那麼聚集索引應該加在哪個欄位上呢？對於該表，訂單編號是順序添加的，如果在orderid上加聚集索引，新增的行都是添加在末尾，這樣不容易經常產生頁分裂。然而，由於大多數查詢都是根據客戶編號來查的，因此，將聚集索引加在contactid上才有意義。而contactid對於訂單表而言，並非順序欄位。
比如「張三」的「contactid」是001，那麼「張三」的訂單信息必須都放在這張表的第一個數據頁上，如果今天「張三」新下了一個訂單，那該訂單信息不能放在表的最後一頁，而是第一頁！如果第一頁放滿了呢？很抱歉，該表所有數據都要往後移動為這條記錄騰地方。
SQL Server的索引和Oracle的索引是不同的，SQL Server的聚集索引實際上是對表按照聚集索引欄位的順序進行了排序，相當於oracle的索引組織表。SQL Server的聚集索引就是表本身的一種組織形式，所以它的效率是非常高的。也正因為此，插入一條記錄，它的位置不是隨便放的，而是要按照順序放在該放的數據頁，如果那個數據頁沒有空間了，就引起了頁分裂。所以很顯然，聚集索引沒有建在表的順序欄位上，該表容易發生頁分裂。
曾經碰到過一個情況，一位哥們的某張表重建索引後，插入的效率大幅下降了。估計情況大概是這樣的。該表的聚集索引可能沒有建在表的順序欄位上，該表經常被歸檔，所以該表的數據是以一種稀疏狀態存在的。比如張三下過20張訂單，而最近3個月的訂單只有5張，歸檔策略是保留3個月數據，那麼張三過去的 15張訂單已經被歸檔，留下15個空位，可以在insert發生時重新被利用。在這種情況下由於有空位可以利用，就不會發生頁分裂。但是查詢性能會比較低，因為查詢時必須掃描那些沒有數據的空位。
重建聚集索引後情況改變了，因為重建聚集索引就是把表中的數據重新排列一遍，原來的空位沒有了，而頁的填充率又很高，插入數據經常要發生頁分裂，所以性能大幅下降。
對於聚集索引沒有建在順序欄位上的表，是否要給與比較低的頁填充率？是否要避免重建聚集索引？是一個值得考慮的問題！
10、加nolock後查詢經常發生頁分裂的表，容易產生跳讀或重復讀
加nolock後可以在「插、刪、改」的同時進行查詢，但是由於同時發生「插、刪、改」，在某些情況下，一旦該數據頁滿了，那麼頁分裂不可避免，而此時nolock的查詢正在發生，比如在第100頁已經讀過的記錄，可能會因為頁分裂而分到第101頁，這有可能使得nolock查詢在讀101頁時重復讀到該條數據，產生「重復讀」。同理，如果在100頁上的數據還沒被讀到就分到99頁去了，那nolock查詢有可能會漏過該記錄，產生「跳讀」。
上面提到的哥們，在加了nolock後一些操作出現報錯，估計有可能因為nolock查詢產生了重復讀，2條相同的記錄去插入別的表，當然會發生主鍵沖突。
11、使用like進行模糊查詢時應注意
有的時候會需要進行一些模糊查詢比如
select * from contact where username like 『%yue%』
關鍵詞%yue%，由於yue前面用到了「%」，因此該查詢必然走全表掃描，除非必要，否則不要在關鍵詞前加%，
12、數據類型的隱式轉換對查詢效率的影響
sql server2000的資料庫一的程序在提交sql語句的時候，沒有使用強類型提交這個欄位的值，由sql server 2000自動轉換數據類型，會導致傳入的參數與主鍵欄位類型不一致，這個時候sql server 2000可能就會使用全表掃描。Sql2005上沒有發現這種問題，但是還是應該注意一下。
13、SQL Server 表連接的三種方式
(1) Merge Join
(2) Nested Loop Join
(3) Hash Join
SQL Server 2000隻有一種join方式——Nested Loop Join，如果A結果集較小，那就默認作為外表，A中每條記錄都要去B中掃描一遍，實際掃過的行數相當於A結果集行數x B結果集行數。所以如果兩個結果集都很大，那Join的結果很糟糕。
SQL Server 2005新增了Merge Join，如果A表和B表的連接欄位正好是聚集索引所在欄位，那麼表的順序已經排好，只要兩邊拼上去就行了，這種join的開銷相當於A表的結果集行數加上B表的結果集行數，一個是加，一個是乘，可見merge join 的效果要比Nested Loop Join好多了。
如果連接的欄位上沒有索引，那SQL2000的效率是相當低的，而SQL2005提供了Hash join，相當於臨時給A，B表的結果集加上索引，因此SQL2005的效率比SQL2000有很大提高，我認為，這是一個重要的原因。
總結一下，在表連接時要注意以下幾點：
(1) 連接欄位盡量選擇聚集索引所在的欄位
(2) 仔細考慮where條件，盡量減小A、B表的結果集
(3) 如果很多join的連接欄位都缺少索引，而你還在用SQL Server 2000，趕緊升級吧。
『陸』 已有資料庫升級sqlserver2014 可以支持內存oltp嗎
：CTP1已經可以下載了。 感覺這次資料庫引擎確實有了不少的增強，之前很多人抱怨MS只重視BI不重視資料庫引擎。 一），Hekaton 支持OLTP的in-memory 資料庫引擎
『柒』 postgreSQL的簡單介紹
postgreSQL是一款先進的開源資料庫，擁有非常齊全的自由軟體的對象-關系型資料庫管理系統（ORDBMS），可面向企業復雜SQL的OLTP業務場景，支持多項企業級功能，能解決使用資料庫的各種難題。
PostgreSQL的優勢有很多。它是一個免費的對象-關系資料庫伺服器(ORDBMS)，在靈活的BSD許可證下發行。
postgreSQL的特徵
函數：通過函數，可以在資料庫伺服器端執行指令程序。
索引：用戶可以自定義索引方法，或使用內置的 B 樹，哈希表與 GiST 索引。
觸發器：觸發器是由SQL語句查詢所觸發的事件。如：一個INSERT語句可能觸發一個檢查數據完整性的觸發器。觸發器通常由INSERT或UPDATE語句觸發。 多版本並發控制：PostgreSQL使用多版本並發控制（MVCC，Multiversion concurrency control）系統進行並發控制，該系統向每個用戶提供了一個資料庫的"快照"，用戶在事務內所作的每個修改，對於其他的用戶都不可見，直到該事務成功提交。
規則：規則（RULE）允許一個查詢能被重寫，通常用來實現對視圖（VIEW）的操作，如插入（INSERT）、更新（UPDATE）、刪除（DELETE）。
數據類型：包括文本、任意精度的數值數組、JSON 數據、枚舉類型、XML 數據等。全文檢索：通過 Tsearch2 或 OpenFTS，8.3版本中內嵌 Tsearch2。
NoSQL：JSON，JSONB，XML，HStore 原生支持，至 NoSQL 資料庫的外部數據包裝器。
數據倉庫：能平滑遷移至同屬postgreSQL生態的GreenPlum，DeepGreen，HAWK 等，使用 FDW 進行 ETL。
『捌』 OLTP和OLAP有何區別
1、適用人員不同：OLTP主要供基層人員使用，進行一線業務操作。OLAP則是探索並挖掘數據價值，作為企業高層進行決策的參考。
2、面向內容不同：OLTP面向應用，OLAP面向主題；
4、數據特點不同：OLTP的數據特點是當前的、最新的、細節的, 二維的、分立的；而OLTP則是歷史的, 聚集的, 多維的，集成的, 統一的；
5、存取能力不同：OLTP可以讀/寫數十條記錄，而OLAP則可以讀上百萬條記錄；
6、工作事件的復雜度不同：OLTP執行的是簡單的事務，而OLAP執行的是復雜任務；
7、可承載用戶數量不同：OLTP的可承載用戶數量為上千個，而OLAP則是上百萬個；
8、DB大小不同：OLTP的DB 大小為100GB，而OLAP則可以達到100TB；
9、執行時間要求不同：OLTP具有實時性，OLAP對時間的要求不嚴格。
(8)sqloltp擴展閱讀：
OLTP與OLAP的實際應用
OLAP工具是針對特定問題的聯機數據訪問與分析。它通過多維的方式對數據進行分析、查詢和報表。維是人們觀察數據的特定角度。
例如，一個企業在考慮產品的銷售情況時，通常從時間、地區和產品的不同角度來深入觀察產品的銷售情況。這里的時間、地區和產品就是維。
這些維的不同組合和所考察的度量指標構成的多維數組則是OLAP分析的基礎，可形式化表示為（維1，維2，……，維n，度量指標），如（地區、時間、產品、銷售額）。
多維分析是指對以多維形式組織起來的數據採取切片（Slice）、切塊（Dice）、鑽取（Drill-down和Roll-up）、旋轉（Pivot）等各種分析動作，以求剖析數據，使用戶能從多個角度、多側面地觀察資料庫中的數據，從而深入理解包含在數據中的信息。
應用OLTP，就必須重新定義OLTP在企業信息化體系結構中的地位。OLTP不再只是一套能處理訂單的老式應用程序。對典型的OLTP系統處理的大規模數據流更新進行同時分析，這種情況很罕見，因為一般認為這不是OLTP的目的。
數據倉庫更新固有的延遲阻礙著對最新數據的近實時分析。組織如果要對於數據的變化迅速作出反應，IT部門就必須讓OLTP產生比以往更大的作用。
參考資料來源：網路-OLTP
參考資料來源：網路-聯機分析處理
『玖』 sql server2014幾個不同的版本特點和用途
Microsoft SQL Server 2014已經內置最新的安全、功能更新。微軟將在愚人節，即Build2014開發者大會期間開放SQL Server 2014資源下載服務。
Microsoft SQL Server 2014為市場帶來了部署到核心資料庫中的新內存功能，包括內存 OLTP，它是對市場上大多數綜合內存資料庫解決方案的現有內存數據倉庫和 BI 功能的補充。
SQL Server 2014 還提供新的雲功能，以簡化 SQL 資料庫對雲技術的採用並幫助您開創新的混合方案。
主要功能：
1.內存 OLTP：
提供部署到核心 SQL Server 資料庫中的內存 OLTP 功能，以顯著提高資料庫應用程序性能。
內存 OLTP 是隨 SQL Server 2014 Engine 一起安裝的，而無需執行任何其他操作，您不必重新編寫資料庫應用程序或更新硬體即可提高內存性能。SQL Server 2014 CTP2 增強功能包括 AlwaysOn 支持、增加的 TSQL 外圍應用以及能夠將現有對象遷移到內存 OLTP 中。
2.內存可更新的 ColumnStore：
為現有 ColumnStore 的數據倉庫工作負載提供更高的壓縮率、更豐富的查詢支持和可更新性，為您提供甚至更快的載入速度、查詢性能、並發性和甚至更低的單位 TB 價格。
3.將內存擴展到 SSD：
通過將 SSD 作為資料庫緩沖池擴展，將固態存儲無縫且透明地集成到 SQL Server 中，從而提高內存處理能力和減少磁碟 IO
4.增強的高可用性
1) 新 AlwaysOn 功能：可用性組現在支持多達 8 個輔助副本，可以隨時讀取這些副本，即便發生了網路故障。故障轉移群集實例現在支持 Windows 群集共享卷，從而提高了共享存儲利用率和故障轉移復原能力。
2) 改進了在線資料庫操作：包括單個分區在線索引重建和管理表分區切換的鎖定優先順序，從而降低了維護停機影響。
5.加密備份：在內部部署和 Windows Azure 中提供備份加密支持。
6.IO 資源監管：資源池現在支持為每個卷配置最小和最大 IOPS，從而實現更全面的資源隔離控制。
7.混合方案：
1)智能備份：管理和自動完成將 SQL Server 備份到 Windows Azure 存儲（從內部部署和 Windows Azure 中）。
2)添加 Azure 副本向導：輕松將 Windows Azure 中的副本添加到內部部署可用性組中。
3)SQL XI（XStore 集成）：支持 Windows Azure 存儲 Blob 上的 SQL Server 資料庫文件（從內部部署和 Windows Azure 中）
4)部署向導：輕松將內部部署 SQL Server 資料庫部署到 Windows Azure 中。
注:微軟2014年3月26日正式宣布，雲計算操作系統Windows Azure更名為Microsoft Azure，新品牌自4月3日啟用。
『拾』 數據倉庫的並發能力和OLTP類資料庫的區別
在數據倉庫場景下，對並發能力的要求：
1.用戶的多任務能連接進來，這就是連接池的管理。
2.高效完成多任務並發執行，實際上是多任務並發進來後，如何充分利用集群資源，向用戶返回執行結果。對於OLTP類資料庫來說，用戶的任務（SQL）以短事務居多，所以並發能力會比較高。但是在數倉場景下，批處理、復雜查詢非常耗費系統資源，對並發能力的要求是幾十，例如POC測試中大部分是用5並發、20並發來測試。
由於DWS/LibrA（注1）的集群的Coordinator Node是多活的、對等的，所以整個系統的並發數隨著CN的增加可以不斷增長。具體的並發能力受限於實際場景：
•短事務：在平安城市某項目中，在混合負載場景下，測試過5000+並發，可以穩定運行。
•長事務：在某銀行復雜批處理場景下，20並發可以穩定運行。後續版本會進一步優化。
獨創技術：提供一種基於流水線執行模式的查詢內存自適應解決方法，解決多並發場景下系統資源搶占問題，實現無論多大並發，系統穩定運行。