MySQL常用優(yōu)化方案

語(yǔ)句執(zhí)行后，會(huì)顯示三個(gè)字段： Query_ID（執(zhí)行ID） | Duration（持續(xù)時(shí)間）| Query（查詢(xún)語(yǔ)句） ；

創(chuàng)新互聯(lián)-專(zhuān)業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性?xún)r(jià)比尤溪網(wǎng)站開(kāi)發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫(kù),直接使用。一站式尤溪網(wǎng)站制作公司更省心,省錢(qián),快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋尤溪地區(qū)。費(fèi)用合理售后完善，10年實(shí)體公司更值得信賴(lài)。

拿到后Query_ID后，可執(zhí)行 show profile for query Query_ID ，查看詳細(xì)的準(zhǔn)備時(shí)間，執(zhí)行時(shí)間、執(zhí)行結(jié)束（ preparing、executing、end ）等。

顯示用戶(hù)正在運(yùn)行的線程，需要注意的是，除了 root 用戶(hù)能看到所有正在運(yùn)行的線程外，其他用戶(hù)都只能看到自己正在運(yùn)行的線程，看不到其它用戶(hù)正在運(yùn)行的線程。除非單獨(dú)個(gè)這個(gè)用戶(hù)賦予了PROCESS 權(quán)限。

顯示字段包含： User| Host| db | Command | Time| State| Info 等。

解析語(yǔ)句，查詢(xún)是否命中索引，及，命中何種索引，用以判斷是否符合我們的預(yù)期。

返回字段包含： select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra 等。

select_type 常見(jiàn)類(lèi)型：

(1) SIMPLE(簡(jiǎn)單SELECT，不使用UNION或子查詢(xún)等)

(2) PRIMARY(子查詢(xún)中最外層查詢(xún)，查詢(xún)中若包含任何復(fù)雜的子部分，最外層的select被標(biāo)記為PRIMARY)

(3) UNION(UNION中的第二個(gè)或后面的SELECT語(yǔ)句)

(4) SUBQUERY(子查詢(xún)中的第一個(gè)SELECT，結(jié)果不依賴(lài)于外部查詢(xún))

table 常見(jiàn)類(lèi)型：

顯示這一行的數(shù)據(jù)是關(guān)于哪張表的.

有時(shí)不是真實(shí)的表名字,看到的是derivedx(x是個(gè)數(shù)字,我的理解是第幾步執(zhí)行的結(jié)果)

type 常見(jiàn)類(lèi)型：

對(duì)表訪問(wèn)方式，表示MySQL在表中找到所需行的方式，又稱(chēng)“訪問(wèn)類(lèi)型”。

常用的類(lèi)型有： ALL、index、range、 ref、eq_ref、const、system、NULL （從左到右，性能從差到好）

possible_keys

指出MySQL能使用哪個(gè)索引在表中找到記錄，查詢(xún)涉及到的字段上若存在索引，則該索引將被列出，但不一定被查詢(xún)使用（該查詢(xún)可以利用的索引，如果沒(méi)有任何索引顯示 null）

該列完全獨(dú)立于EXPLAIN輸出所示的表的次序。這意味著在possible_keys中的某些鍵實(shí)際上不能按生成的表次序使用。

如果該列是NULL，則沒(méi)有相關(guān)的索引。在這種情況下，可以通過(guò)檢查WHERE子句看是否它引用某些列或適合索引的列來(lái)提高你的查詢(xún)性能。如果是這樣，創(chuàng)造一個(gè)適當(dāng)?shù)乃饕⑶以俅斡肊XPLAIN檢查查詢(xún)

key

key列顯示MySQL實(shí)際決定使用的鍵（索引），必然包含在possible_keys中

如果沒(méi)有選擇索引，鍵是NULL。要想強(qiáng)制MySQL使用或忽視possible_keys列中的索引，在查詢(xún)中使用FORCE INDEX、USE INDEX或者IGNORE INDEX。

key_len

表示索引中使用的字節(jié)數(shù)，可通過(guò)該列計(jì)算查詢(xún)中使用的索引的長(zhǎng)度，非實(shí)際長(zhǎng)度，為最大可能長(zhǎng)度。

注：不損失精確性的情況下，長(zhǎng)度越短越好。

ref

列與索引的比較，表示上述表的連接匹配條件，即哪些列或常量被用于查找索引列上的值。

rows

估算出結(jié)果集行數(shù)，表示MySQL根據(jù)表統(tǒng)計(jì)信息及索引選用情況，估算的找到所需的記錄所需要讀取的行數(shù)；

extra

該列包含MySQL解決查詢(xún)的詳細(xì)信息,有以下幾種情況：

(1).Distinct

一旦MYSQL找到了與行相聯(lián)合匹配的行，就不再搜索了

(2).Not exists

MYSQL優(yōu)化了LEFT JOIN，一旦它找到了匹配LEFT JOIN標(biāo)準(zhǔn)的行，就不再搜索了

(3).Range checked for each

Record（index map:#）

沒(méi)有找到理想的索引，因此對(duì)于從前面表中來(lái)的每一個(gè)行組合，MYSQL檢查使用哪個(gè)索引，并用它來(lái)從表中返回行。這是使用索引的最慢的連接之一

(4).Using filesort

看到這個(gè)的時(shí)候，查詢(xún)就需要優(yōu)化了。MYSQL需要進(jìn)行額外的步驟來(lái)發(fā)現(xiàn)如何對(duì)返回的行排序。它根據(jù)連接類(lèi)型以及存儲(chǔ)排序鍵值和匹配條件的全部行的行指針來(lái)排序全部行；

(5).Using temporary

看到這個(gè)的時(shí)候，查詢(xún)需要優(yōu)化了。這里，MYSQL需要?jiǎng)?chuàng)建一個(gè)臨時(shí)表來(lái)存儲(chǔ)結(jié)果，這通常發(fā)生在對(duì)不同的列集進(jìn)行ORDER BY上，而不是GROUP BY上；

(6).Using index

列數(shù)據(jù)是從僅僅使用了索引中的信息而沒(méi)有讀取實(shí)際的行動(dòng)的表返回的，這發(fā)生在對(duì)表的全部的請(qǐng)求列都是同一個(gè)索引的部分的時(shí)候。

(7).Using where

使用了WHERE從句來(lái)限制哪些行將與下一張表匹配或者是返回給用戶(hù)。如果不想返回表中的全部行，并且連接類(lèi)型ALL或index，這就會(huì)發(fā)生，或者是查詢(xún)有問(wèn)題。

mysql如何優(yōu)化以下語(yǔ)句，查詢(xún)耗時(shí)太久了？

根據(jù)所描述的問(wèn)題，可嘗試在mms_profitcenter 的FOrderID ，F(xiàn)Suffix列上建立索引，再查詢(xún)?cè)囋嚒?下面提供30種mysql常用優(yōu)化方法供參考：

1.對(duì)查詢(xún)進(jìn)行優(yōu)化，應(yīng)盡量避免全表掃描，首先應(yīng)考慮在 where 及 order by 涉及的列上建立索引。

2.應(yīng)盡量避免在 where 子句中使用!=或操作符，否則將引擎放棄使用索引而進(jìn)行全表掃描。

3.應(yīng)盡量避免在 where 子句中對(duì)字段進(jìn)行 null 值判斷，否則將導(dǎo)致引擎放棄使用索引而進(jìn)行全表掃描，如：

select id from t where num is null

可以在num上設(shè)置默認(rèn)值0，確保表中num列沒(méi)有null值，然后這樣查詢(xún)：

select id from t where num=0

4.應(yīng)盡量避免在 where 子句中使用 or 來(lái)連接條件，否則將導(dǎo)致引擎放棄使用索引而進(jìn)行全表掃描，如：

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

可以這樣查詢(xún)：

select id from t where num=10

union all

select id from t where num=20

5.下面的查詢(xún)也將導(dǎo)致全表掃描：

select id from t where name like '%abc%'

若要提高效率，可以考慮全文檢索。

6.in 和 not in 也要慎用，否則會(huì)導(dǎo)致全表掃描，如：

select id from t where num in(1,2,3)

對(duì)于連續(xù)的數(shù)值，能用 between 就不要用 in 了：

select id from t where num between 1 and 3

7.如果在 where 子句中使用參數(shù)，也會(huì)導(dǎo)致全表掃描。因?yàn)镾QL只有在運(yùn)行時(shí)才會(huì)解析局部變量，但優(yōu)化程序不能將訪問(wèn)計(jì)劃的選擇推遲到運(yùn)行時(shí)；它必須在編譯時(shí)進(jìn)行選擇。然而，如果在編譯時(shí)建立訪問(wèn)計(jì)劃，變量的值還是未知的，因而無(wú)法作為索引選擇的輸入項(xiàng)。如下面語(yǔ)句將進(jìn)行全表掃描：

select id from t where num=@num

可以改為強(qiáng)制查詢(xún)使用索引：

select id from t with(index(索引名)) where num=@num

8.應(yīng)盡量避免在 where 子句中對(duì)字段進(jìn)行表達(dá)式操作，這將導(dǎo)致引擎放棄使用索引而進(jìn)行全表掃描。如：

select id from t where num/2=100

應(yīng)改為:

select id from t where num=100*2

9.應(yīng)盡量避免在where子句中對(duì)字段進(jìn)行函數(shù)操作，這將導(dǎo)致引擎放棄使用索引而進(jìn)行全表掃描。如：

select id from t where substring(name,1,3)='abc'--name以abc開(kāi)頭的id

select id from t where datediff(day,createdate,'2005-11-30')=0--'2005-11-30'生成的id

應(yīng)改為:

select id from t where name like 'abc%'

select id from t where createdate='2005-11-30' and createdate'2005-12-1'

10.不要在 where 子句中的“=”左邊進(jìn)行函數(shù)、算術(shù)運(yùn)算或其他表達(dá)式運(yùn)算，否則系統(tǒng)將可能無(wú)法正確使用索引。

11.在使用索引字段作為條件時(shí)，如果該索引是復(fù)合索引，那么必須使用到該索引中的第一個(gè)字段作為條件時(shí)才能保證系統(tǒng)使用該索引，否則該索引將不會(huì)被使用，并且應(yīng)盡可能的讓字段順序與索引順序相一致。

12.不要寫(xiě)一些沒(méi)有意義的查詢(xún)，如需要生成一個(gè)空表結(jié)構(gòu)：

select col1,col2 into #t from t where 1=0

這類(lèi)代碼不會(huì)返回任何結(jié)果集，但是會(huì)消耗系統(tǒng)資源的，應(yīng)改成這樣：

create table #t(...)

13.很多時(shí)候用 exists 代替 in 是一個(gè)好的選擇：

select num from a where num in(select num from b)

用下面的語(yǔ)句替換：

select num from a where exists(select 1 from b where num=a.num)

14.并不是所有索引對(duì)查詢(xún)都有效，SQL是根據(jù)表中數(shù)據(jù)來(lái)進(jìn)行查詢(xún)優(yōu)化的，當(dāng)索引列有大量數(shù)據(jù)重復(fù)時(shí)，SQL查詢(xún)可能不會(huì)去利用索引，如一表中有字段sex，male、female幾乎各一半，那么即使在sex上建了索引也對(duì)查詢(xún)效率起不了作用。

15.索引并不是越多越好，索引固然可以提高相應(yīng)的 select 的效率，但同時(shí)也降低了 insert 及 update 的效率，因?yàn)?insert 或 update 時(shí)有可能會(huì)重建索引，所以怎樣建索引需要慎重考慮，視具體情況而定。一個(gè)表的索引數(shù)最好不要超過(guò)6個(gè)，若太多則應(yīng)考慮一些不常使用到的列上建的索引是否有必要。

16.應(yīng)盡可能的避免更新 clustered 索引數(shù)據(jù)列，因?yàn)?clustered 索引數(shù)據(jù)列的順序就是表記錄的物理存儲(chǔ)順序，一旦該列值改變將導(dǎo)致整個(gè)表記錄的順序的調(diào)整，會(huì)耗費(fèi)相當(dāng)大的資源。若應(yīng)用系統(tǒng)需要頻繁更新 clustered 索引數(shù)據(jù)列，那么需要考慮是否應(yīng)將該索引建為 clustered 索引。

17.盡量使用數(shù)字型字段，若只含數(shù)值信息的字段盡量不要設(shè)計(jì)為字符型，這會(huì)降低查詢(xún)和連接的性能，并會(huì)增加存儲(chǔ)開(kāi)銷(xiāo)。這是因?yàn)橐嬖谔幚聿樵?xún)和連接時(shí)會(huì)逐個(gè)比較字符串中每一個(gè)字符，而對(duì)于數(shù)字型而言只需要比較一次就夠了。

18.盡可能的使用 varchar/nvarchar 代替 char/nchar ，因?yàn)槭紫茸冮L(zhǎng)字段存儲(chǔ)空間小，可以節(jié)省存儲(chǔ)空間，其次對(duì)于查詢(xún)來(lái)說(shuō)，在一個(gè)相對(duì)較小的字段內(nèi)搜索效率顯然要高些。

19.任何地方都不要使用 select * from t ，用具體的字段列表代替“*”，不要返回用不到的任何字段。

20.盡量使用表變量來(lái)代替臨時(shí)表。如果表變量包含大量數(shù)據(jù)，請(qǐng)注意索引非常有限（只有主鍵索引）。

21.避免頻繁創(chuàng)建和刪除臨時(shí)表，以減少系統(tǒng)表資源的消耗。

22.臨時(shí)表并不是不可使用，適當(dāng)?shù)厥褂盟鼈兛梢允鼓承├谈行В?，?dāng)需要重復(fù)引用大型表或常用表中的某個(gè)數(shù)據(jù)集時(shí)。但是，對(duì)于一次性事件，最好使用導(dǎo)出表。

23.在新建臨時(shí)表時(shí)，如果一次性插入數(shù)據(jù)量很大，那么可以使用 select into 代替 create table，避免造成大量 log ，以提高速度；如果數(shù)據(jù)量不大，為了緩和系統(tǒng)表的資源，應(yīng)先create table，然后insert。

24.如果使用到了臨時(shí)表，在存儲(chǔ)過(guò)程的最后務(wù)必將所有的臨時(shí)表顯式刪除，先 truncate table ，然后 drop table ，這樣可以避免系統(tǒng)表的較長(zhǎng)時(shí)間鎖定。

25.盡量避免使用游標(biāo)，因?yàn)橛螛?biāo)的效率較差，如果游標(biāo)操作的數(shù)據(jù)超過(guò)1萬(wàn)行，那么就應(yīng)該考慮改寫(xiě)。

26.使用基于游標(biāo)的方法或臨時(shí)表方法之前，應(yīng)先尋找基于集的解決方案來(lái)解決問(wèn)題，基于集的方法通常更有效。

27.與臨時(shí)表一樣，游標(biāo)并不是不可使用。對(duì)小型數(shù)據(jù)集使用 FAST_FORWARD 游標(biāo)通常要優(yōu)于其他逐行處理方法，尤其是在必須引用幾個(gè)表才能獲得所需的數(shù)據(jù)時(shí)。在結(jié)果集中包括“合計(jì)”的例程通常要比使用游標(biāo)執(zhí)行的速度快。如果開(kāi)發(fā)時(shí)間允許，基于游標(biāo)的方法和基于集的方法都可以嘗試一下，看哪一種方法的效果更好。

28.在所有的存儲(chǔ)過(guò)程和觸發(fā)器的開(kāi)始處設(shè)置 SET NOCOUNT ON ，在結(jié)束時(shí)設(shè)置 SET NOCOUNT OFF 。無(wú)需在執(zhí)行存儲(chǔ)過(guò)程和觸發(fā)器的每個(gè)語(yǔ)句后向客戶(hù)端發(fā)送 DONE_IN_PROC 消息。

29.盡量避免向客戶(hù)端返回大數(shù)據(jù)量，若數(shù)據(jù)量過(guò)大，應(yīng)該考慮相應(yīng)需求是否合理。

30.盡量避免大事務(wù)操作，提高系統(tǒng)并發(fā)能力。

MySQL 查詢(xún)優(yōu)化（六）： MySQL 的查詢(xún)優(yōu)化排序優(yōu)化機(jī)制

對(duì)結(jié)果進(jìn)行排序操作的代價(jià)可能很高，因此可以通過(guò)避免排序或讓參與排序的數(shù)據(jù)行更少來(lái)優(yōu)化查詢(xún)性能。

當(dāng) MySQL 不能使用索引產(chǎn)生有序結(jié)果時(shí)，它必須對(duì)數(shù)據(jù)行進(jìn)行排序。這有可能是在內(nèi)存中進(jìn)行也可能是在磁盤(pán)進(jìn)行，但 MySQL 始終將這個(gè)過(guò)程稱(chēng)之為 filesort，即便實(shí)際上并沒(méi)有使用一個(gè)文件。

如果用于排序的值可以一次性放入排序緩存中，MySQL 可以在內(nèi)存中使用快排算法進(jìn)行排序。如果 MySQL 不能在內(nèi)存中進(jìn)行排序，則會(huì)在磁盤(pán)中按塊逐塊排序。它對(duì)每個(gè)塊使用快排算法，然后在將這些排序好的塊合并到結(jié)果中。

有兩個(gè)文件排序（filesort）算法：

很難說(shuō)哪種算法更有效，對(duì)每個(gè)算法來(lái)說(shuō)都會(huì)有最優(yōu)和最壞案例。MySQL 在數(shù)據(jù)表全部列加上用于排序的列的大小不超過(guò) max_length_for_sort_data 時(shí)會(huì)使用單次遍歷算法。可以通過(guò)修改這個(gè)參數(shù)影響排序算法的選擇。

需要注意的是，MySQL 的 filesort使用的臨時(shí)存儲(chǔ)空間可能會(huì)超出你的預(yù)期，這是因?yàn)樗鼘?duì)每個(gè)排序元素都分配了固定大小的存儲(chǔ)空間。這些存儲(chǔ)空間要足夠大以便容下存儲(chǔ)最大的元素，而且 VARCHAR這類(lèi)字段使用的是對(duì)應(yīng)的最大長(zhǎng)度。而且，如果使用的是 UTF-8字符集，MuSQL 會(huì)對(duì)每個(gè)字符分配3個(gè)字節(jié)。結(jié)果是，我們會(huì)發(fā)現(xiàn)那些沒(méi)怎么優(yōu)化的查詢(xún)會(huì)導(dǎo)致磁盤(pán)上的臨時(shí)存儲(chǔ)空間是數(shù)據(jù)表自身存儲(chǔ)空間的好幾倍。

而在對(duì)聯(lián)合查詢(xún)進(jìn)行排序時(shí)，MySQL 可能會(huì)在查詢(xún)執(zhí)行過(guò)程中執(zhí)行兩次文件排序。如果 ORDER BY 子句只是引用聯(lián)合查詢(xún)的第一張表，MySQL 可以先對(duì)這個(gè)表進(jìn)行文件排序，然后再處理聯(lián)合查詢(xún)。如果是這種情況，在 EXPLAIN 時(shí)會(huì)在 Extra 字段顯示“Using filesort”。而對(duì)于其他的排序情況——例如排序不是針對(duì)第一張表，或者是 ORDER BY 使用的列對(duì)應(yīng)了不止一個(gè)數(shù)據(jù)表，MySQL 必須使用臨時(shí)表緩存查詢(xún)結(jié)果，然而在聯(lián)合查詢(xún)完成后，再對(duì)臨時(shí)表進(jìn)行文件排序。在這種情況下，EXPLAIN 會(huì)在 Extra 字段顯示“Using temorary; Using filesort”。如果包含 LIMIT 約束的話，會(huì)發(fā)生在文件排序后，因此臨時(shí)表和文件排序的存儲(chǔ)空間可能非常大。

MySQL 5.6在只需要對(duì)數(shù)據(jù)行的子集（例如 LIMIT）進(jìn)行排序時(shí)，引入了一個(gè)重大改進(jìn)。相對(duì)于對(duì)整個(gè)結(jié)果集進(jìn)行排序再返回部分?jǐn)?shù)據(jù)，MySQL 有時(shí)候會(huì)在排序的時(shí)候直接丟棄掉不需要的數(shù)據(jù)行來(lái)提高效率。不管怎么樣，排序也需要小心使用，很可能會(huì)導(dǎo)致存儲(chǔ)占用的飆升最終導(dǎo)致系統(tǒng)負(fù)荷過(guò)大。

超詳細(xì)MySQL數(shù)據(jù)庫(kù)優(yōu)化

數(shù)據(jù)庫(kù)優(yōu)化一方面是找出系統(tǒng)的瓶頸,提高M(jìn)ySQL數(shù)據(jù)庫(kù)的整體性能,而另一方面需要合理的結(jié)構(gòu)設(shè)計(jì)和參數(shù)調(diào)整,以提高用戶(hù)的相應(yīng)速度,同時(shí)還要盡可能的節(jié)約系統(tǒng)資源,以便讓系統(tǒng)提供更大的負(fù)荷.

1. 優(yōu)化一覽圖

2. 優(yōu)化

筆者將優(yōu)化分為了兩大類(lèi),軟優(yōu)化和硬優(yōu)化,軟優(yōu)化一般是操作數(shù)據(jù)庫(kù)即可,而硬優(yōu)化則是操作服務(wù)器硬件及參數(shù)設(shè)置.

2.1 軟優(yōu)化

2.1.1 查詢(xún)語(yǔ)句優(yōu)化

1.首先我們可以用EXPLAIN或DESCRIBE(簡(jiǎn)寫(xiě):DESC)命令分析一條查詢(xún)語(yǔ)句的執(zhí)行信息.

2.例:

顯示:

其中會(huì)顯示索引和查詢(xún)數(shù)據(jù)讀取數(shù)據(jù)條數(shù)等信息.

2.1.2 優(yōu)化子查詢(xún)

在MySQL中,盡量使用JOIN來(lái)代替子查詢(xún).因?yàn)樽硬樵?xún)需要嵌套查詢(xún),嵌套查詢(xún)時(shí)會(huì)建立一張臨時(shí)表,臨時(shí)表的建立和刪除都會(huì)有較大的系統(tǒng)開(kāi)銷(xiāo),而連接查詢(xún)不會(huì)創(chuàng)建臨時(shí)表,因此效率比嵌套子查詢(xún)高.

2.1.3 使用索引

索引是提高數(shù)據(jù)庫(kù)查詢(xún)速度最重要的方法之一,關(guān)于索引可以參高筆者M(jìn)ySQL數(shù)據(jù)庫(kù)索引一文,介紹比較詳細(xì),此處記錄使用索引的三大注意事項(xiàng):

2.1.4 分解表

對(duì)于字段較多的表,如果某些字段使用頻率較低,此時(shí)應(yīng)當(dāng),將其分離出來(lái)從而形成新的表,

2.1.5 中間表

對(duì)于將大量連接查詢(xún)的表可以創(chuàng)建中間表,從而減少在查詢(xún)時(shí)造成的連接耗時(shí).

2.1.6 增加冗余字段

類(lèi)似于創(chuàng)建中間表,增加冗余也是為了減少連接查詢(xún).

2.1.7 分析表,,檢查表,優(yōu)化表

分析表主要是分析表中關(guān)鍵字的分布,檢查表主要是檢查表中是否存在錯(cuò)誤,優(yōu)化表主要是消除刪除或更新造成的表空間浪費(fèi).

1. 分析表: 使用 ANALYZE 關(guān)鍵字,如ANALYZE TABLE user;

2. 檢查表: 使用 CHECK關(guān)鍵字,如CHECK TABLE user [option]

option 只對(duì)MyISAM有效,共五個(gè)參數(shù)值:

3. 優(yōu)化表:使用OPTIMIZE關(guān)鍵字,如OPTIMIZE [LOCAL|NO_WRITE_TO_BINLOG] TABLE user;

LOCAL|NO_WRITE_TO_BINLOG都是表示不寫(xiě)入日志.,優(yōu)化表只對(duì)VARCHAR,BLOB和TEXT有效,通過(guò)OPTIMIZE TABLE語(yǔ)句可以消除文件碎片,在執(zhí)行過(guò)程中會(huì)加上只讀鎖.

2.2 硬優(yōu)化

2.2.1 硬件三件套

1.配置多核心和頻率高的cpu,多核心可以執(zhí)行多個(gè)線程.

2.配置大內(nèi)存,提高內(nèi)存,即可提高緩存區(qū)容量,因此能減少磁盤(pán)I/O時(shí)間,從而提高響應(yīng)速度.

3.配置高速磁盤(pán)或合理分布磁盤(pán):高速磁盤(pán)提高I/O,分布磁盤(pán)能提高并行操作的能力.

2.2.2 優(yōu)化數(shù)據(jù)庫(kù)參數(shù)

優(yōu)化數(shù)據(jù)庫(kù)參數(shù)可以提高資源利用率,從而提高M(jìn)ySQL服務(wù)器性能.MySQL服務(wù)的配置參數(shù)都在my.cnf或my.ini,下面列出性能影響較大的幾個(gè)參數(shù).

2.2.3 分庫(kù)分表

因?yàn)閿?shù)據(jù)庫(kù)壓力過(guò)大，首先一個(gè)問(wèn)題就是高峰期系統(tǒng)性能可能會(huì)降低，因?yàn)閿?shù)據(jù)庫(kù)負(fù)載過(guò)高對(duì)性能會(huì)有影響。另外一個(gè)，壓力過(guò)大把你的數(shù)據(jù)庫(kù)給搞掛了怎么辦？所以此時(shí)你必須得對(duì)系統(tǒng)做分庫(kù)分表 + 讀寫(xiě)分離，也就是把一個(gè)庫(kù)拆分為多個(gè)庫(kù)，部署在多個(gè)數(shù)據(jù)庫(kù)服務(wù)上，這時(shí)作為主庫(kù)承載寫(xiě)入請(qǐng)求。然后每個(gè)主庫(kù)都掛載至少一個(gè)從庫(kù)，由從庫(kù)來(lái)承載讀請(qǐng)求。

2.2.4 緩存集群

如果用戶(hù)量越來(lái)越大，此時(shí)你可以不停的加機(jī)器，比如說(shuō)系統(tǒng)層面不停加機(jī)器，就可以承載更高的并發(fā)請(qǐng)求。然后數(shù)據(jù)庫(kù)層面如果寫(xiě)入并發(fā)越來(lái)越高，就擴(kuò)容加數(shù)據(jù)庫(kù)服務(wù)器，通過(guò)分庫(kù)分表是可以支持?jǐn)U容機(jī)器的，如果數(shù)據(jù)庫(kù)層面的讀并發(fā)越來(lái)越高，就擴(kuò)容加更多的從庫(kù)。但是這里有一個(gè)很大的問(wèn)題：數(shù)據(jù)庫(kù)其實(shí)本身不是用來(lái)承載高并發(fā)請(qǐng)求的，所以通常來(lái)說(shuō)，數(shù)據(jù)庫(kù)單機(jī)每秒承載的并發(fā)就在幾千的數(shù)量級(jí)，而且數(shù)據(jù)庫(kù)使用的機(jī)器都是比較高配置，比較昂貴的機(jī)器，成本很高。如果你就是簡(jiǎn)單的不停的加機(jī)器，其實(shí)是不對(duì)的。所以在高并發(fā)架構(gòu)里通常都有緩存這個(gè)環(huán)節(jié)，緩存系統(tǒng)的設(shè)計(jì)就是為了承載高并發(fā)而生。所以單機(jī)承載的并發(fā)量都在每秒幾萬(wàn)，甚至每秒數(shù)十萬(wàn)，對(duì)高并發(fā)的承載能力比數(shù)據(jù)庫(kù)系統(tǒng)要高出一到兩個(gè)數(shù)量級(jí)。所以你完全可以根據(jù)系統(tǒng)的業(yè)務(wù)特性，對(duì)那種寫(xiě)少讀多的請(qǐng)求，引入緩存集群。具體來(lái)說(shuō)，就是在寫(xiě)數(shù)據(jù)庫(kù)的時(shí)候同時(shí)寫(xiě)一份數(shù)據(jù)到緩存集群里，然后用緩存集群來(lái)承載大部分的讀請(qǐng)求。這樣的話，通過(guò)緩存集群，就可以用更少的機(jī)器資源承載更高的并發(fā)。

一個(gè)完整而復(fù)雜的高并發(fā)系統(tǒng)架構(gòu)中，一定會(huì)包含：各種復(fù)雜的自研基礎(chǔ)架構(gòu)系統(tǒng)。各種精妙的架構(gòu)設(shè)計(jì).因此一篇小文頂多具有拋磚引玉的效果,但是數(shù)據(jù)庫(kù)優(yōu)化的思想差不多就這些了.

MySQL查詢(xún)優(yōu)化

通過(guò)慢查詢(xún)?nèi)罩菊页鲂什畹腟QL, 再進(jìn)一步判斷索引是否高效;

analyze table score;

explain select * from score where falseG;

盡量使用數(shù)值操作;

“小”類(lèi)型夠用，就不要選用“大”類(lèi)型;

MyISAM中，盡量使用固定長(zhǎng)度數(shù)據(jù)列，減少存儲(chǔ)碎片的發(fā)生；

對(duì)于Memory，InnoDB引擎，固定長(zhǎng)度還是可變長(zhǎng)度，不影響性能；

如果字符串?dāng)?shù)據(jù)列的不同取值的個(gè)數(shù)是有限的，就應(yīng)該把它轉(zhuǎn)換為ENUM數(shù)據(jù)列;

select * from score procedure analyse();

1) MyISAM表消除碎片: optimize table president;

2) 導(dǎo)出導(dǎo)入, 適用所有存儲(chǔ)引擎

mysqldump sampdb president dump.sql;

mysql sampdb dump.sql

批量加載數(shù)據(jù)比單行數(shù)據(jù)加載效率高;

無(wú)索引表比有索引表, 更快;

SQL語(yǔ)句短比SQL語(yǔ)句長(zhǎng), 更快;

加載效率比較: load data load data local insert into …

如果只能使用insert, 則推薦使用 單語(yǔ)句多行插入 ;

分享文章：mysql查詢(xún)?cè)趺磧?yōu)化,如何優(yōu)化mysql
轉(zhuǎn)載來(lái)于：http://aaarwkj.com/article8/dsshoip.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供外貿(mào)建站、動(dòng)態(tài)網(wǎng)站、微信小程序、搜索引擎優(yōu)化、網(wǎng)站導(dǎo)航、自適應(yīng)網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶(hù)投稿、用戶(hù)轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)