1.事務不要大，太大一方面佔用資源多，另外對資源加鎖時間也長
2.合理的索引，使事務快速完成
3.表的欄位和記錄不要涉及多個業務，不同的業務使用不同的表
4.優化程序設計，將大的業務分解
簡單的說：就是使並發操作對資源的使用降低到最小
B. 研究高並發量的SQL語句如何去優化
1、數據行的長度不要超過8020位元組，如果超過這個長度的話在物理頁中這條數據會佔用兩行從而造成存儲碎片，降低查詢效率。
2、能夠用數字類型的欄位盡量選擇數字類型而不用字元串類型的。
3、對於不可變字元類型char和可變字元類型varchar 都是8000位元組,char查詢快，但是耗存儲空間，varchar查詢相對慢一些但是節省存儲空間。
4、欄位的長度在最大限度的滿足可能的需要的前提下，應該盡可能的設得短一些，這樣可以提高查詢的效率，而且在建立索引的時候也可以減少資源的消耗。
5、欄位順序對存儲效率也有不小的影響。在做表結構設計的時候，我們往往不會去考慮欄位的擺放順序。但是，實際上欄位的擺放順序對資料庫操作的性能是有影響的。
查詢的優化
1、保證在實現功能的基礎上，盡量減少對資料庫的訪問次數；
2、通過搜索參數，盡量減少對表的訪問行數,最小化結果集，從而減輕網路負擔；能夠分開的操作盡量分開處理，提高每次的響應速度；
3、在數據窗口使用SQL時，盡量把使用的索引放在選擇的首列；演算法的結構盡量簡單；
4、在查詢時，不要過多地使用通配符如SELECT * FROM T1語句，要用到幾列就選擇幾列如：SELECT COL1,COL2 FROM T1；
5、在可能的情況下盡量限制盡量結果集行數如：SELECT TOP 300 COL1,COL2,COL3 FROM T1,因為某些情況下用戶是不需要那麼多的數據的。
6、在沒有建索引的情況下，資料庫查找某一條數據，就必須進行全表掃描了，對所有數據進行一次遍歷，查找出符合條件的記錄。
7、在數據量比較小的情況下，也許看不出明顯的差別，但是當數據量大的情況下，這種情況就是極為糟糕的了。
8、合理的使用臨時表。例如表A 的 ID 欄位有索引，並且這個表的數據有很多。這時候要查詢這個ID 的最大值與最小值，如果能合理使用臨時表，速度將大幅度提高！
9、多層的子查詢需要進行簡單化。
C. 如何優化大數據高並發量的系統的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。日誌文件應放在單獨的磁碟中。
D. 怎樣解決sql server 資料庫的並發問題
「sql server 資料庫的並發問題」不如說是「資料庫並發處理」問題。因為它不光是存在於SQL資料庫上，幾乎存在於任何資料庫上。並發情況的處理一直是網路資料庫編程需要面對和解決的，也往往是最花費時間和精力去對付的問題之一。這對於多數網路資料庫編程新手來說，都是要碰到的一個問題。
就本人的經驗給於以下提示：
1、對於容易出現並發問題的表，最好是一次性取出所需的數據，或部分數據，而不使用那些帶緩沖的控制項。
2、每次改寫數據時，需要先讀取要改寫的記錄進行校驗。
3、盡可能少地對已存入表中的數據進行改寫。可以用「刪除」標志來作費原記錄，新增改寫後的記錄。這樣，每次操作都會「記錄在案」，而不會無據可查。也規避了客戶端改寫時某條記錄已發生了變化的情況發生。
4、每個表都需要擁有一個自動增量的欄位，並設為主鍵，這樣會減少SQL沖突的發生規避某些錯誤，而且會使資料庫數據的查找加快（注意，在SQL2000中，如果一個表中存在兩條完全一樣的記錄，將發生嚴重問題！比如兩條空白記錄）。
5、使用什麼語言編程是無所謂的，重要的是注意設計上的控制項。如當某個客戶端上正在對某人員的信息進行處理時，別的客戶端就不應該對該人員的信息進行處理。這可以引入佔用機制，如客戶端調入某人准備處理前先在表中標志佔用標志和佔用時刻……（具體的你自個去想吧）。
最後，希望給你說了這么多，你能看懂並好好運用它們。網路資料庫編程技術上是不難的，最難的是考慮方方面面的因素。
E. 代碼中並發執行同一個sql會影響sql的速度嗎
對單次sql執行來講，影響不會太大，除非並發數超過了資料庫瓶頸，導致sql執行需要等待；
對整個並發執行來講，肯定會比執行單個sql要慢的，因為雖然多次執行的sql是一樣的，但是對資料庫來講還是需要進行多次處理的，只是在資料庫中sql只需要解析
一次就好
F. SQLserver是怎麼處理並發控制（同時有多個用戶操作修改資料庫中同一條記錄）server和客戶端分別如何處理
sqlserver
本身通過不同等級的鎖處理並發控制。
有記錄鎖、頁鎖、表鎖。
如果多個用戶同時操作一個記錄，只有第一個能修改，後面的修改時處理等等狀態。
但是在一般程序界面上，多個人同時打開了同一個記錄要進行修改，資料庫往往是保存最後一個修改的數據。可以在保存前做驗證，如果發現打開的數據已改變（界面和資料庫一不致了），則提示數據已改變，重新獲取新數據，然後才能修改和保存。
G. 代碼中並發執行同一個sql會影響sql的速度嗎
對單次sql執行來講，影響不會太大，除非並發數超過了資料庫瓶頸，導致sql執行需要等待；
對整個並發執行來講，肯定會比執行單個sql要慢的，因為雖然多次執行的sql是一樣的，但是對資料庫來講還是需要進行多次處理的，只是在資料庫中sql只需要解析一次就好
H. 在SQL server 2005 資料庫系統中，多用戶同時操作資料庫成為並發操作，那麼在資料庫系統上執行並發操作時
樓下說得對, 最小控制單元是:事務 一 事務的屬性 事務具有ACID屬性 即 Atomic原子性, Consistent一致性, Isolated隔離性, Durable永久性原子性就是事務應作為一個工作單元,事務處理完成，所有的工作要麼都在資料庫中保存下來，要麼完全 回滾，全部不保留一致性事務完成或者撤銷後，都應該處於一致的狀態隔離性多個事務同時進行，它們之間應該互不幹擾.應該防止一個事務處理其他事務也要修改的數據時， 不合理的存取和不完整的讀取數據永久性事務提交以後，所做的工作就被永久的保存下來 二 事務並發處理會產生的問題丟失更新當兩個或多個事務選擇同一行，然後基於最初選定的值更新該行時，會發生丟失更新問題、 每個事務都不知道其它事務的存在。最後的更新將重寫由其它事務所做的更新，這將導致數據丟失。 臟讀當第二個事務選擇其它事務正在更新的行時，會發生未確認的相關性問題。 第二個事務正在讀取的數據還沒有確認並且可能由更新此行的事務所更改。 不可重復讀當第二個事務多次訪問同一行而且每次讀取不同的數據時，會發生不一致的分析問題。 不一致的分析與未確認的相關性類似，因為其它事務也是正在更改第二個事務正在讀取的數據。 然而，在不一致的分析中，第二個事務讀取的數據是由已進行了更改的事務提交的。而且，不一致的分析涉及多次（兩次或更多）讀取同一行，而且每次信息都由其它事務更改；因而該行被非重復讀取。 幻像讀當對某行執行插入或刪除操作，而該行屬於某個事務正在讀取的行的范圍時，會發生幻像讀問題。 事務第一次讀的行范圍顯示出其中一行已不復存在於第二次讀或後續讀中，因為該行已被其它事務刪除。同樣，由於其它事務的插入操作，事務的第二次或後續讀顯示有一行已不存在於原始讀中。 三 事務處理類型 自動處理事務 系統默認每個T－SQL命令都是事務處理 由系統自動開始並提交隱式事務當有大量的DDL 和DML命令執行時會自動開始，並一直保持到用戶明確提交為止，切換隱式事務可以用SET IMPLICIT_TRANSACTIONS 為連接設置隱性事務模式.當設置為 ON 時，SET IMPLICIT_TRANSACTIONS 將連接設置為隱性事務模式。當設置為 OFF 時，則使連接返回到自動提交事務模式 用戶定義事務 由用戶來控制事務的開始和結束 命令有: begin tran commit tran rollback tran 命令分布式事務跨越多個伺服器的事務稱為分布式事務,sql server 可以由DTc microsoft distributed transaction coordinator 來支持處理分布式事務,可以使用 BEgin distributed transaction 命令啟動一個分布式事務處理
I. SQL 事務並發問題處理 都進來看看
確保你的事務的第一句是update對應A表記錄的語句，就算此時不馬上把票數-1，也要確保隨便update一個欄位（更新成原值也可以），這樣就保證了事務第一步已經給表此記錄上了行鎖，並發時，只要當前事務沒走完，其他用戶操作同條記錄的操作都處於等待中不能執行，就不會發生並發出現負數的情況
這個是類似項目資料庫端比較通用的解決並發問題的方法
不過你的執行時間如果是10秒太久了，至少要控制到一秒吧，高並發下，這樣10秒會出問題的