1. 程式人生 > >MySQL優化資料庫物件

MySQL優化資料庫物件

1、優化表的資料型別

使用PROCEDURE ANALYSE()對當前應用的表進行分析,該函式可以對資料表中列的資料型別提供優化建議。

select* from tbl_name PROCEDURE ANALYSE();
select* from tbl_name PROCEDURE ANALYSE(16,256);

第二句告訴PROCEDURE ANALYSE()不要為那些包含的值多於16個或者256個位元組的ENUM型別提出建議。

整型資料優化

儲存人的年齡應該使用哪種資料型別?答:使用tinyint型別(無符號型)

儲存烏龜的年齡應該使用哪種資料型別?答:使用smallinit型別(無符號型)

儲存一個1500萬資料的資料表其主鍵id應該選擇哪種資料型別?答:使用mediumint(無符號型),大約在0-1600萬左右

①考慮空間問題

②考慮範圍問題(unsigned無符號)

字串型別優化

char(length)佔用的空間為 固定的,與內容多少無關;

varchar(length)佔用的空間為 實際內容字元個數*位元組 + 1

如果要儲存一個11位的手機號碼?答:選擇char11)比較合適

如果要儲存一個32位的md5加密密碼?答:選擇char32)比較合適

如果要儲存一個使用者名稱或一個標題,由於不確定具體要存放多少個字元,為了避免空間的浪費建議使用varchar型別。

如果要儲存一個描述資訊(不超過

250個漢字),使用varchar255)比較合適。

如果要儲存一個文字資訊(文章內容),其超過了255個字元,建議使用text文字型別。

時間型別優化

在實際應用中,由於date型別主要用於儲存時間資訊,但是在php中,我們有相關的函式可以對整型資料和時間進行轉化,所以實際應用中,大部分情況儲存時間都是轉化為整型資料直接儲存的

5、列舉型別與集合型別

如果程式中有單選或多選情況,不建議使用varchar型別,而建議使用列舉型別或集合型別。

、IP型別資料的儲存

經常要儲存IP地址,這個時候不建議使用varchar型別來儲存資料,而建議使用整型來儲存IP資訊

//php中ip轉整形

echo ip2long("192.168.1.1");

//整形轉ip

echo long2ip(3232235777);

2、通過拆分提高表的訪問效率

這裡所說的”拆分”,是指對資料表進行拆分。若針對MyISAM型別的表進行,大體有兩種拆分方法。

1 第一種方法是垂直拆分,即把主碼和一些列放到一個表,然後把主碼和另外的列放到另一個表中。

如果一個表中某些列常用,而另一些列不常用,則可以採用垂直拆分,另外,垂直拆分可以使得資料行變小,一個數據頁就能存放更多的資料,在査詢時就會減少I/O次數。其缺點是 需要管理冗餘列,査詢所有資料需要聯合(join)操作。

2 第二種方法是水平拆分,即根據一列或多列資料的值把資料行放到兩個獨立的表中。 水平拆分通常在以下幾種情況下使用。

表很大,分割後可以降低在查詢時需要讀的資料和索引的頁數,同時也降低了索引的層數,提高查詢速度.表中的資料本來就有獨立性.

例如,表中分別記錄各個地區的資料或不同時期的資料, 特別是有些資料常用,而另外一些資料不常用需要把資料存放到多個介質上.

例如,行動電話的賬單表就可以分成兩個表或多個表。最近3個月的賬單資料存在一個表 中,3個月前的歷史賬單存放在另外一個表中,超過1年的歷史賬單可以儲存到單獨的儲存介質上,這種拆分是最常使用的水平拆分方法.

總結: 
水平拆分會給應用增加複雜度,它通常在査詢時需要多個表名,査詢所有資料需要UNION 操作。在許多資料庫應用中,這種複雜性會超過它帶來的優點,因為只要索引關鍵字不大,則 在索引用於査詢時,表中增加2〜3倍資料量,査詢時也就增加讀一個索引層的磁碟次數,所以水平拆分要考慮數量額增長速度,根據實際情況決定是否需要對錶進行水平拆分.

3、逆規範化

資料庫設計時要滿足規範化這個道理大家都非常清楚,甚至有資料庫的三正規化, 好吧, 這有點讓我想起了機器人的三定律.但是否資料的規範化程度越高越好呢?這還是由實際需求來決定。

  • 因為規範化越高,那麼產生的關係就越多,關係過多的直接結果就是導致表之間的連線操作越頻繁,而表之間的連線操作是效能較低的操作,直接影響到査詢的速度,所以,對於査詢較多的應用,就需要根據實際情況運用逆規範化對資料進行設計,通過逆規範化來提高査詢的效能。

    例如,行動電話的使用者每月都會査詢自己的賬單,賬單資訊一般包含使用者的名字和本月消費總金額,設想一下,如果使用者的姓名和屬性資訊存放在一個表中,假設表名為A,而使用者的 編號和他對應的賬單資訊存放在另外一張B表中,那麼,使用者每次查詢自己的月賬單時,資料庫査詢時都要進行表連線,因為賬單表B中並不包含使用者的名字,所以必須通過關聯A表取 過來,如果在資料庫設計時考慮到這一點,就可以在B表增加一個冗餘欄位存放使用者的名字, 這樣在査詢賬單時就不用再做表關聯,可以使査詢有更好的效能。

反規範的好處是降低連線操作的需求、降低外碼和索引的數目,還可能減少表的數目,相 應帶來的問題是可能出現數據的完整性問題。加快查詢速度,但會降低修改速度。因此,決定 做反規範時,一定要權衡利弊,仔細分析應用的資料存取需求和實際的效能特點,好的索引和 其他方法經常能夠解決效能問題,而不必採用反規範這種方法。

在進行反規範操作之前,要充分考慮資料的存取需求、常用表的大小、一些特殊的計算(例 如合計)、資料的物理儲存位置等。常用的反規範技術有增加冗餘列、增加派生列、重新組表 和分割表。

  • 增加冗餘列:指在多個表中具有相同的列,它常用來在查詢時避免連線操作。
  • 增加派生列:指增加的列來自其他表中的資料,由其他表中的資料經過計算生成。增 加的派生列其作用是在查詢時減少連線操作,避免使用集函式。
  • 重新組表:指如果許多使用者需要檢視兩個表連接出來的結果資料,則把這兩個表重新 組成一個表來減少連線而提高效能.

另外,逆規範技術需要維護資料的完整性。無論使用何種反規範技術,都需要一定的管理 來維護資料的完整性,常用的方法是批處理維護、應用邏輯和觸發器。 
1. 批處理維護是指對複製列或派生列的修改積累一定的時間後,執行一批處理作業或存 儲過程對複製或派生列進行修改,這隻能在對實時性要求不高的情況下使用. 
2. 資料的完整性也可由應用邏輯來實現,這就要求必須在同一事務中對所有涉及的表進 行增、刪、改操作.用應用邏輯來實現資料的完整性風險較大,因為同一邏輯必須在所有的應 用中使用和維護,容易遺漏,特別是在需求變化時,不易於維護。 
3. 另一種方式就是使用觸發器,對資料的任何修改立即觸發對複製列或派生列的相應修 改,觸發器是實時的,而且相應的處理邏輯只在一個地方出現,易於維護•一般來說,是解決 這類問題比較好的辦法。

4、使用中間表提高統計查詢速度

對於資料量較大的表,在其上進行統計查詢通常會效率很低,並且還要考慮統計查詢是否會對線上的應用產生負面影響。通常在這種情況下,使用中間表可以提高統計查詢的效率,下面通過對session 表的統計來介紹中間表的使用:
(1)session 表記錄了客戶每天的消費記錄,表結構如下:
CREATE TABLE session (
cust_id varchar(10) , --客戶編號
cust_amount DECIMAL(16,2), --客戶消費金額
cust_date DATE, --客戶消費時間
cust_ip varchar(20) –客戶IP 地址
)
(2)由於每天都會產生大量的客戶消費記錄,所以session 表的資料量很大,現在業務部門有一具體的需求:希望瞭解最近一週客戶的消費總金額和近一週每天不同時段使用者的消費總金額。針對這一需求我們通過2 種方法來得出業務部門想要的結果。
方法1:在session 表上直接進行統計,得出想要的結果。
mysql> select sum(cust_amount) from session where cust_date>adddate(now(),-7);
+------------------+
| sum(cust_amount) |
+------------------+
| 161699200.64 |
+------------------+
1 row in set (3.95 sec)


方法2:建立中間表tmp_session,表結構和源表結構完全相同。
CREATE TABLE tmp_session (
cust_id varchar(10) , --客戶編號
cust_amount DECIMAL(16,2), --客戶消費金額
cust_date DATE, --客戶消費時間
cust_ip varchar(20) –客戶IP 地址
) ;

轉移要統計的資料到中間表,然後在中間表上進行統計,得出想要的結果。
mysql> insert into tmp_session select * from session where cust_date>adddate(now(),-7);
Query OK, 1573328 rows affected (6.67 sec)
Records: 1573328 Duplicates: 0 Warnings: 0
mysql> select sum(cust_amount) from tmp_session;
+------------------+
| sum(cust_amount) |
+------------------+
| 161699200.64 |
+------------------+


1 row in set (0.73 sec)


從上面的2 種實現方法上看,在中間表中做統計花費的時間很少(這裡不計算轉移資料花費的時間),另外,針對業務部門想了解“近一週每天不同時段使用者的消費總金額”這一需求,在中間表上給出統計結果更為合適,原因是源資料表(session 表)cust_date 欄位沒有索引並且源表的資料量較大,所以在按時間進行分時段統計時效率很低,這時可以在中間表上對cust_date 欄位建立單獨的索引來提高統計查詢的速度。中間表在統計查詢中經常會用到,其優點如下:
 中間表複製源表部分資料,並且與源表相“隔離”,在中間表上做統計查詢不
會對線上應用產生負面影響。
 中間表上可以靈活的新增索引或增加臨時用的新欄位,從而達到提高統計查詢
效率和輔助統計查詢作用。