1.最重要的調整資料表的架構，以提升效率。透過架構調整，減少關聯查詢，減少同步讀寫。用冗餘欄位，減少關聯。

2 大小欄位分離。尤其是大欄位，最好獨立表儲存（當然是資料量極為龐大時）

3.使用連結（join）來代替子查詢，速度將會快很多的。

4.合理索引！十分重要，必要時分表分庫。好的索引，使查詢提升1000倍，不是問題。

接手的時候，經理就說了，一定要把使用者反饋的這個事情列為P0級問題，儘快解決。

於是，我馬上開始了分析。經過在日誌裡打點，得知時間主要消耗在資料庫查詢上。根據我們之前的理論知識，我根本想象不到資料庫能被拖慢到這個地步。問題出現在一張儲存歷史任務的表格實在是太大了，新任務還在以每天百萬級的速度增長，而這張表的體量已經達到了億。這種情況下，就算有索引，在頻繁寫表（建立任務）的間隙去讀表（查任務），其效率也是非常低的。

在查閱了很多資訊之後，我看到了很多人推薦使用elastic search作為持久層。

它是一個輕量型的儲存工具，雖然不是關係型資料庫，也不支援基本SQL語句，但是它具有能夠動態多節點部署，節點掉線後不影響全域性資料的優點，最重要的一點，在面對海量資料查詢時，它的表現要比MySQL優秀許多。根據我們的實際測試，一張幾千萬的表格，如果儲存在MySQL中，利用非索引欄位查詢，可能消耗數秒到數十秒，但是同樣的資料儲存在ElasticSearch中，只需要毫秒級別就能查詢到結果。簡直就是為我們遇到的問題量身定做的解決方案。

綜上，我們從兩個方面提供了最佳化資料庫的思路，分別是配置主從與引入ElasticSearch。

減少磁碟訪問

我們都知道，磁碟的讀取速度是很慢的，很多時候資料庫訪問的瓶頸都在這裡。而減少磁碟訪問的主要方法有：

合理使用索引：這裡要注意避免索引失效；

分頁查詢：不同的資料，SQL語句分頁的寫法不相同，就不在這裡舉例了；

只返回需要的欄位，儘量減少這樣的寫法：select * from table；

使用繫結變數（避免硬解析）；

合理使用排序；

減少比較操作；減少CPU中的計算；

批次提交，要更新一萬條資料的時候，避免一萬次與資料庫發生一萬次操作，而是隻提交一次。

合理的使用儲存過程（當然有時候也會造成業務邏輯被寫在不同的地方）；

使用遊標處理結果記錄；

這個最好理解吧，加資源唄，這個是成本最高，不過效果卻不一定高的方法。

自己經常做這件事，所以分享一些經驗給大家，資料庫其實從某種程度上來說就是一個特殊的檔案系統，只不過資料庫系統本身對這個系統做了很多特殊的操作，比如提供事務、提供分割槽、提供複製等等，換句話說，資料庫裡面的資料還是儲存到檔案裡面的，那麼資料庫的最佳化從某種程度上來說就是檔案的最佳化，下面我們就列舉一些最佳化方法。

方案一：減少一次讀取的資料量記錄，既然資料是儲存在檔案裡面的，那麼如果你一次要讀取檔案裡面的很多很多資料，肯定效能大打折扣，為什麼呢？這就如，你要在一本書裡面找很多個字，並且找完，你想想，慢嗎？所以對於這種情況，儘可能的減少讀取的資料量，比如之前是一次讀取1萬條，那麼現在一次讀取100條就可以了。

方案二：減少寫入檔案的次數，我們知道檔案的操作就是開啟檔案、寫入資料、關閉檔案，現在假設你有10000條修改記錄（對同一個表的），每次僅僅執行一次修改，那麼你要反覆執行開啟、寫入、關閉檔案10000次，試想一下，效能怎麼樣，所以很多資料庫系統都提供了insert一次插入多條記錄的功能。

很多最佳化方案，都需要你在專案裡面不斷實踐。