資料庫高並發

『壹』 高並發下，資料庫成最大問題怎麼辦

一、資料庫結構的設計

為了保證資料庫的一致性和完整性，在邏輯設計的時候往往會設計過多的表間關聯，盡可能的降低數據的冗餘。（例如用戶表的地區，我們可以把地區另外存放到一個地區表中）如果數據冗餘低，數據的完整性容易得到保證，提高了數據吞吐速度，保證了數據的完整性，清楚地表達數據元素之間的關系。不要用自增屬性欄位作為主鍵與子表關聯。不便於系統的遷移和數據恢復。對外統計系統映射關系丟失。
表的設計具體注意的問題：
1、數據行的長度不要超過8020位元組，如果超過這個長度的話在物理頁中這條數據會佔用兩行從而造成存儲碎片，降低查詢效率。
2、能夠用數字類型的欄位盡量選擇數字類型而不用字元串類型的（電話號碼），這會降低查詢和連接的性能，並會增加存儲開銷。這是因為引擎在處理查詢和連接回逐個比較字元串中每一個字元，而對於數字型而言只需要比較一次就夠了。
3、對於不可變字元類型char和可變字元類型varchar都是8000位元組,char查詢快，但是耗存儲空間，varchar查詢相對慢一些但是節省存儲空間。在設計欄位的時候可以靈活選擇，例如用戶名、密碼等長度變化不大的欄位可以選擇CHAR，對於評論等長度變化大的欄位可以選擇VARCHAR。
4、欄位的長度在最大限度的滿足可能的需要的前提下，應該盡可能的設得短一些，這樣可以提高查詢的效率，而且在建立索引的時候也可以減少資源的消耗。

二、查詢的優化

在數據窗口使用sql時，盡量把使用的索引放在選擇的首列；演算法的結構盡量簡單；
在查詢時，不要過多地使用通配符如SELECT* FROM T1語句，要用到幾列就選擇幾列如：SELECT COL1,COL2 FROMT1；在可能的情況下盡量限制盡量結果集行數如：SELECT TOP 300 COL1,COL2,COL3 FROMT1,因為某些情況下用戶是不需要那麼多的數據的。
在沒有建索引的情況下，資料庫查找某一條數據，就必須進行全表掃描了，對所有數據進行一次遍歷，查找出符合條件的記錄。在數據量比較小的情況下，也許看不出明顯的差別，但是當數據量大的情況下，這種情況就是極為糟糕的了。
SQL語句在SQL SERVER中是如何執行的，他們擔心自己所寫的SQL語句會被SQLSERVER誤解。比如：
select * from table1 where name='zhangsan' and tID >10000和執行:
select * from table1 where tID > 10000 andname='zhangsan'
一些人不知道以上兩條語句的執行效率是否一樣，因為如果簡單的從語句先後上看，這兩個語句的確是不一樣，如果tID是一個聚合索引，那麼後一句僅僅從表的10000條以後的記錄中查找就行了；而前一句則要先從全表中查找看有幾個name='zhangsan'的，而後再根據限制條件條件tID>10000來提出查詢結果。
事實上，這樣的擔心是不必要的。SQLSERVER中有一個「查詢分析優化器」，它可以計算出where子句中的搜索條件並確定哪個索引能縮小表掃描的搜索空間，也就是說，它能實現自動優化。雖然查詢優化器可以根據where子句自動的進行查詢優化，但有時查詢優化器就會不按照您的本意進行快速查詢。

所以，優化查詢最重要的就是，盡量使語句符合查詢優化器的規則避免全表掃描而使用索引查詢。
具體要注意的：
1.應盡量避免在 where 子句中對欄位進行 null 值判斷，否則將導致引擎放棄使用索引而進行全表掃描，如：

select id from t where num is null

可以在num上設置默認值0，確保表中num列沒有null值，然後這樣查詢：

select id from t where num=0
2.應盡量避免在 where子句中使用!=或<>操作符，否則將引擎放棄使用索引而進行全表掃描。優化器將無法通過索引來確定將要命中的行數,因此需要搜索該表的所有行。
3.應盡量避免在 where 子句中使用 or 來連接條件，否則將導致引擎放棄使用索引而進行全表掃描，如：

select id from t where num=10 or num=20

可以這樣查詢：

select id from t where num=10
union all
select id from t where num=20s
4.in 和 not in 也要慎用，因為IN會使系統無法使用索引,而只能直接搜索表中的數據。如：

select id from t where num in(1,2,3)
對於連續的數值，能用 between 就不要用 in 了：
select id from t where num between 1 and 3
6.必要時強制查詢優化器使用某個索引，如在 where子句中使用參數，也會導致全表掃描。因為SQL只有在運行時才會解析局部變數，但優化程序不能將訪問計劃的選擇推遲到運行時；它必須在編譯時進行選擇。然而，如果在編譯時建立訪問計劃，變數的值還是未知的，因而無法作為索引選擇的輸入項。如下面語句將進行全表掃描：

select id from t where num=@num
可以改為強制查詢使用索引：
select id from t with(index(索引名)) where num=@num
7.應盡量避免在 where 子句中對欄位進行表達式操作，這將導致引擎放棄使用索引而進行全表掃描。如：

SELECT * FROM T1 WHERE F1/2=100
應改為:
SELECT * FROM T1 WHERE F1=100*2
SELECT * FROM RECORD WHERESUBSTRING(CARD_NO,1,4)=』5378』
應改為:
SELECT * FROM RECORD WHERE CARD_NO LIKE 『5378%』
SELECT member_number, first_name, last_name FROMmembers
WHERE DATEDIFF(yy,datofbirth,GETDATE()) >21
應改為:
SELECT member_number, first_name, last_name FROMmembers
WHERE dateofbirth <DATEADD(yy,-21,GETDATE())
即：任何對列的操作都將導致表掃描，它包括資料庫函數、計算表達式等等，查詢時要盡可能將操作移至等號右邊。
8.應盡量避免在where子句中對欄位進行函數操作，這將導致引擎放棄使用索引而進行全表掃描。如：

select id from t wheresubstring(name,1,3)='abc'--name以abc開頭的id
select id from t wheredatediff(day,createdate,'2005-11-30')=0--『2005-11-30』生成的id
應改為:
select id from t where name like 'abc%'
select id from t where createdate>='2005-11-30' andcreatedate<'2005-12-1'
9.不要在 where 子句中的「=」左邊進行函數、算術運算或其他表達式運算，否則系統將可能無法正確使用索引。
10.在使用索引欄位作為條件時，如果該索引是復合索引，那麼必須使用到該索引中的第一個欄位作為條件時才能保證系統使用該索引，否則該索引將不會被使用，並且應盡可能的讓欄位順序與索引順序相一致。
11.很多時候用 exists是一個好的選擇：

elect num from a where num in(select num from b)
用下面的語句替換：
select num from a where exists(select 1 from b where num=a.num)
但是後者的效率顯然要高於前者。因為後者不會產生大量鎖定的表掃描或是索引掃描。
如果你想校驗表裡是否存在某條紀錄，不要用count(*)那樣效率很低，而且浪費伺服器資源。可以用EXISTS代替。如：
IF (SELECT COUNT(*) FROM table_name WHERE column_name ='xxx')
可以寫成：
IF EXISTS (SELECT * FROM table_name WHERE column_name = 'xxx')
12.盡量使用表變數來代替臨時表。如果表變數包含大量數據，請注意索引非常有限（只有主鍵索引）。
13.避免頻繁創建和刪除臨時表，以減少系統表資源的消耗。
14.臨時表並不是不可使用，適當地使用它們可以使某些常式更有效，例如，當需要重復引用大型表或常用表中的某個數據集時。但是，對於一次性事件，最好使用導出表。
15.在新建臨時表時，如果一次性插入數據量很大，那麼可以使用 select into 代替 create table，避免造成大量log ，以提高速度；如果數據量不大，為了緩和系統表的資源，應先create table，然後insert。
16.如果使用到了臨時表，在存儲過程的最後務必將所有的臨時表顯式刪除，先 truncate table ，然後 drop table，這樣可以避免系統表的較長時間鎖定。
17.在所有的存儲過程和觸發器的開始處設置 SET NOCOUNT ON ，在結束時設置 SET NOCOUNT OFF。無需在執行存儲過程和觸發器的每個語句後向客戶端發送 DONE_IN_PROC 消息。
18.盡量避免大事務操作，提高系統並發能力。
19.盡量避免向客戶端返回大數據量，若數據量過大，應該考慮相應需求是否合理。

20.避免使用不兼容的數據類型。例如float和int、char和varchar、binary和varbinary是不兼容的。數據類型的不兼容可能使優化器無法執行一些本來可以進行的優化操作。例如:

SELECT name FROM employee WHERE salary >60000
在這條語句中,如salary欄位是money型的,則優化器很難對其進行優化,因為60000是個整型數。我們應當在編程時將整型轉化成為錢幣型,而不要等到運行時轉化。

23、能用DISTINCT的就不用GROUP BY

SELECT OrderID FROM Details WHERE UnitPrice > 10 GROUP BYOrderID
可改為：
SELECT DISTINCT OrderID FROM Details WHERE UnitPrice > 10
24.能用UNION ALL就不要用UNION

UNION ALL不執行SELECTDISTINCT函數，這樣就會減少很多不必要的資源

35.盡量不要用SELECT INTO語句。

SELECT INOT 語句會導致表鎖定，阻止其他用戶訪問該表。

四、建立高效的索引
創建索引一般有以下兩個目的：維護被索引列的唯一性和提供快速訪問表中數據的策略。
大型資料庫有兩種索引即簇索引和非簇索引，一個沒有簇索引的表是按堆結構存儲數據，所有的數據均添加在表的尾部，而建立了簇索引的表，其數據在物理上會按照簇索引鍵的順序存儲，一個表只允許有一個簇索引，因此，根據B樹結構，可以理解添加任何一種索引均能提高按索引列查詢的速度，但會降低插入、更新、刪除操作的性能，尤其是當填充因子（FillFactor）較大時。所以對索引較多的表進行頻繁的插入、更新、刪除操作，建表和索引時因設置較小的填充因子，以便在各數據頁中留下較多的自由空間，減少頁分割及重新組織的工作。
索引是從資料庫中獲取數據的最高效方式之一。95%的資料庫性能問題都可以採用索引技術得到解決。作為一條規則，我通常對邏輯主鍵使用唯一的成組索引，對系統鍵（作為存儲過程）採用唯一的非成組索引，對任何外鍵列[欄位]採用非成組索引。不過，索引就象是鹽，太多了菜就咸了。你得考慮資料庫的空間有多大，表如何進行訪問，還有這些訪問是否主要用作讀寫。
實際上，您可以把索引理解為一種特殊的目錄。微軟的SQL SERVER提供了兩種索引：聚集索引（clusteredindex，也稱聚類索引、簇集索引）和非聚集索引（nonclusteredindex，也稱非聚類索引、非簇集索引）。
聚集索引和非聚集索引的區別：
其實，我們的漢語字典的正文本身就是一個聚集索引。比如，我們要查「安」字，就會很自然地翻開字典的前幾頁，因為「安」的拼音是「an」，而按照拼音排序漢字的字典是以英文字母「a」開頭並以「z」結尾的，那麼「安」字就自然地排在字典的前部。如果您翻完了所有以「a」開頭的部分仍然找不到這個字，那麼就說明您的字典中沒有這個字；同樣的，如果查「張」字，那您也會將您的字典翻到最後部分，因為「張」的拼音是「zhang」。也就是說，字典的正文部分本身就是一個目錄，您不需要再去查其他目錄來找到您需要找的內容。
我們把這種正文內容本身就是一種按照一定規則排列的目錄稱為「聚集索引」。
如果您認識某個字，您可以快速地從自動中查到這個字。但您也可能會遇到您不認識的字，不知道它的發音，這時候，您就不能按照剛才的方法找到您要查的字，而需要去根據「偏旁部首」查到您要找的字，然後根據這個字後的頁碼直接翻到某頁來找到您要找的字。但您結合「部首目錄」和「檢字表」而查到的字的排序並不是真正的正文的排序方法，比如您查「張」字，我們可以看到在查部首之後的檢字表中「張」的頁碼是672頁，檢字表中「張」的上面是「馳」字，但頁碼卻是63頁，「張」的下面是「弩」字，頁面是390頁。很顯然，這些字並不是真正的分別位於「張」字的上下方，現在您看到的連續的「馳、張、弩」三字實際上就是他們在非聚集索引中的排序，是字典正文中的字在非聚集索引中的映射。我們可以通過這種方式來找到您所需要的字，但它需要兩個過程，先找到目錄中的結果，然後再翻到您所需要的頁碼。

『貳』 新人求助，大數據量高並發情況下寫入資料庫問題

1、如果硬體允許搞個讀寫分離。
2、讀取數據的時候採用臟讀方式，有效提高讀取性能
3、插入的時候大批量比如10W條，可以分開10次1W插入，有效提高寫入性能，但盡量不要1條1條來，會造成大量事務日誌

『叄』 高並發下資料庫插入重復數據，有什麼好方法

MySql避免重復插入記錄的幾種方法
本文章來給大家提供三種在mysql中避免重復插入記錄方法，主要是講到了ignore,Replace,ON DUPLICATE KEY UPDATE三種方法，有需要的朋友可以參考一下

方案一：使用ignore關鍵字
如果是用主鍵primary或者唯一索引unique區分了記錄的唯一性,避免重復插入記錄可以使用：
復制代碼 代碼如下:

INSERT IGNORE INTO `table_name` (`email`, `phone`, `user_id`) VALUES ('[email protected]', '99999', '9999');

這樣當有重復記錄就會忽略,執行後返回數字0

還有個應用就是復製表,避免重復記錄：
復制代碼 代碼如下:

INSERT IGNORE INTO `table_1` (`name`) SELECT `name` FROM `table_2`;

方案二：使用Replace

語法格式：
復制代碼 代碼如下:

REPLACE INTO `table_name`(`col_name`, ...) VALUES (...);
REPLACE INTO `table_name` (`col_name`, ...) SELECT ...;
REPLACE INTO `table_name` SET `col_name`='value',

...演算法說明：
REPLACE的運行與INSERT很相像,但是如果舊記錄與新記錄有相同的值，則在新記錄被插入之前，舊記錄被刪除，即：

嘗試把新行插入到表中
當因為對於主鍵或唯一關鍵字出現重復關鍵字錯誤而造成插入失敗時：
從表中刪除含有重復關鍵字值的沖突行
再次嘗試把新行插入到表中
舊記錄與新記錄有相同的值的判斷標准就是：
表有一個PRIMARY KEY或UNIQUE索引，否則，使用一個REPLACE語句沒有意義。該語句會與INSERT相同，因為沒有索引被用於確定是否新行復制了其它的行。
返回值：
REPLACE語句會返回一個數，來指示受影響的行的數目。該數是被刪除和被插入的行數的和
受影響的行數可以容易地確定是否REPLACE只添加了一行，或者是否REPLACE也替換了其它行：檢查該數是否為1（添加）或更大（替換）。
示例:
# eg:(phone欄位為唯一索引)
復制代碼 代碼如下:

REPLACE INTO `table_name` (`email`, `phone`, `user_id`) VALUES ('test569', '99999', '123');

另外,在 SQL Server 中可以這樣處理：

復制代碼 代碼如下:

if not exists (select phone from t where phone= '1') insert into t(phone, update_time) values('1', getdate()) else update t set update_time = getdate() where phone= '1'

更多信息請看：http://dev.mysql.com/doc/refman/5.1/zh/sql-syntax.html#replace

方案三：ON DUPLICATE KEY UPDATE
如‍上所寫，你也可以在INSERT INTO…..後面加上 ON DUPLICATE KEY UPDATE方法來實現。如果您指定了ON DUPLICATE KEY UPDATE，並且插入行後會導致在一個UNIQUE索引或PRIMARY KEY中出現重復值，則執行舊行UPDATE。
例如，如果列a被定義為UNIQUE，並且包含值1，則以下兩個語句具有相同的效果：
復制代碼 代碼如下:

INSERT INTO `table` (`a`, `b`, `c`) VALUES (1, 2, 3) ON DUPLICATE KEY UPDATE `c`=`c`+1;
UPDATE `table` SET `c`=`c`+1 WHERE `a`=1;

如果行作為新記錄被插入，則受影響行的值為1；如果原有的記錄被更新，則受影響行的值為2。

注釋：如果列b也是唯一列，則INSERT與此UPDATE語句相當：
復制代碼 代碼如下:

UPDATE `table` SET `c`=`c`+1 WHERE `a`=1 OR `b`=2 LIMIT 1;

如果a=1 OR b=2與多個行向匹配，則只有一個行被更新。通常，您應該盡量避免對帶有多個唯一關鍵字的表使用ON DUPLICATE KEY子句。

您可以在UPDATE子句中使用VALUES(col_name)函數從INSERT…UPDATE語句的INSERT部分引用列值。換句話說，如果沒有發生重復關鍵字沖突，則UPDATE子句中的VALUES(col_name)可以引用被插入的col_name的值。本函數特別適用於多行插入。VALUES()函數只在INSERT…UPDATE語句中有意義，其它時候會返回NULL。
復制代碼 代碼如下:

INSERT INTO `table` (`a`, `b`, `c`) VALUES (1, 2, 3), (4, 5, 6) ON DUPLICATE KEY UPDATE `c`=VALUES(`a`)+VALUES(`b`);

本語句與以下兩個語句作用相同：

復制代碼 代碼如下:

INSERT INTO `table` (`a`, `b`, `c`) VALUES (1, 2, 3) ON DUPLICATE KEY UPDATE `c`=3;
INSERT INTO `table` (`a`, `b`, `c`) VALUES (4, 5, 6) ON DUPLICATE KEY UPDATE c=9;

注釋：當您使用ON DUPLICATE KEY UPDATE時，DELAYED選項被忽略。

示例：
這個例子是我在實際項目中用到的：是將一個表的數據導入到另外一個表中，數據的重復性就得考慮(如下)，唯一索引為：email：
復制代碼 代碼如下:

INSERT INTO `table_name1` (`title`, `first_name`, `last_name`, `email`, `phone`, `user_id`, `role_id`, `status`, `campaign_id`)
SELECT '', '', '', `table_name2`.`email`, `table_name2`.`phone`, NULL, NULL, 'pending', 29 FROM `table_name2`
WHERE `table_name2`.`status` = 1
ON DUPLICATE KEY UPDATE `table_name1`.`status`='pending'

再貼一個例子：

復制代碼 代碼如下:

INSERT INTO `class` SELECT * FROM `class1` ON DUPLICATE KEY UPDATE `class`.`course`=`class1`.`course`

其它關鍵：DELAYED 做為快速插入，並不是很關心失效性，提高插入性能。
IGNORE 只關注主鍵對應記錄是不存在，無則添加，有則忽略。

特別說明：在MYSQL中UNIQUE索引將會對null欄位失效，也就是說(a欄位上建立唯一索引)：
復制代碼 代碼如下:

INSERT INTO `test` (`a`) VALUES (NULL);

是可以重復插入的（聯合唯一索引也一樣）。

『肆』 做分布式高並發的時候 資料庫怎麼支持高並發

些建議處理高並發要學習的東西實在太多.要在沒有實際工作經驗的情況下逐一了解太難,也很難深入.對於高並發的學習,我建議除了多閱讀高並發架構的文檔學習基本的方法論以外,自己要去深入學習網路基礎,數據結構和演算法.這些都是處理高並發熱點

『伍』 java多用戶同時訪問和資料庫進行交互，如何能夠高並發

我覺得1萬的數據並發量並不大，想oracle資料庫，mysql承載這些並發是沒有問題的

我覺得，主要的問題在於你GPS是一直在修改的，因為車輛在不斷的行駛，這樣的話，可能會影響資料庫的性能
我覺得，你可以用一個內存行的資料庫，比如，redis，用這個來存放GPS信息，redis是基於內存的，讀寫要比關系資料庫速度快(忽略網路因素),你可能要問GPS入庫怎麼弄，可以做一個定時任務，每隔多少時間來將redis的數據寫入到資料庫中，當然，redis也支持一些演算法，比如LRU，來設置何時將數據同步到資料庫

『陸』 資料庫高並發寫入，怎麼降低資料庫的壓力

發的時候，是直接顯示在界面上的，這個時候還沒有存入資料庫吧。寫入估計有排隊機制吧。

對於微博、評論這樣的數據，對可用性要求不算太高的，可以選擇採用Nosql來解決。

『柒』 資料庫高並發下樂觀鎖的原理

在高並發下，經常需要處理SELECT之後，在業務層處理邏輯，再執行UPDATE的情況。

若兩個連接並發查詢同一條數據，然後在執行一些邏輯判斷或業務操作後，執行UPDATE，可能出現與預期不相符的結果。

在不使用悲觀鎖與復雜SQL的前提下，可以使用樂觀鎖處理該問題，同時兼顧性能。

場景模擬：

假設一張表兩個欄位，一個id，一個use_count。
表裡存了100個id，每個id對應自己的use_count。

當id每使用一次，use_count要加1。當use_count大於1000時，這個id就不能在被使用了（換句話說 無法從資料庫中查出）。

在高並發情況下，會遇到一種問題：假設數據表中有一條記錄為：id=123456, use_count=999
A與B兩個連接並發查詢這個id=123456，都執行下列SQL:

SELECT*FROMtableWHEREid=123456anse_count<1000;

A先執行，得到id=123456的use_count是999，之後在程序里做了一些邏輯判斷或業務操作後執行SQL：

UPDATEtableSETuse_count+1WHEREid=123456;

在A做判斷且沒有update之前，B也執行了查詢SQL，發現use_count是999，之後它也會執行SQL：

UPDATEtableSETuse_count+1WHEREid=123456;

但是，事實上B不應該取得這個id，因為A已經是第1000個使用者。

處理步驟如下：

1、添加第3個欄位version，int類型，default值為0。version值每次update時作加1處理。

'0'NOTNULLAFTERuse_count;

2、SELECT時同時獲取version值（例如為3）。

SELECTuse_count,versionFROMtableWHEREid=123456ANDuse_count<1000;

3、UPDATE時檢查version值是否為第2步獲取到的值。

UPDATEtableSETversion=4,use_count=use_count+1WHEREid=123456ANDversion=3;

如果UPDATE的記錄數為1，則表示成功。
如果UPDATE的記錄數為0，則表示已經被其他連接UPDATE過了，需作異常處理。

參考地址：http://latrell.me/post-358.html

『捌』 哪些資料庫支持高並發

池化支持，
資料庫連接池是最常見的池化手段。由於連接資料庫會耗費比較多的時間，所以可以通過復用連接的方式來減少這些時間開銷。使用連接池的時候需要控制好兩個變數

『玖』 高並發性的資料庫操作-Mysql

使用SELECT LAST_INSERT_ID() 函數就可以，因為LAST_INSERT_ID是基於Connection的，只要每個線程都使用獨立的 Connection對象，LAST_INSERT_ID函數將返回該Connection對AUTO_INCREMENT列最新的insert or update 操作生成的第一個record的ID。這個值不能被其它客戶端（Connection）影響，保證了你能夠找回自己的 ID 而不用擔心其它客戶端的活動，而且不需要加鎖。使用單INSERT語句插入多條記錄, LAST_INSERT_ID返回一個列表。

『拾』 mysql資料庫怎麼解決高並發問題

通常情況下在PHP中MySQL查詢是串列的，如果能實現MySQL查詢的非同步化，就能實現多條SQL語句同時執行，這樣就能大大地縮短MySQL查詢的耗時，提高資料庫查詢的效率。目前MySQL的非同步查詢只在MySQLi擴展提供，查詢方法分別是：
1、使用MYSQLI_ASYNC模式執行mysqli::query
2、獲取非同步查詢結果：mysqli::reap_async_query
使用mysql非同步查詢，需要使用mysqlnd作為PHP的MySQL資料庫驅動。
使用MySQL非同步查詢，因為需要給所有查詢都創建一個新的連接，而MySQL服務端會為每個連接創建一個單獨的線程進行處理，如果創建的線程過多，則會造成線程切換引起系統負載過高。Swoole中的非同步MySQL其原理是通過MYSQLI_ASYNC模式查詢，然後獲取mysql連接的socket，加入到epoll事件循環中，當資料庫返回結果時會回調指定函數，這個過程是完全非同步非阻塞的。