當前位置:首頁 » 編程語言 » sql並發怎麼寫
擴展閱讀
第一個元素存儲順序 2022-09-25 12:26:53
c語言表示1不是素數 2022-09-25 12:26:36
fd01前端提升 2022-09-25 12:22:56

sql並發怎麼寫

發布時間: 2022-08-11 08:54:51

A. sql實現並發控制的主要方法是

事務和鎖。

B. 如何優化大數據高並發量的系統的SQL語句提高效率

1. SQL優化的原則是:將一次操作需要讀取的BLOCK數減到最低,即在最短的時間達到最大的數據吞吐量。 調整不良SQL通常可以從以下幾點切入: ? 檢查不良的SQL,考慮其寫法是否還有可優化內容 ? 檢查子查詢 考慮SQL子查詢是否可以用簡單連接的方式進行重新書寫 ? 檢查優化索引的使用 ? 考慮資料庫的優化器 2. 避免出現SELECT * FROM table 語句,要明確查出的欄位。 3. 在一個SQL語句中,如果一個where條件過濾的資料庫記錄越多,定位越准確,則該where條件越應該前移。 4. 查詢時盡可能使用索引覆蓋。即對SELECT的欄位建立復合索引,這樣查詢時只進行索引掃描,不讀取數據塊。 5. 在判斷有無符合條件的記錄時建議不要用SELECT COUNT (*)和select top 1 語句。 6. 使用內層限定原則,在拼寫SQL語句時,將查詢條件分解、分類,並盡量在SQL語句的最里層進行限定,以減少數據的處理量。 7. 應絕對避免在order by子句中使用表達式。 8. 如果需要從關聯表讀數據,關聯的表一般不要超過7個。 9. 小心使用 IN 和 OR,需要注意In集合中的數據量。建議集合中的數據不超過200個。 10. <> 用 < 、 > 代替,>用>=代替,<用<=代替,這樣可以有效的利用索引。 11. 在查詢時盡量減少對多餘數據的讀取包括多餘的列與多餘的行。 12. 對於復合索引要注意,例如在建立復合索引時列的順序是F1,F2,F3,則在where或order by子句中這些欄位出現的順序要與建立索引時的欄位順序一致,且必須包含第一列。只能是F1或F1,F2或F1,F2,F3。否則不會用到該索引。 13. 多表關聯查詢時,寫法必須遵循以下原則,這樣做有利於建立索引,提高查詢效率。格式如下select sum(table1.je) from table1 table1, table2 table2, table3 table3 where (table1的等值條件(=)) and (table1的非等值條件) and (table2與table1的關聯條件) and (table2的等值條件) and (table2的非等值條件) and (table3與table2的關聯條件) and (table3的等值條件) and (table3的非等值條件)。 注:關於多表查詢時from 後面表的出現順序對效率的影響還有待研究。 14. 子查詢問題。對於能用連接方式或者視圖方式實現的功能,不要用子查詢。例如:select name from customer where customer_id in ( select customer_id from order where money>1000)。應該用如下語句代替:select name from customer inner join order on customer.customer_id=order.customer_id where order.money>100。 15. 在WHERE 子句中,避免對列的四則運算,特別是where 條件的左邊,嚴禁使用運算與函數對列進行處理。比如有些地方 substring 可以用like代替。 16. 如果在語句中有not in(in)操作,應考慮用not exists(exists)來重寫,最好的辦法是使用外連接實現。 17. 對一個業務過程的處理,應該使事物的開始與結束之間的時間間隔越短越好,原則上做到資料庫的讀操作在前面完成,資料庫寫操作在後面完成,避免交叉。 18. 請小心不要對過多的列使用列函數和order by,group by等,謹慎使用disti軟體開發t。 19. 用union all 代替 union,資料庫執行union操作,首先先分別執行union兩端的查詢,將其放在臨時表中,然後在對其進行排序,過濾重復的記錄。 當已知的業務邏輯決定query A和query B中不會有重復記錄時,應該用union all代替union,以提高查詢效率。 數據更新的效率 1. 在一個事物中,對同一個表的多個insert語句應該集中在一起執行。 2. 在一個業務過程中,盡量的使insert,update,delete語句在業務結束前執行,以減少死鎖的可能性。 資料庫物理規劃的效率 為了避免I/O的沖突,我們在設計資料庫物理規劃時應該遵循幾條基本的原則(以ORACLE舉例):  table和index分離:table和index應該分別放在不同的tablespace中。  Rollback Segment的分離:Rollback Segment應該放在獨立的Tablespace中。  System Tablespace的分離:System Tablespace中不允許放置任何用戶的object。(mssql中primary filegroup中不允許放置任何用戶的object)  Temp Tablesace的分離:建立單獨的Temp Tablespace,並為每個user指定default Temp Tablespace 避免碎片:但segment中出現大量的碎片時,會導致讀數據時需要訪問的block數量的增加。對經常發生DML操作的segemeng來說,碎片是不能完全避免的。所以,我們應該將經常做DML操作的表和很少發生變化的表分離在不同的Tablespace中。 當我們遵循了以上原則後,仍然發現有I/O沖突存在,我們可以用數據分離的方法來解決。  連接Table的分離:在實際應用中經常做連接查詢的Table,可以將其分離在不同的Taclespace中,以減少I/O沖突。  使用分區:對數據量很大的Table和Index使用分區,放在不同的Tablespace中。 在實際的物理存儲中,建議使用RAID。日誌文件應放在單獨的磁碟中。

C. SQL資料庫並發處理

你這個也不會涉及到並發啊,就按正常的處理就行。一般涉及並發的都是減法問題,加法沒關系。

D. 如何寫出高性能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,趕緊升級吧。

E. SQL並發執行問題

sql server資料庫的話
更新的時候會有事務鎖,多個事務不會產生沖突。
就是說對於同一行記錄,第一個事務執行成功,第二個事務就不會再次更新了。

F. 在 SQL Server 中,如何實現並發環境下查詢結果不重復

begin tran
select top 1 * from test_table with (TABLOCKX) //表鎖
update firstrow flag
commit tran

G. Sql中如何使用 並發 觸發 事務

這個也不是事務也不是觸發器
當有人瀏覽公告時,程序中把該公告的id以及查看人的id存入t_b表
這只是個插入語句,而且只有一個表,沒涉及到其他表的操作
不過建議你t_b表加一列添加時間

H. 如何在sql server中更好的實現並發控制

一 : 對表進行手動加鎖 ,像這樣:

SQL code?

SELECT * FROM table WITH (TABLOCKX)

二: 設置隔離級別實現並發控制,如下所示:

SQL code?

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

三:使用時間戳

每一次對資料庫做更新時都要留下TIMESTAMP, 修改之前要取得TIMESTAMP, 提交時要比較數據的TIMESTAMP, 如果不同則停止處理, 向用戶提示在他操作期間, 他所看到的數據已經被他人改動過了

I. 作好SQL SERVER數據並發,除了使用事務+存儲過程外,還需要哪些注意的問題,可以確保多個用戶的並發操作。

1.事務不要大,太大一方面佔用資源多,另外對資源加鎖時間也長
2.合理的索引,使事務快速完成
3.表的欄位和記錄不要涉及多個業務,不同的業務使用不同的表
4.優化程序設計,將大的業務分解
簡單的說:就是使並發操作對資源的使用降低到最小

J. sql並發控制具體的語句

一般並發資料庫會自控制的,資料庫有鎖機制。
如果程序要控制鎖,使用with ( 鎖 ) 的語法。

比如:

select * from table_name with ( xlock)