總體思路
- 客戶端（1）：優(yōu)化客戶端的應(yīng)用，做Sql優(yōu)化，看看是否有不必要的壓力給了數(shù)據(jù)庫（應(yīng)用優(yōu)化），難度指數(shù)低，改進效果不明顯
- 服務(wù)端（2）：讀寫分離，難度指數(shù)低，改進效果不明顯
- 服務(wù)端（3）：看看有沒有其他辦法可以降低對數(shù)據(jù)庫的壓力，例如引入緩存、加搜索引擎等，難度指數(shù)中等，改進效果明顯，10G-100GB的 數(shù)據(jù)，完全無壓力
- 服務(wù)端（4）：把數(shù)據(jù)庫的數(shù)據(jù)和訪問分到多臺數(shù)據(jù)庫上，分開支持，分為垂直分割和水平分割，難度指數(shù)大，改進效果明顯，適合TB級的數(shù)據(jù)量
方法3
- 加入緩存或者搜索引擎
- 緩存和隊列：緩存是降低數(shù)據(jù)庫讀取量的出色技術(shù)。有許多應(yīng)用使用這種技術(shù)可以降低數(shù)據(jù)庫讀負載高達80-95%。與之相對的是隊列，它是用來優(yōu)化寫操作的。通過合并多次寫操作，提高了對數(shù)據(jù)庫操作的效率。大部分大型應(yīng)用都應(yīng)該重點考慮這兩種技術(shù)。Memcached和Redis是MySQL領(lǐng)域非常流行的兩種緩存技術(shù)。對于隊列，最流行的技術(shù)是ActiveMQ和RabbitMQ，以及較新的kafka
- 外部支持技術(shù)：MySQL在很多方面都很出色，但也不是所有方面都強。如果你需要高性能全文檢索，應(yīng)該考慮ElasticSearch、Sphinx或者Lucene。如果你想做大規(guī)模數(shù)據(jù)分析，可以考慮基于Hadoop的基礎(chǔ)架構(gòu)或者Vertica也是不錯的選擇。你應(yīng)該讓MySQL處理它擅長的事，把其它事留給外部支持工具來做
方法4
- 垂直分割和水平分割
- 垂直分割：把一個數(shù)據(jù)庫中不同業(yè)務(wù)單元的數(shù)據(jù)分到不同的數(shù)據(jù)庫里面
- 水平分割：根據(jù)一定的規(guī)則把同一業(yè)務(wù)單元的數(shù)據(jù)拆分到多個數(shù)據(jù)庫中
- 垂直分割和水平分割的理解
- 分片不是萬能藥，使用分片的場景
- 對垂直分割和水平分割都有的影響：
- 單機的ACID保證被打破了
- Join操作被影響
- 依靠外鍵去進行約束的場景會有影響
- 另外對于水平分割的影響：
- 依靠單庫的自增序列生成唯一ID 會受影響
- 針對單個邏輯意義上的表的查詢要跨庫
