本文目錄一覽:
- 1、mysql資料庫如何優化?誰能給出點具體的解決方案?
- 2、北大青鳥java培訓:mysql資料庫的優化方法?
- 3、Mysql資料庫優化可以從哪幾個方面優化
- 4、MySQL資料庫性能優化之分區分表分庫
- 5、資料庫如何優化
mysql資料庫如何優化?誰能給出點具體的解決方案?
1、explain:解釋sql的執行計劃,後邊的sql不執行
2、explain partitions :用於查看存在分區的表的執行計劃
3、explain extended:待驗證
4、show warnings:
5、show create table:查看錶的詳細的創建語句,便於用戶對錶進行優化
6、show indexes :產看錶的所有索引,show indexes from table_name,同樣也可以從information_schema.statistics表中獲得同樣的信息。cardinality列很重要,表示數據量。
7、show tables status: 查看資料庫表的底層大小以及表結構,同樣可以從information_schema.tables表中獲得底層表的信息。
8、show [global|session]status:可以查看mysql伺服器當前內部狀態信息。可以幫助卻行mysql伺服器的負載的各種指標。默認是session。同information_schema.global_status和information_schema.session_status
9、show [global|session] variables :查看當前mysql系統變數的值,其中一些值能影響到sql語句的執行方式。同information_schema.global_variables和information_schema.session_variables;
10、information_schema:包含的表的數量和mysql的版本有關係。
北大青鳥java培訓:mysql資料庫的優化方法?
我們都知道,伺服器資料庫的開發一般都是通過java或者是PHP語言來編程實現的,而為了提高我們資料庫的運行速度和效率,資料庫優化也成為了我們每日的工作重點,今天,福建IT培訓就一起來了解一下mysql伺服器資料庫的優化方法。
為什麼要了解索引真實案例案例一:大學有段時間學習爬蟲,爬取了知乎300w用戶答題數據,存儲到mysql數據中。
那時不了解索引,一條簡單的「根據用戶名搜索全部回答的sql「需要執行半分鐘左右,完全滿足不了正常的使用。
案例二:近線上應用的資料庫頻頻出現多條慢sql風險提示,而工作以來,對資料庫優化方面所知甚少。
例如一個用戶數據頁面需要執行很多次資料庫查詢,性能很慢,通過增加超時時間勉強可以訪問,但是性能上需要優化。
索引的優點合適的索引,可以大大減小mysql伺服器掃描的數據量,避免內存排序和臨時表,提高應用程序的查詢性能。
索引的類型mysql數據中有多種索引類型,primarykey,unique,normal,但底層存儲的數據結構都是BTREE;有些存儲引擎還提供hash索引,全文索引。
BTREE是常見的優化要面對的索引結構,都是基於BTREE的討論。
B-TREE查詢數據簡單暴力的方式是遍歷所有記錄;如果數據不重複,就可以通過組織成一顆排序二叉樹,通過二分查找演算法來查詢,大大提高查詢性能。
而BTREE是一種更強大的排序樹,支持多個分支,高度更低,數據的插入、刪除、更新更快。
現代資料庫的索引文件和文件系統的文件塊都被組織成BTREE。
btree的每個節點都包含有key,data和只想子節點指針。
btree有度的概念d=1。
假設btree的度為d,則每個內部節點可以有n=[d+1,2d+1)個key,n+1個子節點指針。
樹的大高度為h=Logb[(N+1)/2]。
索引和文件系統中,B-TREE的節點常設計成接近一個內存頁大小(也是磁碟扇區大小),且樹的度非常大。
這樣磁碟I/O的次數,就等於樹的高度h。
假設b=100,一百萬個節點的樹,h將只有3層。
即,只有3次磁碟I/O就可以查找完畢,性能非常高。
索引查詢建立索引後,合適的查詢語句才能大發揮索引的優勢。
另外,由於查詢優化器可以解析客戶端的sql語句,會調整sql的查詢語句的條件順序去匹配合適的索引。
Mysql資料庫優化可以從哪幾個方面優化
1、選取最適用的欄位屬性
MySQL可以很好的支持大數據量的存取,但是一般說來,資料庫中的表越小,在它上面執行的查詢也就會越快。因此,在創建表的時候,為了獲得更好的性能,我們可以將表中欄位的寬度設得儘可能小。
2、使用連接(JOIN)來代替子查詢(Sub-Queries)
MySQL從4.1開始支持SQL的子查詢。這個技術可以使用SELECT語句來創建一個單列的查詢結果,然後把這個結果作為過濾條件用在另一個查詢中。例如,我們要將客戶基本信息表中沒有任何訂單的客戶刪除掉,就可以利用子查詢先從銷售信息表中將所有發出訂單的客戶ID取出來,然後將結果傳遞給主查詢。
3、使用聯合(UNION)來代替手動創建的臨時表
MySQL從4.0的版本開始支持union查詢,它可以把需要使用臨時表的兩條或更多的select查詢合併的一個查詢中。在客戶端的查詢會話結束的時候,臨時表會被自動刪除,從而保證資料庫整齊、高效。使用union來創建查詢的時候,我們只需要用UNION作為關鍵字把多個select語句連接起來就可以了,要注意的是所有select語句中的欄位數目要想同。下面的例子就演示了一個使用UNION的查詢。
4、事務
儘管我們可以使用子查詢(Sub-Queries)、連接(JOIN)和聯合(UNION)來創建各種各樣的查詢,但不是所有的資料庫操作都可以只用一條或少數幾條SQL語句就可以完成的。更多的時候是需要用到一系列的語句來完成某種工作。但是在這種情況下,當這個語句塊中的某一條語句運行出錯的時候,整個語句塊的操作就會變得不確定起來。設想一下,要把某個數據同時插入兩個相關聯的表中,可能會出現這樣的情況:第一個表中成功更新後,資料庫突然出現意外狀況,造成第二個表中的操作沒有完成,這樣,就會造成數據的不完整,甚至會破壞資料庫中的數據。要避免這種情況,就應該使用事務,它的作用是:要麼語句塊中每條語句都操作成功,要麼都失敗。換句話說,就是可以保持資料庫中數據的一致性和完整性。事物以BEGIN關鍵字開始,COMMIT關鍵字結束。在這之間的一條SQL操作失敗,那麼,ROLLBACK命令就可以把資料庫恢復到BEGIN開始之前的狀態。
5、鎖定表
儘管事務是維護資料庫完整性的一個非常好的方法,但卻因為它的獨佔性,有時會影響資料庫的性能,尤其是在很大的應用系統中。由於在事務執行的過程中,資料庫將會被鎖定,因此其它的用戶請求只能暫時等待直到該事務結束。如果一個資料庫系統只有少數幾個用戶來使用,事務造成的影響不會成為一個太大的問題;但假設有成千上萬的用戶同時訪問一個資料庫系統,例如訪問一個電子商務網站,就會產生比較嚴重的響應延遲。其實,有些情況下我們可以通過鎖定表的方法來獲得更好的性能。
6、使用外鍵
鎖定表的方法可以維護數據的完整性,但是它卻不能保證數據的關聯性。這個時候我們就可以使用外鍵。
7、使用索引
索引是提高資料庫性能的常用方法,它可以令資料庫伺服器以比沒有索引快得多的速度檢索特定的行,尤其是在查詢語句當中包含有MAX(),MIN()和ORDERBY這些命令的時候,性能提高更為明顯。
希望可以幫到你,謝謝!
MySQL資料庫性能優化之分區分表分庫
分表是分散資料庫壓力的好方法。
分表,最直白的意思,就是將一個表結構分為多個表,然後,可以再同一個庫里,也可以放到不同的庫。
當然,首先要知道什麼情況下,才需要分表。個人覺得單表記錄條數達到百萬到千萬級別時就要使用分表了。
分表的分類
**1、縱向分表**
將本來可以在同一個表的內容,人為劃分為多個表。(所謂的本來,是指按照關係型資料庫的第三範式要求,是應該在同一個表的。)
分表理由:根據數據的活躍度進行分離,(因為不同活躍的數據,處理方式是不同的)
案例:
對於一個博客系統,文章標題,作者,分類,創建時間等,是變化頻率慢,查詢次數多,而且最好有很好的實時性的數據,我們把它叫做冷數據。而博客的瀏覽量,回複數等,類似的統計信息,或者別的變化頻率比較高的數據,我們把它叫做活躍數據。所以,在進行資料庫結構設計的時候,就應該考慮分表,首先是縱向分表的處理。
這樣縱向分表後:
首先存儲引擎的使用不同,冷數據使用MyIsam 可以有更好的查詢數據。活躍數據,可以使用Innodb ,可以有更好的更新速度。
其次,對冷數據進行更多的從庫配置,因為更多的操作時查詢,這樣來加快查詢速度。對熱數據,可以相對有更多的主庫的橫向分表處理。
其實,對於一些特殊的活躍數據,也可以考慮使用memcache ,redis之類的緩存,等累計到一定量再去更新資料庫。或者mongodb 一類的nosql 資料庫,這裡只是舉例,就先不說這個。
**2、橫向分表**
字面意思,就可以看出來,是把大的表結構,橫向切割為同樣結構的不同表,如,用戶信息表,user_1,user_2等。表結構是完全一樣,但是,根據某些特定的規則來劃分的表,如根據用戶ID來取模劃分。
分表理由:根據數據量的規模來劃分,保證單表的容量不會太大,從而來保證單表的查詢等處理能力。
案例:同上面的例子,博客系統。當博客的量達到很大時候,就應該採取橫向分割來降低每個單表的壓力,來提升性能。例如博客的冷數據表,假如分為100個表,當同時有100萬個用戶在瀏覽時,如果是單表的話,會進行100萬次請求,而現在分表後,就可能是每個表進行1萬個數據的請求(因為,不可能絕對的平均,只是假設),這樣壓力就降低了很多很多。
延伸:為什麼要分表和分區?
日常開發中我們經常會遇到大表的情況,所謂的大表是指存儲了百萬級乃至千萬級條記錄的表。這樣的表過於龐大,導致資料庫在查詢和插入的時候耗時太長,性能低下,如果涉及聯合查詢的情況,性能會更加糟糕。分表和表分區的目的就是減少資料庫的負擔,提高資料庫的效率,通常點來講就是提高表的增刪改查效率。
什麼是分表?
分表是將一個大表按照一定的規則分解成多張具有獨立存儲空間的實體表,我們可以稱為子表,每個表都對應三個文件,MYD數據文件,.MYI索引文件,.frm表結構文件。這些子表可以分布在同一塊磁碟上,也可以在不同的機器上。app讀寫的時候根據事先定義好的規則得到對應的子表名,然後去操作它。
什麼是分區?
分區和分表相似,都是按照規則分解表。不同在於分表將大表分解為若干個獨立的實體表,而分區是將數據分段劃分在多個位置存放,可以是同一塊磁碟也可以在不同的機器。分區後,表面上還是一張表,但數據散列到多個位置了。app讀寫的時候操作的還是大表名字,db自動去組織分區的數據。
**MySQL分表和分區有什麼聯繫呢?**
1、都能提高mysql的性高,在高並髮狀態下都有一個良好的表現。
2、分表和分區不矛盾,可以相互配合的,對於那些大訪問量,並且表數據比較多的表,我們可以採取分表和分區結合的方式(如果merge這種分表方式,不能和分區配合的話,可以用其他的分表試),訪問量不大,但是表數據很多的表,我們可以採取分區的方式等。
3、分表技術是比較麻煩的,需要手動去創建子表,app服務端讀寫時候需要計運算元表名。採用merge好一些,但也要創建子表和配置子表間的union關係。
4、表分區相對於分表,操作方便,不需要創建子表。
我們知道對於大型的互聯網應用,資料庫單表的數據量可能達到千萬甚至上億級別,同時面臨這高並發的壓力。Master-Slave結構只能對資料庫的讀能力進行擴展,寫操作還是集中在Master中,Master並不能無限制的掛接Slave庫,如果需要對資料庫的吞吐能力進行進一步的擴展,可以考慮採用分庫分表的策略。
**1、分表**
在分表之前,首先要選中合適的分表策略(以哪個字典為分表欄位,需要將數據分為多少張表),使數據能夠均衡的分布在多張表中,並且不影響正常的查詢。在企業級應用中,往往使用org_id(組織主鍵)做為分表欄位,在互聯網應用中往往是userid。在確定分表策略後,當數據進行存儲及查詢時,需要確定到哪張表裡去查找數據,
數據存放的數據表 = 分表欄位的內容 % 分表數量
**2、分庫**
分表能夠解決單表數據量過大帶來的查詢效率下降的問題,但是不能給資料庫的並發訪問帶來質的提升,面對高並發的寫訪問,當Master無法承擔高並發的寫入請求時,不管如何擴展Slave伺服器,都沒有意義了。我們通過對資料庫進行拆分,來提高資料庫的寫入能力,即所謂的分庫。分庫採用對關鍵字取模的方式,對資料庫進行路由。
數據存放的資料庫=分庫欄位的內容%資料庫的數量
**3、即分表又分庫**
資料庫分表可以解決單表海量數據的查詢性能問題,分庫可以解決單台資料庫的並發訪問壓力問題。
當資料庫同時面臨海量數據存儲和高並發訪問的時候,需要同時採取分表和分庫策略。一般分表分庫策略如下:
中間變數 = 關鍵字%(資料庫數量*單庫數據表數量)
庫 = 取整(中間變數/單庫數據表數量)
表 = (中間變數%單庫數據表數量)
實例:
1、分庫分表
很明顯,一個主表(也就是很重要的表,例如用戶表)無限制的增長勢必嚴重影響性能,分庫與分表是一個很不錯的解決途徑,也就是性能優化途徑,現在的案例是我們有一個1000多萬條記錄的用戶表members,查詢起來非常之慢,同事的做法是將其散列到100個表中,分別從members0到members99,然後根據mid分發記錄到這些表中,牛逼的代碼大概是這樣子:
複製代碼 代碼如下:
?php
for($i=0;$i 100; $i++ ){
//echo “CREATE TABLE db2.members{$i} LIKE db1.members
“;
echo “INSERT INTO members{$i} SELECT * FROM members WHERE mid%100={$i}
“;
}
?
2、不停機修改mysql表結構
同樣還是members表,前期設計的表結構不盡合理,隨著資料庫不斷運行,其冗餘數據也是增長巨大,同事使用了下面的方法來處理:
先創建一個臨時表:
/*創建臨時表*/
CREATE TABLE members_tmp LIKE members
然後修改members_tmp的表結構為新結構,接著使用上面那個for循環來導出數據,因為1000萬的數據一次性導出是不對的,mid是主鍵,一個區間一個區間的導,基本是一次導出5萬條吧,這裡略去了
接著重命名將新表替換上去:
/*這是個頗為經典的語句哈*/
RENAME TABLE members TO members_bak,members_tmp TO members;
就是這樣,基本可以做到無損失,無需停機更新表結構,但實際上RENAME期間表是被鎖死的,所以選擇在線少的時候操作是一個技巧。經過這個操作,使得原先8G多的表,一下子變成了2G多。
資料庫如何優化
body{
line-height:200%;
}
如何優化MySQL資料庫
當MySQL資料庫邂逅優化,它有好幾個意思,今天我們所指的是性能優化。
我們究竟該如何對MySQL資料庫進行優化呢?下面我就從MySQL對硬體的選擇、Mysql的安裝、my.cnf的優化、MySQL如何進行架構設計及數據切分等方面來說明這個問題。
1.伺服器物理硬體的優化
1)磁碟(I/O),MySQL每一秒鐘都在進行大量、複雜的查詢操作,對磁碟的讀寫量可想而知,所以推薦使用RAID1+0磁碟陣列,如果資金允許,可以選擇固態硬碟做RAID1+0;
2)cpu對Mysql的影響也是不容忽視的,建議選擇運算能力強悍的CPU。
2.MySQL應該採用編譯安裝的方式
MySQL資料庫的線上環境安裝,我建議採取編譯安裝,這樣性能會較大的提升。
3.MySQL配置文件的優化
1)skip
-name
-resolve,禁止MySQL對外部連接進行DNS解析,使用這一選項可以消除MySQL進行DNS解析的時間;
2)back_log
=
384,back_log指出在MySQL暫時停止響應新請求之前,短時間內的多少個請求可以被存在堆棧中,對於Linux系統而言,推薦設置小於512的整數。
3)如果key_reads太大,則應該把my.cnf中key_buffer_size變大,保持key_reads/key_read_requests至少在1/100以上,越小越好。
4.MySQL上線後根據status狀態進行適當優化
1)打開慢查詢日誌可能會對系統性能有一點點影響,如果你的MySQL是主-從結構,可以考慮打開其中一台從伺服器的慢查詢日誌,這樣既可以監控慢查詢,對系統性能影響也會很小。
2)MySQL伺服器過去的最大連接數是245,沒有達到伺服器連接數的上限256,應該不會出現1040錯誤。比較理想的設置是:Max_used_connections/max_connections
*
100%
=85%
5.MySQL資料庫的可擴展架構方案
1)MySQL
cluster,其特點為可用性非常高,性能非常好,但它的維護非常複雜,存在部分Bug;
2)DRBD磁碟網路鏡像方案,其特點為軟體功能強大,數據可在底層塊設備級別跨物理主機鏡像,且可根據性能和可靠性要求配置不同級別的同步。
原創文章,作者:小藍,如若轉載,請註明出處:https://www.506064.com/zh-tw/n/293582.html