MySQL支撐百萬級流量高並發的網站的部署方法是本文我們主要要介紹的內容，了解了這部分內容我們自己就能用MySQL來支撐百萬級流量高並發的網站了，接下來我們就開始介紹這部分內容。
1. MySQL服務器集群
由於是小公司在資金和成本上都有所限制，而且在技術上也沒有幾個技術員接觸過，所以這個方法自然就讓大伙否決了。
這裡說說我個人的理解!做集群不但添加資費的開銷，而且在技術上也有很大的挑戰，對於我們公司目前的情況是不大現實的。集群無非就是把一台服務器的壓力轉接到兩台或是多台服務器上，我是這麼理解的，也許我理解有誤，還請大家指教。
2. 分而治之
這個方法和集群差不多，不過是把統計的代碼放在不同的服務器上跑，由於公司有不少配置低的服務器跑幾萬到幾十萬IP還是沒有問題的，我們可以把幾百萬流量分成十來個幾十萬的量分而統計。
優點：充分的利用了現在的資源，解決了目前的問題。
缺點：這樣的方法不是長久之計，遲早還是會出問題的。而且在統計數據的時候比較麻煩。
3. 統計代碼的修改
由於之前采用的是在插入數據之前加以判斷，這個IP是否存在，來路等的處理，無形中增加了服務器的壓力，所以大伙把統計代碼改成來一個就插入數據庫，不管三七二十一等以後在處理。
這個方法基本上把當天的數據保留下來了，可是在處理的時候由於數據量的龐大，來來回回還是把服務器跑死了，而且在插入的時候由於當時設計數據結構的時候留有的索引，也大大的消耗了不少的服務器資源。
那麼把索引去掉到最後處理的時候又是老慢的，得不償失。
4. 統計方式的修改
最後這一個方法，效果非常的明顯。那是什麼方法呢!
這裡就主要介紹這個方法：
A、保留原用的數據結構不變，並把所有的數據按一定的結構存入文件
結構：可以是xml,json，也可以是你自己想的任何有規律的數據排放。
例如：
1) 221.2.70.52,http://www.baidu.com,windowxp\r\n
2) 221.2.70.52,http://www.baidu.com,windowxp\r\n
寫入文件:fopen，fwrite??no 這裡介紹一個非常好用的技巧，也許大家都知道，但是像我這樣的菜鳥大概都不知道，那就是用error_log，這不是寫錯誤日志的嗎?對就是他，非常方便。
格式：
1 error_log("內容", 3, "/date.dat");
這裡我就不說他的具體用了，不明白的朋友可以查一下手冊。
B、數據文件的命名
為什麼這裡要講文件的命名呢?如果就一味的把數據的寫入文件不作任何的處理那麼他和直接插入數據庫有多大的區別呢?那麼我們所作的一切都是無用功了。
首先是在時間的利用上:date(‘YmdH’)得到的值是如：2008121112這有什麼好入，這樣一來這個數據就是一個小時一個文件必免了文件過大，而且不用去判斷自動生成。
IP的應用：由於在很多數據上都是一個IP操作的，所以把相同IP的數據放在一個文件裡在後面的處理就非常方便處理。請看後面的介紹，這裡我們取IP成三位為文件名字的一部分。
C、數據的導入處理
通過以上兩位的操作當天的數據會一個不少的保留下來，接下來怎麼處理其實並不是很重要了。但是這裡還是講講我的想法。
入庫前處理：
前面講到把IP三位相同的放一個文件就是為了入庫前到它們進行處理，首先可以用最笨的方法把數據拆成N個數據。在進行重復數據的刪除。
如果一個IP浏覽多頁那麼PV在這裡就可以得到統計，並把訪問的頁面進行處理，組成新的數據。
導入方法：
這裡要介紹一下數據的導入方法:1 $sql="LOAD DATA INFILE '".$file."' INTO TABLE `test` FIELDS TERMINATED BY ', ' LINES TERMINATED BY '\r\n'(2 3 `time` , `md5`4 5 )";就這一個語句，在導入幾十萬數據的時候可以說是十分快速的，用法我這裡也不過多介紹了，大家有不明白的可以查手冊，所以說解決數據庫的瓶頸的辦法不定要加設備，也不一定要換數據庫，只要換一個思路就能解決不少問題。
以上就是MySQL支撐百萬級流量高並發的網站的部署方法，本文就介紹到這裡了，希望本次的介紹能夠對您有所收獲！
