畢竟當時的認識還是非常淺的。
如果大家有異議,可以在後面補充。我會隨時更新的。
現在大概列出如下:(望各位補充)
1.資料庫的設計
儘量把資料庫設計的更小的佔磁碟空間.
1).儘可能使用更小的整數型別.(mediumint就比int更合適).
2).儘可能的定義欄位為not null,除非這個欄位需要null.(這個規則只適合欄位為KEY的情形)
3).如果沒有用到變長欄位的話比如varchar,那就採用固定大小的紀錄格式比如char.(CHAR 總是比VARCHR快)
4).表的主索引應該儘可能的短.這樣的話每條紀錄都有名字標誌且更高效.
5).只建立確實需要的索引。索引有利於檢索記錄,但是不利於快速儲存記錄。如果總是要在表的組合欄位上做搜尋,那麼就在這些欄位上建立索引。索引的第一部分必須是最常使用的欄位.如果總是需要用到很多欄位,首先就應該多複製這些欄位,使索引更好的壓縮。
(這條只適合MYISAM引擎的表,對於INNODB則在儲存記錄的時候關係不大,因為INNODB是以事務為基礎的,如果想快速儲存記錄的話,特別是大批量的匯入記錄的時候)
6).所有資料都得在儲存到資料庫前進行處理。
7).所有欄位都得有預設值。
8).在某些情況下,把一個頻繁掃描的表分成兩個速度會快好多。在對動態格式表掃描以取得相關記錄時,它可能使用更小的靜態格式表的情況下更是如此。
(具體的表現為:MYISAM表的MERGE型別,以及MYISAM和INNODB通用的分割槽,詳情見手冊)
9).不會用到外來鍵約束的地方儘量不要使用外來鍵。
2.系統的用途
1).及時的關閉對MYSQL的連線。
2).explain 複雜的SQL語句。(這樣能確定你的SELECT 語句怎麼優化最佳)
3).如果兩個關聯表要做比較話,做比較的欄位必須型別和長度都一致.(在資料龐大的時候建立INDEX)
4).LIMIT語句儘量要跟order by或者 distinct.這樣可以避免做一次full table scan.
5).如果想要清空表的所有紀錄,建議用truncate table tablename而不是delete from tablename.
不過有一個問題,truncate 不會在事務處理中回滾。因為她要呼叫create table 語句。
(Truncate Table 語句先刪除表然後再重建,這個是屬於檔案界別的,所以自然快N多)
實測例子:
song2為INNODB表。
mysql> select count(1) from song2;
+———-+
| count(1) |
+———-+
| 500000 |
+———-+
1 row in set (0.91 sec)
mysql> delete from song2;
Query OK, 500000 rows affected (15.70 sec)
mysql> truncate table song2;
Query OK, 502238 rows affected (0.17 sec)
mysql>
{
這一點手冊上有詳細解釋:
TRUNCATE [TABLE] tbl_name
}
6).能使用STORE PROCEDURE 或者 USER FUNCTION的時候.(ROUTINE總是減少了伺服器端的開銷)
7).在一條insert語句中採用多重紀錄插入格式.而且使用load data infile來匯入大量資料,這比單純的indert快好多.(在MYSQL中具體表現為:INSERT INTO TABLEQ VALUES (),(),…();)
(還有就是在MYISAM表中插入大量記錄的時候先禁用到KEYS後面再建立KEYS,具體表現語句:
ALTER TABLE TABLE1 DISABLE KEYS;ALTER TABLE TABLE1 ENABLE KEYS;
而對於INNNODB 表在插入前先 set autocommit=0;完了後:set autocommit=1;這樣效率比較高。)
8).經常OPTIMIZE TABLE 來整理碎片.
9).還有就是date 型別的資料如果頻繁要做比較的話儘量儲存在unsigned int 型別比較快。
3.系統的瓶頸
1).磁碟搜尋.
並行搜尋,把資料分開存放到多個磁碟中,這樣能加快搜尋時間.
2).磁碟讀寫(IO)
可以從多個媒介中並行的讀取資料。
3).CPU週期
資料存放在主記憶體中.這樣就得增加CPU的個數來處理這些資料。
4).記憶體頻寬
當CPU要將更多的資料存放到CPU的快取中來的話,記憶體的頻寬就成了瓶頸.
====
[url]http://www.informit.com/articles/article.aspx?p=29406&seqNum=1[/url]