聯(lián)系官方銷售客服
1835022288
028-61286886
數(shù)據(jù)優(yōu)化是一個(gè)大學(xué)問(wèn)，本節(jié)部分內(nèi)容來(lái)自百度
一、模板標(biāo)簽
模板標(biāo)簽寫法不合理時(shí)會(huì)導(dǎo)致cpu占用過(guò)高，網(wǎng)站緩慢，不推薦使用的標(biāo)簽
module=all 全模塊查詢嚴(yán)重影響速度
related 相關(guān)標(biāo)簽，按關(guān)鍵詞查詢影響速度 order=rand 避免這種隨機(jī)排序，嚴(yán)重影響速度
二、創(chuàng)建索引
最簡(jiǎn)單也是最常用的優(yōu)化就是查詢。因?yàn)閷?duì)于CRUD操作，read操作是占據(jù)了絕大部分的比例，所以read的性能基本上決定了應(yīng)用的性能。對(duì)于查詢性能最常用的就是創(chuàng)建索引。經(jīng)過(guò)測(cè)試，2000萬(wàn)條記錄，每條記錄200字節(jié)兩列varchar類型的。當(dāng)不使用索引的時(shí)候查詢一條記錄需要一分鐘，而當(dāng)創(chuàng)建了索引的時(shí)候查詢時(shí)間可以忽略。但是，當(dāng)你在已有數(shù)據(jù)上添加索引的時(shí)候，則需要耗費(fèi)非常大的時(shí)間。我插入2000萬(wàn)條記錄之后，再創(chuàng)建索引大約話費(fèi)了幾十分鐘的樣子。
創(chuàng)建索引的弊端和場(chǎng)合。雖然創(chuàng)建索引可以很大程度上優(yōu)化查詢的速度，但是弊端也是很明顯的。一個(gè)是在插入數(shù)據(jù)的時(shí)候，創(chuàng)建索引也需要消耗部分的時(shí)間，這就使得插入性能在一定程度上降低；另一個(gè)很明顯的是數(shù)據(jù)文件變的更大。在列上創(chuàng)建索引的時(shí)候，每條索引的長(zhǎng)度是和你創(chuàng)建列的時(shí)候制定的長(zhǎng)度相同的。比如你創(chuàng)建varchar(100)，當(dāng)你在該列上創(chuàng)建索引，那么索引的長(zhǎng)度則是102字節(jié)，因?yàn)殚L(zhǎng)度超過(guò)64字節(jié)則會(huì)額外增加2字節(jié)記錄索引的長(zhǎng)度。
1、為搜索字段建索引
索引并不一定就是給主鍵或是唯一的字段。如果在你的表中，有某個(gè)字段你總要會(huì)經(jīng)常用來(lái)做搜索，那么，請(qǐng)為其建立索引吧。
2、千萬(wàn)不要 ORDER BY RAND() 和order=rand標(biāo)簽
想打亂返回的數(shù)據(jù)行？隨機(jī)挑一個(gè)數(shù)據(jù)？真不知道誰(shuí)發(fā)明了這種用法，但很多新手很喜歡這樣用。但你確不了解這樣做有多么可怕的性能問(wèn)題。
如果你真的想把返回的數(shù)據(jù)行打亂了，你有N種方法可以達(dá)到這個(gè)目的。這樣使用只讓你的數(shù)據(jù)庫(kù)的性能呈指數(shù)級(jí)的下降。這里的問(wèn)題是：MySQL會(huì)不得 不去執(zhí)行RAND()函數(shù)（很耗CPU時(shí)間），而且這是為了每一行記錄去記行，然后再對(duì)其排序。就算是你用了Limit 1也無(wú)濟(jì)于事（因?yàn)橐判颍?br>
3、在Join表的時(shí)候使用相當(dāng)類型的例，并將其索引
如果你的應(yīng)用程序有很多 JOIN 查詢，你應(yīng)該確認(rèn)兩個(gè)表中Join的字段是被建過(guò)索引的。這樣，MySQL內(nèi)部會(huì)啟動(dòng)為你優(yōu)化Join的SQL語(yǔ)句的機(jī)制。
而且，這些被用來(lái)Join的字段，應(yīng)該是相同的類型的。例如：如果你要把 DECIMAL 字段和一個(gè) INT 字段Join在一起，MySQL就無(wú)法使用它們的索引。對(duì)于那些STRING類型，還需要有相同的字符集才行。（兩個(gè)表的字符集有可能不一樣）
4、對(duì)查詢進(jìn)行優(yōu)化，應(yīng)盡量避免全表掃描，首先應(yīng)考慮在 where 及 order by 涉及的列上建立索引。
5、應(yīng)盡量避免在 where 子句中使用!=或<>操作符，否則引擎將放棄使用索引而進(jìn)行全表掃描。
6、任何地方都不要使用 select * from t ，用具體的字段列表代替“*”，不要返回用不到的任何字段。
三、讀寫分離
用兩臺(tái)或者多臺(tái)主機(jī)做集群，一般是一寫多讀（一臺(tái)mysql只寫入，剩下的用來(lái)讀取，寫入的數(shù)據(jù)要實(shí)時(shí)的從寫庫(kù)同步到讀庫(kù)）這個(gè)配置起來(lái)也比較簡(jiǎn)單，唯一要說(shuō)的是代理插件的選擇，推薦360開(kāi)源的atlas，用法很簡(jiǎn)單，實(shí)際使用中也沒(méi)有太多bug。
四、數(shù)據(jù)表分區(qū)
什么是分區(qū)？
分區(qū)和分表相似，都是按照規(guī)則分解表。不同在于分表將大表分解為若干個(gè)獨(dú)立的實(shí)體表，而分區(qū)是將數(shù)據(jù)分段劃分在多個(gè)位置存放，分區(qū)后，表還是一張表，但數(shù)據(jù)散列到多個(gè)位置。
另外分區(qū)也可以分為兩種：
垂直分區(qū)和水平分區(qū)
水平分區(qū)（Horizontal Partitioning）這種形式分區(qū)是對(duì)表的行進(jìn)行分區(qū)，所有在表中定義的列在每個(gè)數(shù)據(jù)集中都能找到，所以表的特性依然得以保持。
垂直分區(qū)（Vertical Partitioning）這種分區(qū)方式一般來(lái)說(shuō)是通過(guò)對(duì)表的垂直劃分來(lái)減少目標(biāo)表的寬度，使某些特定的列被劃分到特定的分區(qū)，每個(gè)分區(qū)都包含了其中的列所對(duì)應(yīng)的行。
五、MYSQL緩存配置
在MySQL中有多種多樣的緩存，有的緩存負(fù)責(zé)緩存查詢語(yǔ)句，也有的負(fù)責(zé)緩存查詢數(shù)據(jù)。這些緩存內(nèi)容客戶端無(wú)法操作，是由server端來(lái)維護(hù)的。它會(huì)隨著你查詢與修改等相應(yīng)不同操作進(jìn)行不斷更新。通過(guò)其配置文件我們可以看到在MySQL中的緩存：
在這里主要分析query cache，它是主要用來(lái)緩存查詢數(shù)據(jù)。當(dāng)你想使用該cache，必須把query_cache_size大小設(shè)置為非0。當(dāng)設(shè)置大小為非0的時(shí)候，server會(huì)就會(huì)緩存每次查詢返回的結(jié)果，到下次相同查詢server就直接從緩存獲取數(shù)據(jù)，而不是再執(zhí)行查詢。能緩存的數(shù)據(jù)量就和你的size大小設(shè)置有關(guān)，所以當(dāng)你設(shè)置的足夠大，數(shù)據(jù)可以完全緩存到內(nèi)存，速度就會(huì)非常之快。
但是，query cache也有它的弊端。當(dāng)你對(duì)數(shù)據(jù)表做任何的更新操作(update/insert/delete)等操作，server為了保證緩存與數(shù)據(jù)庫(kù)的一致性，會(huì)強(qiáng)制刷新緩存數(shù)據(jù)，導(dǎo)致緩存數(shù)據(jù)全部失效。所以，當(dāng)一個(gè)表格的更新數(shù)據(jù)表操作非常多的話，query cache是不會(huì)起到查詢提升的性能，還會(huì)影響其他操作的性能。