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