一、分庫分表、MPP和分布式數據庫的區別

1）分庫分表做法，主要是因為早期單機數據庫（主要還是MySQL這種低成本場景）下無法在一個庫一張表來承載同一業務表下所有的數據，因而將數據劃分到不同的物理庫表中去，從業務視角來形成一個大的邏輯表。這樣的話能夠充分利用水平拆分能力，來存儲超大的數據集。一般拆分邏輯依賴業務給出相關的字段，配合分表規則，來做hash、range的拆分。這種方式一般通過一些富客戶端來支持用戶sql，好處很直觀，針對點查詢效率很高，插入數據效率高，但問題點很多，也不太好解決，主要在于涉及到不同分庫的sql操作，比如怎么支持跨庫表join，怎么支持分布式事務來更新，如果sql中不帶分區鍵導致全邏輯表查詢等等。另外，數據量越來越大時有熱點問題怎么辦，數據怎么重分布，宕機怎么恢復，路由表變更怎么辦，怎么做多個實例的服務發現，怎么做讀寫分離，等等。最終就是讓業務上做妥協，最終一致性，不支持join，允許局部節點故障，等等。

2）本質上，分庫分表中間件相當于把數據庫解決不了的問題推到業務側，讓業務參與解決或者妥協。隨著云計算平臺分布式數據庫越來越強大，分庫分表的技術會慢慢的退出歷史舞臺。簡單來說，分布式數據庫把上面的問題盡量的在數據系統內部解決掉，給客戶的接口非常簡單，統一的endpoint，標準的數據庫協議，完整的sql支持能力，等等，但內部一樣有各種數據分區邏輯。分布式數據庫從廣義上來說，就是實現數據庫語義的分布式架構下的系統，像云上各種OLTP和OLAP產品，應該都可以稱之為分布式數據庫。分布式數據庫中最重要的就是數據怎么擺放，數據在多個機器上平均分攤持有一份數據做sharding，還是多個節點相互復制一份數據做主備，還是利用底層共享存儲共享一份完整數據集，衍生出不一樣的系統架構和能力。

3）mpp數據庫主要區別于smp數據庫。后者一般是單機架構，而單機能力畢竟有限，在OLAP計算數據量非常大的時候，單機數據庫的分析能力非常有限。mpp數據庫構建一套分布式計算集群（mpp數據庫肯定是分布式系統，但狹義上應該不算那些只考慮數據切片的分布式數據庫），增強計算能力，在計算中再針對數據集做切片調度執行等，最終希望能實現計算力的水平擴展。

總結一下，這些概念本身不是完全無關的，相互有關系。我接觸過的發展過程：

單機數據庫，到主備分布式數據庫（解決高可用和數據高可靠），到分庫分表（sharding解決橫向擴展）+主備分布式數據庫（解決部分數據的可用和數據可靠性，全局數據無強一致保障），再到主備+內部自動分區和復雜分布式計算的分布式數據庫（數據，語義，能力，免運維都很強），再到數據層共享存儲、計算層橫向彈性擴縮容的分布式數據庫架構（能力越來越強，成本、彈性、故障恢復速度、災備等），等等。

無論上單機還是分布式數據庫，針對單個sql，最終只會在一個節點上執行完成，而mpp數據庫會對這個sql執行計算任務分解，靠整個集群的算力分布式調度計算，最后整體完成sql。這個可能是與分布式數據庫的差異。但分布式數據庫與mpp數據庫不是一個差異化很大的概念，技術實現上也會有很多重疊的。

延伸閱讀：

二、全文索引

FULLTEXT（全文）索引，僅可用于MyISAM和InnoDB，針對較大的數據，生成全文索引非常的消耗時間和空間。對于文本的大對象，或者較大的CHAR類型的數據，如果使用普通索引，那么匹配文本前幾個字符還是可行的，但是想要匹配文本中間的幾個單詞，那么就要使用LIKE %word%來匹配，這樣需要很長的時間來處理，響應時間會大大增加，這種情況，就可使用時FULLTEXT索引了，在生成FULLTEXT索引時，會為文本生成一份單詞的清單，在索引時及根據這個單詞的清單來索引。FULLTEXT可以在創建表的時候創建，也可以在需要的時候用ALTER或者CREATE INDEX來添加。