innodb表正好相反;行級鎖表
互連網服務,不算支付性的服務外,互動產品,新聞系統等等一般都是讀多,寫少。用myisam表比較合適。
表的設計
定長表:所有列的欄位長度都是定長的。可以去查mysql的手冊不定長欄位是VARCHAR、BLOB或TEXT。int char都是定長的,定長表佔用空間會大。
動態表:就是欄位不是都定長的。
定長表要比動態表檢索速度快。
軟體系統的設計習慣是把每張表都分清很明確的功能,比如使用者表都是使用者資訊,如果需要同時從留言表取資料,又從使用者表取使用者資訊的時候,就會採用聯合查 詢,有的時候一些操作還會用left,join等各種複雜sql語句,沒準還要用mysql的函數。如果是針對訪問量,讀取量很大的互連網服務時,同時並 發去讀,資料量又大,很可怕。最好是如果資料不會修改,在常用的表上有冗餘欄位,能夠做到一次讀,把資料都拿到;可以有冗餘的寫操作,但減少複雜的查詢操 作。
在設計表的時候要將這個表的所有欄位類型佔用的位元組數求和,並乘以你的預期(如:儲存100W資料量),就是整張表未來會佔用容量。
拆表 拆庫
拆表就是將一張表複製N多張,裡面分別存放不用內容的資料,資料的存放是用HASH演算法來決定放入哪張表。
例如使用者表user,傳統情況就是一張表,拆表就是將表複製為user_01,user_02等裡面都存放了格式一樣的不同使用者資料。
拆庫和拆表類似,就是庫的複製。
拆表或拆庫有很多的HASH演算法,主要目的就是減少表的資料量,用演算法保證每個表的資料量平均,請求,讀寫操作被分攤降低壓力,而且安全,出了問題最多是一部分使用者受影響。缺點就是檢索不方便,需要另想辦法。
很多網站為了前期省事都會採用discuz的產品,如bbs,blog等,網上有不少關於這個產品的介紹和最佳化方法,沒細研究過,聽過一些網站介紹他們的 最佳化方法時,對於資料庫主要是採用主從的方法,將資料庫的讀寫分離來提高效能,但是個人覺得這種辦法在資料量到了規模的時候就OVER了,並發和讀寫操作 沒提升,資料也是會逐漸累計超過限制。
互連網服務由於要應對大資料量,大請求量,所以在設計開發的時候就不要太學院派,不要力圖達到資料庫、程式的設計“優美”,效能是最要緊的。