1. 如何處理大量數據並發操作
處理大量數據並發操作可以採用如下幾種方法:
1.使用緩存：使用程序直接保存到內存中。或者使用緩存框架: 用一個特定的類型值來保存，以區別空數據和未緩存的兩種狀態。
2.資料庫優化：表結構優化;sql語句優化，語法優化和處理邏輯優化;分區;分表;索引優化;使用存儲過程代替直接操作。
3.分離活躍數據:可以分為活躍用戶和不活躍用戶。
4.批量讀取和延遲修改: 高並發情況可以將多個查詢請求合並到一個。高並發且頻繁修改的可以暫存緩存中。
5.讀寫分離: 資料庫伺服器配置多個，配置主從資料庫。寫用主資料庫，讀用從資料庫。
6.分布式資料庫: 將不同的表存放到不同的資料庫中，然後再放到不同的伺服器中。
7.NoSql和Hadoop: NoSql，not only SQL。沒有關系型資料庫那麼多限制，比較靈活高效。Hadoop，將一個表中的數據分層多塊，保存到多個節點（分布式）。每一塊數據都有多個節點保存（集群）。集群可以並行處理相同的數據，還可以保證數據的完整性。
拓展資料:
大數據（big data），指無法在一定時間范圍內用常規軟體工具進行捕捉、管理和處理的數據集合，是需要新處理模式才能具有更強的決策力、洞察發現力和流程優化能力的海量、高增長率和多樣化的信息資產。
在維克托·邁爾-舍恩伯格及肯尼斯·庫克耶編寫的《大數據時代》中大數據指不用隨機分析法（抽樣調查）這樣捷徑，而採用所有數據進行分析處理。大數據的5V特點（IBM提出）：Volume（大量）、Velocity（高速）、Variety（多樣）、Value（低價值密度）、Veracity（真實性）。
2. 高並發下，資料庫成最大問題怎麼辦
一、資料庫結構的設計
為了保證資料庫的一致性和完整性，在邏輯設計的時候往往會設計過多的表間關聯，盡可能的降低數據的冗餘。（例如用戶表的地區，我們可以把地區另外存放到一個地區表中）如果數據冗餘低，數據的完整性容易得到保證，提高了數據吞吐速度，保證了數據的完整性，清楚地表達數據元素之間的關系。不要用自增屬性欄位作為主鍵與子表關聯。不便於系統的遷移和數據恢復。對外統計系統映射關系丟失。
表的設計具體注意的問題：
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頁。很顯然，這些字並不是真正的分別位於「張」字的上下方，現在您看到的連續的「馳、張、弩」三字實際上就是他們在非聚集索引中的排序，是字典正文中的字在非聚集索引中的映射。我們可以通過這種方式來找到您所需要的字，但它需要兩個過程，先找到目錄中的結果，然後再翻到您所需要的頁碼。
3. 怎麼提高資料庫高峰時訪問的並發能力
1：首先需要有非常良好的網路帶寬，若有上萬人同時錄入數據的普通的Web信息管理系統，至少需要10M左右的網路帶寬，而且網通、電信的主幹網都有接入比較好，否則全國各地的網路情況都不太一樣，有的城市錄入數據時可能會遇到網路非常緩慢的情況，甚至到無法忍受的程度。
2：須有一台牛X的Web伺服器 + 一台牛X的資料庫伺服器(備注接近頂配的奢侈硬體伺服器非個人PC)，由於是需要錄入1000萬條以上數據，最好採用Oracle資料庫比較理想一些，經得起考驗一些。
3：需要進行適當的內存緩存優化策略，不能所有的資料庫都依靠SQL資料庫的方式把壓力放在資料庫伺服器上，盡量多使用內存的方式處理數據。
4：需要一個牛X的，經得起考驗的資料庫訪問層，因為每秒都有可能成千上萬的人在訪問，若是質量不良好的資料庫訪問組件、或者不穩定的資料庫訪問組件，更容易導致系統崩潰、或者佔用非常龐大的內存，最後容易導致整個系統的崩潰。
5：需要優化分頁存取數據功能，應為有可能會有1000萬條數據，若分頁讀取數據的功能沒能優化到最高，也很容易導致系統的崩潰，因為上萬人萬一在同一時間，或者接近同一時間點了查詢某頁數據時，那系統就真崩潰了，分頁存取數據一定需要做到極致才可以。
6：需要進行資料庫索引優化，有索引和沒索引的性能差距有時候會是100倍，大數據量時可能會有1000倍都有可能，資料庫索引優化到極致了更容易得到運行順暢的信息管理系統。
7：嚴謹高效的資料庫事務處理，由於高並發，並且有些單據是需要同時寫入多個表，需要保證資料庫的一致性，要麼全部成功，要麼全部失敗重新錄入數據，所以需要一個高效的資料庫事務處理機制的配合。
8：所有的系統的操作日誌、異常信息都需要完整的記錄下來，當系統發生一些故障時，可以快速排查問題，對正確診斷系統發生的故障的原因做分析參考用。
9：需要經常檢測系統的各項指標、例如各伺服器的內存使用情況、CPU使用情況、網路帶寬使用情況，高峰時的各個參數是什麼情況、系統不繁忙時的情況等，若伺服器快承受不了壓力了，就得馬上增加負載均衡的伺服器，網路帶寬不夠了需要增加等等，總不能等系統崩潰了再去做這些事情。
10：每個頁面的HTML、JS都進行優化，若某個頁面多餘發了100個字元的垃圾HTML代碼，那1萬人每天獲得100次，那得佔用多少網路帶寬，100×100×1萬個字元的多餘HTML被網路上傳輸了，要知道接入主幹網的網路資源是多麼寶貴，費用是多麼昂貴。
11：HTML、JS等都可以考慮用壓縮模式傳輸，那樣網路傳輸效率會更高一些。
12：由於全國各地上萬人，會有各種各樣的人，這些人也未必全是好人，可能某些人心情不好，或者其他什麼的，可能就會攻擊我們的軟體系統破壞數據，這些也可能是由於好奇心導致的，所以系統需要有嚴格的許可權管理控制，不應該進入的頁面絕對不能進入，不應該看的數據絕對不讓看，不能操作的功能絕對不讓多操作，一方面防止沒必要的多餘的麻煩，另一方面也可以減少系統被攻擊破壞的可能性。
4. 如何處理資料庫並發問題
想要知道如何處理數據並發，自然需要先了解數據並發。
什麼是數據並發操作呢？
就是同一時間內，不同的線程同時對一條數據進行讀寫操作。
在互聯網時代，一個系統常常有很多人在使用，因此就可能出現高並發的現象，也就是不同的用戶同時對一條數據進行操作，如果沒有有效的處理，自然就會出現數據的異常。而最常見的一種數據並發的場景就是電商中的秒殺，成千上萬個用戶對在極端的時間內，搶購一個商品。針對這種場景，商品的庫存就是一個需要控制的數據，而多個用戶對在同一時間對庫存進行重寫，一個不小心就可能出現超賣的情況。
針對這種情況，我們如何有效的處理數據並發呢？
第一種方案、資料庫鎖
從鎖的基本屬性來說，可以分為兩種：一種是共享鎖（S），一種是排它鎖（X）。在MySQL的資料庫中，是有四種隔離級別的，會在讀寫的時候，自動的使用這兩種鎖，防止數據出現混亂。
這四種隔離級別分別是：
讀未提交（Read Uncommitted）
讀提交（Read Committed）
可重復讀（Repeated Read）
串列化（Serializable）
當然，不同的隔離級別，效率也是不同的，對於數據的一致性保證也就有不同的結果。而這些可能出現的又有哪些呢？
臟讀（dirty read）
當事務與事務之間沒有任何隔離的時候，就可能會出現臟讀。例如：商家想看看所有的訂單有哪些，這時，用戶A提交了一個訂單，但事務還沒提交，商家卻看到了這個訂單。而這時就會出現一種問題，當商家去操作這個訂單時，可能用戶A的訂單由於部分問題，導致數據回滾，事務沒有提交，這時商家的操作就會失去目標。
不可重復讀（unrepeatable read）
一個事務中，兩次讀操作出來的同一條數據值不同，就是不可重復讀。
例如：我們有一個事務A，需要去查詢一下商品庫存，然後做扣減，這時，事務B操作了這個商品，扣減了一部分庫存，當事務A再次去查詢商品庫存的時候，發現這一次的結果和上次不同了，這就是不可重復讀。
幻讀（phantom problem）
一個事務中，兩次讀操作出來的結果集不同，就是幻讀。
例如：一個事務A，去查詢現在已經支付的訂單有哪些，得到了一個結果集。這時，事務B新提交了一個訂單，當事務A再次去查詢時，就會出現，兩次得到的結果集不同的情況，也就是幻讀了。
那針對這些結果，不同的隔離級別可以干什麼呢？
「讀未提（Read Uncommitted）」能預防啥？啥都預防不了。
「讀提交（Read Committed）」能預防啥？使用「快照讀（Snapshot Read）」方式，避免「臟讀」，但是可能出現「不可重復讀」和「幻讀」。
「可重復讀（Repeated Red）」能預防啥？使用「快照讀（Snapshot Read）」方式，鎖住被讀取記錄，避免出現「臟讀」、「不可重復讀」，但是可能出現「幻讀」。
「串列化（Serializable）」能預防啥？有效避免「臟讀」、「不可重復讀」、「幻讀」，不過運行效率奇差。
好了，鎖說完了，但是，我們的資料庫鎖，並不能有效的解決並發的問題，只是盡可能保證數據的一致性，當並發量特別大時，資料庫還是容易扛不住。那解決數據並發的另一個手段就是，盡可能的提高處理的速度。
因為數據的IO要提升難度比較大，那麼通過其他的方式，對數據進行處理，減少資料庫的IO，就是提高並發能力的有效手段了。
最有效的一種方式就是：緩存
想要減少並發出現的概率，那麼讀寫的效率越高，讀寫的執行時間越短，自然數據並發的可能性就變小了，並發性能也有提高了。
還是用剛才的秒殺舉例，我們為的就是保證庫存的數據不出錯，賣出一個商品，減一個庫存，那麼，我們就可以將庫存放在內存中進行處理。這樣，就能夠保證庫存有序的及時扣減，並且不出現問題。這樣，我們的資料庫的寫操作也變少了，執行效率也就大大提高了。
當然，常用的分布式緩存方式有：Redis和Memcache，Redis可以持久化到硬碟，而Memcache不行，應該怎麼選擇，就看具體的使用場景了。
當然，緩存畢竟使用的范圍有限，很多的數據我們還是必須持久化到硬碟中，那我們就需要提高資料庫的IO能力，這樣避免一個線程執行時間太長，造成線程的阻塞。
那麼，讀寫分離就是另一種有效的方式了
當我們的寫成為了瓶頸的時候，讀寫分離就是一種可以選擇的方式了。
我們的讀庫就只需要執行讀，寫庫就只需要執行寫，把讀的壓力從主庫中分離出去，讓主庫的資源只是用來保證寫的效率，從而提高寫操作的性能。
5. 如何查看高並發下mysql資料庫的性能
如何提高MySQL Limit查詢的性能?
在MySQL資料庫操作中，我們在做一些查詢的時候總希望能避免資料庫引擎做全表掃描，因為全表掃描時間長，而且其中大部分掃描對客戶端而言是沒有意義的。其實我們可以使用Limit關鍵字來避免全表掃描的情況，從而提高效率。
有個幾千萬條記錄的表 on MySQL 5.0.x，現在要讀出其中幾十萬萬條左右的記錄。常用方法，依次循環：
select * from mytable where index_col = xxx limit offset, limit;
經驗：如果沒有blob/text欄位，單行記錄比較小，可以把 limit 設大點，會加快速度。
問題：頭幾萬條讀取很快，但是速度呈線性下降，同時 mysql server cpu 99% ，速度不可接受。
調用 explain select * from mytable where index_col = xxx limit offset, limit;
顯示 type = ALL
在 MySQL optimization 的文檔寫到"All"的解釋
A full table scan is done for each combination of rows from the previous tables. This is normally not good if the table is the first table not marked const, and usually very bad in all other cases. Normally, you can avoid ALL by adding indexes that allow row retrieval from the table based on constant values or column values from earlier tables.
看樣子對於 all, mysql 就使用比較笨的方法，那就改用 range 方式？ 因為 id 是遞增的，也很好修改 sql 。
select * from mytable where id > offset and id < offset + limit and index_col = xxx
explain 顯示 type = range，結果速度非常理想，返回結果快了幾十倍。
Limit語法：
SELECT * FROM table LIMIT [offset,] rows | rows OFFSET offset
LIMIT子句可以被用於強制 SELECT 語句返回指定的記錄數。LIMIT接受一個或兩個數字參數。參數必須是一個整數常量。
如果給定兩個參數，第一個參數指定第一個返回記錄行的偏移量，第二個參數指定返回記錄行的最大數目。初始記錄行的偏移量是 0(而不是 1)。
為了與 PostgreSQL 兼容，MySQL 也支持句法：LIMIT # OFFSET #。
mysql> SELECT * FROM table LIMIT 5,10; //檢索記錄行6-15
//為了檢索從某一個偏移量到記錄集的結束所有的記錄行，可以指定第二個參數為-1
mysql> SELECT * FROM table LIMIT 95,-1; //檢索記錄行96-last
//如果只給定一個參數，它表示返回最大的記錄行數目，換句話說，LIMIT n 等價於 LIMIT 0,n
mysql> SELECT * FROM table LIMIT 5; //檢索前5個記錄行
MySQL的limit給分頁帶來了極大的方便，但數據量一大的時候，limit的性能就急劇下降。同樣是取10條數據，下面兩句就不是一個數量級別的。
select * from table limit 10000,10
select * from table limit 0,10
文中不是直接使用limit，而是首先獲取到offset的id然後直接使用limit size來獲取數據。根據他的數據，明顯要好於直接使用limit。
這里我具體使用數據分兩種情況進行測試。
1、offset比較小的時候：
select * from table limit 10,10
//多次運行，時間保持在0.0004-0.0005之間
Select * From table Where vid ＞=(Select vid From table Order By vid limit 10,1) limit 10
//多次運行，時間保持在0.0005-0.0006之間，主要是0.0006
結論：偏移offset較小的時候，直接使用limit較優。這個顯然是子查詢的原因。
2、offset大的時候：
select * from table limit 10000,10
//多次運行，時間保持在0.0187左右
Select * From table Where vid ＞=(Select vid From table Order By vid limit 10000,1) limit 10
//多次運行，時間保持在0.0061左右，只有前者的1/3。可以預計offset越大，後者越優。
6. 高並發的MySQL數據查詢時,會不會選擇資料庫連接池
好了，基本概念說完了，言歸正傳進行比較了。
首先說明的一點，為了應用便於移植以及可配置的角度，建議還是使用jndi統一進行連接池的配置。怎麼配置其實網上都有很多例子，
這里簡單舉個例子（使用spring框架）：
首先在應用的上下文定義中配置jndi名稱，如一個resource.xml文件，里邊的寫法
<bean id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiName"><value>jdbc/myapp</value></property>
</bean>
注意dataSource這個bean在層(hibernate或jdbc)的配置文件里需要作為dataSource名稱的屬性配置到所有bean中
其中「jdbc/myds」這個就是jndi名稱了，下一步就是在應用伺服器連接池裡進行資料庫連接以及對應的jndi配置了
7. 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事件循環中，當資料庫返回結果時會回調指定函數，這個過程是完全非同步非阻塞的。
8. 大數據量高並發訪問資料庫結構的設計
大數據量高並發訪問資料庫結構的設計
如果不能設計一個合理的資料庫模型，不僅會增加客戶端和伺服器段程序的編程和維護的難度，而且將會影響系統實際運行的性能。所以，在一個系統開始實施之前，完備的資料庫模型的設計是必須的。
在一個系統分析、設計階段，因為數據量較小，負荷較低。我們往往只注意到功能的實現，而很難注意到性能的薄弱之處，等到系統投入實際運行一段時間後，才發現系統的性能在降低，這時再來考慮提高系統性能則要花費更多的人力物力，而整個系統也不可避免的形成了一個打補丁工程。
所以在考慮整個系統的流程的時候，我們必須要考慮，在高並發大數據量的訪問情況下，我們的系統會不會出現極端的情況。（例如：對外統計系統在7月16日出現的數據異常的情況，並發大數據量的的訪問造成，資料庫的響應時間不能跟上數據刷新的速度造成。具體情況是：在日期臨界時（00：00：00），判斷資料庫中是否有當前日期的記錄，沒有則插入一條當前日期的記錄。在低並發訪問的情況下，不會發生問題，但是當日期臨界時的訪問量相當大的時候，在做這一判斷的時候，會出現多次條件成立，則資料庫里會被插入多條當前日期的記錄，從而造成數據錯誤。），資料庫的模型確定下來之後，我們有必要做一個系統內數據流向圖，分析可能出現的瓶頸。
為了保證資料庫的一致性和完整性，在邏輯設計的時候往往會設計過多的表間關聯，盡可能的降低數據的冗餘。（例如用戶表的地區，我們可以把地區另外存放到一個地區表中）如果數據冗餘低，數據的完整性容易得到保證，提高了數據吞吐速度，保證了數據的完整性，清楚地表達數據元素之間的關系。而對於多表之間的關聯查詢（尤其是大數據表）時，其性能將會降低，同時也提高了客戶端程序的編程難度，因此，物理設計需折衷考慮，根據業務規則，確定對關聯表的數據量大小、數據項的訪問頻度，對此類數據表頻繁的關聯查詢應適當提高數據冗餘設計但增加了表間連接查詢的操作，也使得程序的變得復雜，為了提高系統的響應時間，合理的數據冗餘也是必要的。設計人員在設計階段應根據系統操作的類型、頻度加以均衡考慮。
另外，最好不要用自增屬性欄位作為主鍵與子表關聯。不便於系統的遷移和數據恢復。對外統計系統映射關系丟失（******************）。
原來的表格必須可以通過由它分離出去的表格重新構建。使用這個規定的好處是，你可以確保不會在分離的表格中引入多餘的列，所有你創建的表格結構都與它們的實際需要一樣大。應用這條規定是一個好習慣，不過除非你要處理一個非常大型的數據，否則你將不需要用到它。（例如一個通行證系統，我可以將USERID，USERNAME，USERPASSWORD，單獨出來作個表，再把USERID作為其他表的外鍵）
表的設計具體注意的問題：
1、數據行的長度不要超過8020位元組，如果超過這個長度的話在物理頁中這條數據會佔用兩行從而造成存儲碎片，降低查詢效率。
2、能夠用數字類型的欄位盡量選擇數字類型而不用字元串類型的（電話號碼），這會降低查詢和連接的性能，並會增加存儲開銷。這是因為引擎在處理查詢和連接回逐個比較字元串中每一個字元，而對於數字型而言只需要比較一次就夠了。
3、對於不可變字元類型char和可變字元類型varchar都是8000位元組,char查詢快，但是耗存儲空間，varchar查詢相對慢一些但是節省存儲空間。在設計欄位的時候可以靈活選擇，例如用戶名、密碼等長度變化不大的欄位可以選擇CHAR，對於評論等長度變化大的欄位可以選擇VARCHAR。
4、欄位的長度在最大限度的滿足可能的需要的前提下，應該盡可能的設得短一些，這樣可以提高查詢的效率，而且在建立索引的時候也可以減少資源的消耗。
5、基本表及其欄位之間的關系, 應盡量滿足第三範式。但是，滿足第三範式的資料庫設計，往往不是最好的設計。為了提高資料庫的運行效率，常常需要降低範式標准：適當增加冗餘，達到以空間換時間的目的。
6、若兩個實體之間存在多對多的關系，則應消除這種關系。消除的辦法是，在兩者之間增加第三個實體。這樣，原來一個多對多的關系，現在變為兩個一對多的關系。要將原來兩個實體的屬性合理地分配到三個實體中去。這里的第三個實體，實質上是一個較復雜的關系，它對應一張基本表。一般來講，資料庫設計工具不能識別多對多的關系，但能處理多對多的關系。
7、主鍵PK的取值方法，PK是供程序員使用的表間連接工具，可以是一無物理意義的數字串, 由程序自動加1來實現。也可以是有物理意義的欄位名或欄位名的組合。不過前者比後者好。當PK是欄位名的組合時，建議欄位的個數不要太多，多了不但索引佔用空間大，而且速度也慢。
8、主鍵與外鍵在多表中的重復出現, 不屬於數據冗餘，這個概念必須清楚，事實上有許多人還不清楚。非鍵欄位的重復出現, 才是數據冗餘！而且是一種低級冗餘，即重復性的冗餘。高級冗餘不是欄位的重復出現，而是欄位的派生出現。
〖例4〗：商品中的「單價、數量、金額」三個欄位，「金額」就是由「單價」乘以「數量」派生出來的，它就是冗餘，而且是一種高級冗餘。冗餘的目的是為了提高處理速度。只有低級冗餘才會增加數據的不一致性，因為同一數據，可能從不同時間、地點、角色上多次錄入。因此，我們提倡高級冗餘(派生性冗餘)，反對低級冗餘(重復性冗餘)。
9、中間表是存放統計數據的表，它是為數據倉庫、輸出報表或查詢結果而設計的，有時它沒有主鍵與外鍵(數據倉庫除外)。臨時表是程序員個人設計的，存放臨時記錄，為個人所用。基表和中間表由DBA維護，臨時表由程序員自己用程序自動維護。
10、防止資料庫設計打補丁的方法是「三少原則」
(1) 一個資料庫中表的個數越少越好。只有表的個數少了，才能說明系統的E--R圖少而精，去掉了重復的多餘的實體，形成了對客觀世界的高度抽象，進行了系統的數據集成，防止了打補丁式的設計；
(2) 一個表中組合主鍵的欄位個數越少越好。因為主鍵的作用，一是建主鍵索引，二是做為子表的外鍵，所以組合主鍵的欄位個數少了，不僅節省了運行時間，而且節省了索引存儲空間；
(3) 一個表中的欄位個數越少越好。只有欄位的個數少了，才能說明在系統中不存在數據重復，且很少有數據冗餘，更重要的是督促讀者學會「列變行」，這樣就防止了將子表中的欄位拉入到主表中去，在主表中留下許多空餘的欄位。所謂「列變行」，就是將主表中的一部分內容拉出去，另外單獨建一個子表。這個方法很簡單，有的人就是不習慣、不採納、不執行。
資料庫設計的實用原則是：在數據冗餘和處理速度之間找到合適的平衡點。「三少」是一個整體概念，綜合觀點，不能孤立某一個原則。該原則是相對的，不是絕對的。「三多」原則肯定是錯誤的。試想：若覆蓋系統同樣的功能，一百個實體(共一千個屬性) 的E--R圖，肯定比二百個實體(共二千個屬性)的E--R圖，要好得多。
提倡「三少」原則，是叫讀者學會利用資料庫設計技術進行系統的數據集成。數據集成的步驟是將文件系統集成為應用資料庫，將應用資料庫集成為主題資料庫，將主題資料庫集成為全局綜合資料庫。集成的程度越高，數據共享性就越強，信息孤島現象就越少，整個企業信息系統的全局E—R圖中實體的個數、主鍵的個數、屬性的個數就會越少。
提倡「三少」原則的目的，是防止讀者利用打補丁技術，不斷地對資料庫進行增刪改，使企業資料庫變成了隨意設計資料庫表的「垃圾堆」，或資料庫表的「大雜院」，最後造成資料庫中的基本表、代碼表、中間表、臨時表雜亂無章，不計其數，導致企事業單位的信息系統無法維護而癱瘓。
「三多」原則任何人都可以做到，該原則是「打補丁方法」設計資料庫的歪理學說。「三少」原則是少而精的原則，它要求有較高的資料庫設計技巧與藝術，不是任何人都能做到的，因為該原則是杜絕用「打補丁方法」設計資料庫的理論依據。
11、在給定的系統硬體和系統軟體條件下，提高資料庫系統的運行效率的辦法是：
(1) 在資料庫物理設計時，降低範式，增加冗餘, 少用觸發器, 多用存儲過程。
(2) 當計算非常復雜、而且記錄條數非常巨大時(例如一千萬條)，復雜計算要先在資料庫外面，以文件系統方式用編程語言計算處理完成之後，最後才入庫追加到表中去。
(3) 發現某個表的記錄太多，例如超過一千萬條，則要對該表進行水平分割。水平分割的做法是，以該表主鍵PK的某個值為界線，將該表的記錄水平分割為兩個表。若發現某個表的欄位太多，例如超過八十個，則垂直分割該表，將原來的一個表分解為兩個表。
(4) 對資料庫管理系統DBMS進行系統優化，即優化各種系統參數，如緩沖區個數。
(5) 在使用面向數據的SQL語言進行程序設計時，盡量採取優化演算法。
總之，要提高資料庫的運行效率，必須從資料庫系統級優化、資料庫設計級優化、程序實現級優化，這三個層次上同時下功夫。
主鍵設計：
1、不建議用多個欄位做主鍵，單個表還可以，但是關聯關系就會有問題，主鍵自增是高性能的。
2、一般情況下，如果有兩個外鍵，不建議採用兩個外鍵作為聯合住建，另建一個欄位作為主鍵。除非這條記錄沒有邏輯刪除標志，且該表永遠只有一條此聯合主鍵的記錄。
3、一般而言，一個實體不能既無主鍵又無外鍵。在E—R 圖中, 處於葉子部位的實體, 可以定義主鍵，也可以不定義主鍵(因為它無子孫), 但必須要有外鍵(因為它有父親)。
主鍵與外鍵的設計，在全局資料庫的設計中，佔有重要地位。當全局資料庫的設計完成以後，有個美國資料庫設計專家說：「鍵，到處都是鍵，除了鍵之外，什麼也沒有」，這就是他的資料庫設計經驗之談，也反映了他對信息系統核心(數據模型)的高度抽象思想。因為：主鍵是實體的高度抽象，主鍵與、外鍵的配對，表示實體之間的連接。