PHP數據庫為什么要分表和分庫

數據量太大會影響性能，所以進行分庫分表以優化數據庫的性能

成都創新互聯服務項目包括安溪網站建設、安溪網站制作、安溪網頁制作以及安溪網絡營銷策劃等。多年來，我們專注于互聯網行業，利用自身積累的技術優勢、行業經驗、深度合作伙伴關系等，向廣大中小型企業、政府機構等提供互聯網行業的解決方案，安溪網站推廣取得了明顯的社會效益與經濟效益。目前，我們服務的客戶以成都為中心已經輻射到安溪省份的部分城市，未來相信會繼續擴大服務區域并繼續獲得客戶的支持與信任！

php 高并發解決思路解決方案

php 高并發解決思路解決方案，如何應對網站大流量高并發情況。本文為大家總結了常用的處理方式，但不是細節，后續一系列細節教程給出。希望大家喜歡。

一 高并發的概念

在互聯網時代，并發，高并發通常是指并發訪問。也就是在某個時間點，有多少個訪問同時到來。

二 高并發架構相關概念

1、QPS (每秒查詢率) : 每秒鐘請求或者查詢的數量，在互聯網領域，指每秒響應請求數(指 HTTP 請求)

2、PV（Page View）：綜合瀏覽量，即頁面瀏覽量或者點擊量，一個訪客在 24 小時內訪問的頁面數量

--注：同一個人瀏覽你的網站的同一頁面，只記做一次 pv

3、吞吐量（fetches/sec） ：單位時間內處理的請求數量 （通常由 QPS 和并發數決定）

4、響應時間：從請求發出到收到響應花費的時間

5、獨立訪客（UV）：一定時間范圍內，相同訪客多次訪問網站，只計算為 1 個獨立訪客

6、帶寬：計算帶寬需關注兩個指標，峰值流量和頁面的平均大小

7、日網站帶寬： PV/統計時間（換算到秒） * 平均頁面大小（kb）* 8

三 需要注意點：

1、QPS 不等于并發連接數（QPS 是每秒 HTTP 請求數量，并發連接數是系統同時處理的請求數量）

2、峰值每秒請求數（QPS）= （總 PV 數*80%）/ （六小時秒數*20%）【代表 80%的訪問量都集中在 20%的時間內】

3、壓力測試： 測試能承受的最大并發數 以及測試最大承受的 QPS 值

4、常用的性能測試工具【ab，wrk，httpload，Web Bench，Siege，Apache JMeter】

四 優化

1、當 QPS 小于 50 時

優化方案:為一般小型網站,不用考慮優化

2、當 QPS 達到 100 時,遇到數據查詢瓶頸

優化方案: 數據庫緩存層,數據庫的負載均衡

3、當 QPS 達到 800 時, 遇到帶寬瓶頸

優化方案:CDN 加速,負載均衡

4、當 QPS 達到 1000 時

優化方案: 做 html 靜態緩存

5、當 QPS 達到 2000 時

優化方案: 做業務分離,分布式存儲

五、高并發解決方案案例:

1、流量優化

防盜鏈處理(去除惡意請求)

2、前端優化

(1) 減少 HTTP 請求[將 css,js 等合并]

(2) 添加異步請求(先不將所有數據都展示給用戶,用戶觸發某個事件,才會異步請求數據)

(3) 啟用瀏覽器緩存和文件壓縮

(4) CDN 加速

(5) 建立獨立的圖片服務器(減少 I/O)

3、服務端優化

(1) 頁面靜態化

(2) 并發處理

(3) 隊列處理

4、數據庫優化

(1) 數據庫緩存

(2) 分庫分表,分區

(3) 讀寫分離

(4) 負載均衡

5、web 服務器優化

(1) nginx 反向代理實現負載均衡

(2) lvs 實現負載均衡

市面上數據庫分庫分表一菜有哪幾種方案

1 基本思想之什么是分庫分表？

從字面上簡單理解，就是把原本存儲于一個庫的數據分塊存儲到多個庫上，把原本存儲于一個表的數據分塊存儲到多個表上。

2 基本思想之為什么要分庫分表？

數據庫中的數據量不一定是可控的，在未進行分庫分表的情況下，隨著時間和業務的發展，庫中的表會越來越多，表中的數據量也會越來越大，相應地，數據操作，增刪改查的開銷也會越來越大；另外，由于無法進行分布式式部署，而一臺服務器的資源（CPU、磁盤、內存、IO等）是有限的，最終數據庫所能承載的數據量、數據處理能力都將遭遇瓶頸。

3 分庫分表的實施策略。

分庫分表有垂直切分和水平切分兩種。

3.1 何謂垂直切分，即將表按照功能模塊、關系密切程度劃分出來，部署到不同的庫上。例如，我們會建立定義數據庫workDB、商品數據庫payDB、用戶數據庫userDB、日志數據庫logDB等，分別用于存儲項目數據定義表、商品定義表、用戶數據表、日志數據表等。

3.2 何謂水平切分，當一個表中的數據量過大時，我們可以把該表的數據按照某種規則，例如userID散列，進行劃分，然后存儲到多個結構相同的表，和不同的庫上。例如，我們的userDB中的用戶數據表中，每一個表的數據量都很大，就可以把userDB切分為結構相同的多個userDB：part0DB、part1DB等，再將userDB上的用戶數據表userTable，切分為很多userTable：userTable0、userTable1等，然后將這些表按照一定的規則存儲到多個userDB上。

3.3 應該使用哪一種方式來實施數據庫分庫分表，這要看數據庫中數據量的瓶頸所在，并綜合項目的業務類型進行考慮。

如果數據庫是因為表太多而造成海量數據，并且項目的各項業務邏輯劃分清晰、低耦合，那么規則簡單明了、容易實施的垂直切分必是首選。

而如果數據庫中的表并不多，但單表的數據量很大、或數據熱度很高，這種情況之下就應該選擇水平切分，水平切分比垂直切分要復雜一些，它將原本邏輯上屬于一體的數據進行了物理分割，除了在分割時要對分割的粒度做好評估，考慮數據平均和負載平均，后期也將對項目人員及應用程序產生額外的數據管理負擔。

在現實項目中，往往是這兩種情況兼而有之，這就需要做出權衡，甚至既需要垂直切分，又需要水平切分。我們的游戲項目便綜合使用了垂直與水平切分，我們首先對數據庫進行垂直切分，然后，再針對一部分表，通常是用戶數據表，進行水平切分。

4 分庫分表存在的問題。

4.1 事務問題。

在執行分庫分表之后，由于數據存儲到了不同的庫上，數據庫事務管理出現了困難。如果依賴數據庫本身的分布式事務管理功能去執行事務，將付出高昂的性能代價；如果由應用程序去協助控制，形成程序邏輯上的事務，又會造成編程方面的負擔。

4.2 跨庫跨表的join問題。

在執行了分庫分表之后，難以避免會將原本邏輯關聯性很強的數據劃分到不同的表、不同的庫上，這時，表的關聯操作將受到限制，我們無法join位于不同分庫的表，也無法join分表粒度不同的表，結果原本一次查詢能夠完成的業務，可能需要多次查詢才能完成。

4.3 額外的數據管理負擔和數據運算壓力。

額外的數據管理負擔，最顯而易見的就是數據的定位問題和數據的增刪改查的重復執行問題，這些都可以通過應用程序解決，但必然引起額外的邏輯運算，例如，對于一個記錄用戶成績的用戶數據表userTable，業務要求查出成績最好的100位，在進行分表之前，只需一個order by語句就可以搞定，但是在進行分表之后，將需要n個order by語句，分別查出每一個分表的前100名用戶數據，然后再對這些數據進行合并計算，才能得出結果。

上述整理于互聯網