作為一名IT行業的從業人員，主要在從事產品研發及項目管理工作，在項目過程中，經常有優化數據庫存儲、架構方面的方案，所以我來探討一下這個問題。

目前經常使用的關系型數據庫如MySQL、SQL Server等，都是以“行”為單位進行存儲，為了快速檢索，也都采用了B樹或其他索引技術。

從原理上來講，表中的數據越多，索引樹的范圍越大，磁盤讀取也越多，性能也就越低。

從實踐角度來看，一般以百萬到千萬作為一個表的存儲量級，超出該范圍之后，性能就會下降，需要采用其他技術手段解決。

首先想到的就是能否將讀和寫分離，主數據庫用于寫入，讀數據庫（多個）用于對外提供查詢，通過數據復制的方式將主數據庫的數據同步到讀庫。該架構提升了數據庫的讀寫能力，但對于主數據庫的寫入能力依然沒法擴展。

其次，垂直分表就是把一個數據量很大的表,可以按某個字段的屬性或使用頻繁程度分類,拆分為多個表。如有多種業務類型，每種業務類型建立不同的表，tb1,tb2,tb3。如果日常業務不需要使用所有數據，可以按時間分表，比如說月表。每個表只存一個月的記錄。

再次，水平分表就是根據一列或多列數據的值把數據行放到多個獨立的表里，這里不具備業務意義。如按照id分表，末尾是0-9的數據分別插入到10個表里面。

這樣做的好處就是解決了數據存儲容量的問題，但也帶來了諸多弊端，不再一一闡述。

mysql優化的方式有很多，選擇上主要還是要考慮個人的實際情況，如代碼不可控的情況下，就不適合選擇按字段屬性分表的情況，這樣可能會帶來大量的重構以及很多不可預期的風險。

而架構的優化，雖然對應用是透明的，但對sql的寫法有很多局限性，比如說不能使用聚合函數等等，同時也需要有充足的硬件資源，只有一臺服務器的情況下是沒有意義的。

相比起來，代價最低的是按時間分表或分區，這兩種辦法對應用來說都是透明的。分區只需要一次本地數據遷移的操作。而通過分表把現網數據和歷史數據分離，唯一的代價是定期的數據維護。

一般如果表里面有1億數據的情況下，索引的問題應該是常識了，這方面我就不說了。