『壹』 Mysql某個表有近千萬數據，CRUD比較慢，如何優化
數據千萬級別之多，佔用的存儲空間也比較大，可想而知它不會存儲在一塊連續的物理空間上，而是鏈式存儲在多個碎片的物理空間上。可能對於長字元串的比較，就用更多的時間查找與比較，這就導致用更多的時間。
可以做表拆分，減少單表欄位數量，優化表結構。
在保證主鍵有效的情況下，檢查主鍵索引的欄位順序，使得查詢語句中條件的欄位順序和主鍵索引的欄位順序保持一致。
主要兩種拆分 垂直拆分，水平拆分。
垂直分表
也就是「大表拆小表」，基於列欄位進行的。一般是表中的欄位較多，將不常用的， 數據較大，長度較長（比如text類型欄位）的拆分到「擴展表「。 一般是針對 那種 幾百列的大表，也避免查詢時，數據量太大造成的「跨頁」問題。
垂直分庫針對的是一個系統中的不同業務進行拆分，比如用戶User一個庫，商品Proct一個庫，訂單Order一個庫。 切分後，要放在多個伺服器上，而不是一個伺服器上。為什麼？ 我們想像一下，一個購物網站對外提供服務，會有用戶，商品，訂單等的CRUD。沒拆分之前， 全部都是落到單一的庫上的，這會讓資料庫的單庫處理能力成為瓶頸。按垂直分庫後，如果還是放在一個資料庫伺服器上， 隨著用戶量增大，這會讓單個資料庫的處理能力成為瓶頸，還有單個伺服器的磁碟空間，內存，tps等非常吃緊。 所以我們要拆分到多個伺服器上，這樣上面的問題都解決了，以後也不會面對單機資源問題。
資料庫業務層面的拆分，和服務的「治理」，「降級」機制類似，也能對不同業務的數據分別的進行管理，維護，監控，擴展等。 資料庫往往最容易成為應用系統的瓶頸，而資料庫本身屬於「有狀態」的，相對於Web和應用伺服器來講，是比較難實現「橫向擴展」的。 資料庫的連接資源比較寶貴且單機處理能力也有限，在高並發場景下，垂直分庫一定程度上能夠突破IO、連接數及單機硬體資源的瓶頸。
水平分表
針對數據量巨大的單張表（比如訂單表），按照某種規則（RANGE,HASH取模等），切分到多張表裡面去。 但是這些表還是在同一個庫中，所以庫級別的資料庫操作還是有IO瓶頸。不建議採用。
水平分庫分表
將單張表的數據切分到多個伺服器上去，每個伺服器具有相應的庫與表，只是表中數據集合不同。 水平分庫分表能夠有效的緩解單機和單庫的性能瓶頸和壓力，突破IO、連接數、硬體資源等的瓶頸。
水平分庫分表切分規則
1. RANGE
從0到10000一個表，10001到20000一個表；
2. HASH取模
一個商場系統，一般都是將用戶，訂單作為主表，然後將和它們相關的作為附表，這樣不會造成跨庫事務之類的問題。 取用戶id，然後hash取模，分配到不同的資料庫上。
3. 地理區域
比如按照華東，華南，華北這樣來區分業務，七牛雲應該就是如此。
4. 時間
按照時間切分，就是將6個月前，甚至一年前的數據切出去放到另外的一張表，因為隨著時間流逝，這些表的數據 被查詢的概率變小，所以沒必要和「熱數據」放在一起，這個也是「冷熱數據分離」。
分庫分表後面臨的問題
事務支持
分庫分表後，就成了分布式事務了。如果依賴資料庫本身的分布式事務管理功能去執行事務，將付出高昂的性能代價； 如果由應用程序去協助控制，形成程序邏輯上的事務，又會造成編程方面的負擔。
跨庫join
只要是進行切分，跨節點Join的問題是不可避免的。但是良好的設計和切分卻可以減少此類情況的發生。解決這一問題的普遍做法是分兩次查詢實現。在第一次查詢的結果集中找出關聯數據的id,根據這些id發起第二次請求得到關聯數據。
跨節點的count,order by,group by以及聚合函數問題
這些是一類問題，因為它們都需要基於全部數據集合進行計算。多數的代理都不會自動處理合並工作。解決方案：與解決跨節點join問題的類似，分別在各個節點上得到結果後在應用程序端進行合並。和join不同的是每個結點的查詢可以並行執行，因此很多時候它的速度要比單一大錶快很多。但如果結果集很大，對應用程序內存的消耗是一個問題。
數據遷移，容量規劃，擴容等問題
來自淘寶綜合業務平台團隊，它利用對2的倍數取余具有向前兼容的特性（如對4取余得1的數對2取余也是1）來分配數據，避免了行級別的數據遷移，但是依然需要進行表級別的遷移，同時對擴容規模和分表數量都有限制。總得來說，這些方案都不是十分的理想，多多少少都存在一些缺點，這也從一個側面反映出了Sharding擴容的難度。
ID問題
一旦資料庫被切分到多個物理結點上，我們將不能再依賴資料庫自身的主鍵生成機制。一方面，某個分區資料庫自生成的ID無法保證在全局上是唯一的；另一方面，應用程序在插入數據之前需要先獲得ID,以便進行SQL路由.
一些常見的主鍵生成策略
UUID
使用UUID作主鍵是最簡單的方案，但是缺點也是非常明顯的。由於UUID非常的長，除佔用大量存儲空間外，最主要的問題是在索引上，在建立索引和基於索引進行查詢時都存在性能問題。
Twitter的分布式自增ID演算法Snowflake
在分布式系統中，需要生成全局UID的場合還是比較多的，twitter的snowflake解決了這種需求，實現也還是很簡單的，除去配置信息，核心代碼就是毫秒級時間41位 機器ID 10位 毫秒內序列12位。
跨分片的排序分頁
一般來講，分頁時需要按照指定欄位進行排序。當排序欄位就是分片欄位的時候，我們通過分片規則可以比較容易定位到指定的分片，而當排序欄位非分片欄位的時候，情況就會變得比較復雜了。為了最終結果的准確性，我們需要在不同的分片節點中將數據進行排序並返回，並將不同分片返回的結果集進行匯總和再次排序，最後再返回給用戶。
『貳』 php如何實現兩台伺服器資料庫同步問題 - 技術問答
基於資料庫 Log 日誌分析可以實現，網上搜一下 CDC 數據同步。。
不過你也可以嘗試下 cloud.tapdata.net ， 一個在線的數據同步工具，支持一次性全量同步，也支持實時的增量同步。
『叄』 如何解決資料庫負載過大的問題
市面上存在兩種資料庫負載均衡的思路：1. 基於資料庫連接的負載均衡：例如總共有100個資料庫連接，50個連接登錄到資料庫機器A，另外50個連接登錄到資料庫機器B，這樣每個連接中接下來的所有請求全都是發往同一台資料庫機器的。 這種資料庫負載均衡的思路模擬了WEB上的負載均衡方法，但是由於WEB連接是短時間連接(連接建立後，獲取需要的HTML等資源後，連接馬上被關閉)，而資料庫連接是長時間連接( 連接建立後，可長時間保持，客戶可不停向資料庫發送SQL請求，資料庫做出回答，如此不斷循環直到連接被人為或因錯而斷開為止)，因此這種資料庫負載均衡思路存在著明顯的缺點：有可能會發生絕大部分的請求壓力都集中到某台資料庫機器上去，從而使得負載均衡效果失效。2.基於批處理請求的負載均衡：在建立資料庫連接的時候，會同時與每台資料庫伺服器建立連接，之後針對客戶端的每次請求，都會根據負載均衡演算法，獨立地選出某個資料庫節點來執行這個請求。此種思路符合資料庫長時間連接的特徵，不存在上面所述的基於連接的負載均衡方法的缺點。市面上的負載均衡廠商，既有基於連接的，也有基於批處理請求的，用戶需仔細辨別才能找到自己想要的合適產品。
『肆』 Java中怎麼把資料庫中的表做成定時任務，存入緩存，減輕頻繁直查資料庫時，資料庫的壓力
根據你的想法，建議將兩種方式整合下，建議如下設置：
接根據業務層的需要，把頻繁使用的多個表數據進行整合，並利用視圖的方式進行訪問，這樣既能減少數據表的壓力，也能保持數據的准確性；
根據向系統設定場景，將經常使用到的數據存放在緩存中，緩存建議使用radis等非關系型資料庫；
根據數據量確定，數據量比較大的，可以使用中間表等方式，如果數據量小而多的，放在緩存中最好，提高命中率。
『伍』 怎麼減輕網站資料庫的壓力
fikker 讓網站響應加速 10 倍以上， 減少資料庫壓力 90% 以上：
頁面緩存：目前網上的大部分頁面都是由網站程序動態生成的，例如 ASP，PHP，JSP等頁面都是網站動態生成的，這種頁面在被生成的時候，大部分都會讀取資料庫，在訪問量比較小的時候，資料庫尚可勝任，在訪問量較大的時候，資料庫就會嚴重延遲甚至不堪重負。因為資料庫的大部分數據存放在硬碟上的，並且硬碟數據交換的能力相對於內存來說是極低的（相差10倍以上），所以當資料庫頻繁讀取硬碟數據的時候，網站系統的負載能力便會大大降低，硬碟IO就成為了網站響應速度的瓶頸。Fikker 提供了動態頁面緩存能力，對於頻繁讀取的動態頁面，可以將其緩存在 Fikker 頁面緩存中，當瀏覽器訪問的時候，就不再需要網站程序重新讀取資料庫和重新編譯頁面，系統的吞吐能力大大的提高，極大的抵消了頻繁讀取資料庫帶來的瓶頸，網站的響應速度會有 10 倍以上的提升。加速舉例：一個熱門商品或熱點新聞頁面，1分鍾內有1萬次的訪問量，如果這些頁面都由網站生成，就會讀取1萬次資料庫並重復生成1萬個的頁面；如果 Fikker 將這個頁面緩存1分鍾，一分鍾內只會讀取1次資料庫並生成1次頁面，網站和資料庫的負荷就會大大的降低（10倍以上），所以越是負荷較大的網站，加速效果感覺上越明顯。
壓縮傳輸：絕大部分基於文本的頁面（asp, php, jsp, html, js, css, txt等）進行 gzip/compress/deflate 壓縮以後，相對於非壓縮頁面會減少大約75%的尺寸。例如：一個100K位元組的頁面，壓縮以後大約在20K - 25K位元組左右，如果這種壓縮過的頁面被緩存後再傳輸，會顯著的提升傳輸效率，加快網頁傳輸載入的速度，而且還很經濟（減少了帶寬支出）。Fikker 內置了 gzip 頁面壓縮功能，既減少了內存的佔用，提升了傳輸效率，又降低了帶寬的佔用。
『陸』 資料庫高並發寫入，怎麼降低資料庫的壓力
主要通過架構設計來減少高並發對資料庫的壓力；
比如 在資料庫和應用程序之間，增加 DAL層，通過代理，連接池等，保證資料庫與業務程序由一定的緩沖和關系梳理；
在資料庫前面，加一個緩存層，讓大部分數據訪問，都直接在緩存層獲取數據，不用訪問到後端的MySQL資料庫；
『柒』 一個大型、穩健、成熟的分布式系統的背後，往往會涉及眾多的支撐系統基礎設施
樹苗中2包是需要混合浸泡嗎？一個大型、穩健、成熟的分布式系統的背後，往往會涉及眾多的支撐系統，我們將這些支撐系統稱為分布式系統的基礎設施。除了前面所介紹的分布式協作及配置管理系統ZooKeeper,我們進行系統架構設計所依賴的基礎設施，還包括分布式緩存系統、持久化存儲、分布式消息系統、搜索引擎，以及CDN系統、負載均衡系統、運維自動化系統等，還有後面章節所要介紹的實時計算系統、離線計算系統、分布式文件系統、日誌收集系統、監控系統、數據倉庫等。
分布式緩存主要用於在高並發環境下，減輕資料庫的壓力，提高系統的響應速度和並發吞吐。當大量的讀、寫請求湧向資料庫時，磁碟的處理速度與內存顯然不在一個量級，因此，在資料庫之前加一層緩存，能夠顯著提高系統的響應速度，並降低資料庫的壓力。作為傳統的關系型資料庫，MySQL提供完整的ACID操作，支持豐富的數據類型、強大的關聯查詢、where語句等，能夠非常客易地建立查詢索引，執行復雜的內連接、外連接、求和、排序、分組等操作，並且支持存儲過程、函數等功能，產品成熟度高，功能強大。但是，對於需要應對高並發訪問並且存儲海量數據的場景來說，出於對性能的考慮，不得不放棄很多傳統關系型資料庫原本強大的功能，犧牲了系統的易用性，並且使得系統的設計和管理變得更為復雜。這也使得在過去幾年中，流行著另一種新的存儲解決方案——NoSQL，它與傳統的關系型資料庫最大的差別在於，它不使用SQL作為查詢語言來查找數據，而採用key-value形式進行查找，提供了更高的查詢效率及吞吐，並且能夠更加方便地進行擴展，存儲海量數據，在數千個節點上進行分區，自動進行數據的復制和備份。在分布式系統中，消息作為應用間通信的一種方式，得到了十分廣泛的應用。消息可以被保存在隊列中，直到被接收者取出，由於消息發送者不需要同步等待消息接收者的響應，消息的非同步接收降低了系統集成的耦合度，提升了分布式系統協作的效率，使得系統能夠更快地響應用戶，提供更高的吞吐。
當系統處於峰值壓力時，分布式消息隊列還能夠作為緩沖，削峰填谷，緩解集群的壓力，避免整個系統被壓垮。垂直化的搜索引擎在分布式系統中是一個非常重要的角色，它既能夠滿足用戶對於全文檢索、模糊匹配的需求，解決資料庫like查詢效率低下的問題，又能夠解決分布式環境下，由於採用分庫分表，或者使用NoSQL資料庫，導致無法進行多表關聯或者進行復雜查詢的問題。