大型網站面臨的問題：
海量數據處理
大型網站每天的數據量可能上百萬，甚至上千萬或更多。如果存在設計不好的多對多關係，在前期可能沒有任何問題，但是隨着用戶增長，數據量會以幾何級數增加。此時，對於一個表的select和update（還不用說多表聯合查詢）的成本是非常高的。
數據併發處理
死鎖在高併發情況下存在的概率非常高，這時使用緩存仍是一個大問題。因爲在整個應用範圍下，緩存是全局共享的。當兩個或者多個請求同時對緩存有更新要求時，儘管我們有lock機制，但並不是很靈驗，應用程序還是會直接死掉。
文件存貯問題
當文件量是海量數據的情況下，那麼維護和使用時，磁盤I/O就是一個巨大的問題，哪怕你的帶寬足夠，但是你的磁盤也未必響應得過來。如果這個時候還涉及上傳，磁盤很容易就over了。
數據關係處理
在Web2.0時代，數據關係大多是多對多關係，涉及的大多是多表聯合查詢。如果避免是一個問題。
數據索引問題
索引和更新是一對矛盾。廉價的索引可能帶來高代價的update。
分佈式處理
爲了保證各地的訪問速度，如何有效實現數據同步和更新，實現各地服務器的實時通信是一個很大的問題。
Ajax利弊
Ajax利用簡單的post和get進行數據傳遞，採用HTTP debuger抓取數據，但存在攻擊危險。
數據安全性
大型網站面臨的危險主要有外掛、羣發等，如採用驗證碼，對用戶體驗又是一個很意外的影響。
數據同步和集羣處理
當數據庫服務器不堪重負時，就需要做基於數據庫的負載和集羣了。這時可能會遇到最讓人困擾的問題：根據數據庫的設計不同，數據基於網絡傳輸時會發生數據延遲。這是很可怕的問題，也不可避免。由此，我們就需要通過另外的手段來保證在這延遲的幾秒或者更長時間內，實現有效的交互。比如數據散列、分割、內容、異步處理等問題。
Open API以及數據共享
Open API已經成爲不可避免的趨勢，從google,facebook,myspace到海內、校內，都在考慮這個問題，它可以更有效地留住用戶，並激發用戶更多參與，讓更多人幫助你做最有效的開發。
大量like,or,in以及多表查詢帶來的性能屏障
大量上傳文件攻擊
解決方案
把Web2.0網站用戶量級別定爲三種，百萬級別（M）、千萬級別（S）以及億萬級別（Q）。如果全表查詢，可以採用分區視圖、分表索引處理。
對於M級別來說，主要應對的是I/O問題：對數據庫的file文件分磁盤存貯（不是分區，是不同的硬盤），根據負載量大小，我們可以適當控制硬盤的數量和文件分區的數量。對於S級別，需要對註冊和入庫的流程進行簡單修改。解決方案是數據散列和分區視圖。
常用的方案有三種。第一種是等容擴充法：在用戶註冊控制的基礎上，保證每個庫的用戶容量不超過500萬，超過之後入第二個庫，以此類推。這個方案可以保證有效的擴充性，但不能保證數據被有效索引。第二種就是共區索引方案，其實和第一種方案有異曲同工之處。但是對第一種方案進行了合理的優化，按照用戶名進行了分庫存貯。如建立26個數據庫，按照用戶名的索引來控制用戶數據入哪個庫。假如用戶名是crazycode，那該用戶名的數據存放在用戶表C中。方案三是一個更具模型化的方案，進行用戶ID的編碼。我們用一種序列化的方案將用戶名以編碼的形式存貯，如crazycode按照C,R,A,......存貯爲數字索引，然後進行分區存貯。數字類型的數據在數據庫中可以更有效地被查詢、更新和共享，這就是結合方案一和方案二的方案三。
對於Q級別，可以根據用戶活躍度的權值結合數據量進行臨時數據表的存放。如果是在非意外的數據情況下，每天登錄的用戶量不會上千萬。利用一個簡單的數據代理程序，一個臨時的用戶驗證數據庫，每天執行一次批處理，將活躍度高的用戶帳戶撮到臨時數據庫中。查詢的時候先查詢臨時庫，如果沒有，再進行全庫查詢。
一個更高級的查詢方案——數據緩存服務，就是將最常用最直接的數據直接存放在緩存服務器中，而這個緩存服務器定時從主服務器獲取並更新信息。更深入地，可以將緩存服務器做二次緩存，也就是一次性處理輸入並存放到list數據中，作爲全局變量放到內存中進行查詢，同時用散列表或者數組進行數據索引，根據查詢分佈到各個變量中，直接從內在中讀取數據。