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位的手機號碼？答：選擇char（11）比較合適
②如果要存儲一個32位的md5加密密碼？答：選擇char（32）比較合適
③如果要存儲一個用戶名或一個標題，由於不確定具體要存放多少個字符，爲了避免空間的浪費建議使用varchar類型。
④如果要存儲一個描述信息（不超過250個漢字），使用varchar（255）比較合適。
如果要存儲一個文本信息（文章內容），其超過了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 字段創建單獨的索引來提高統計查詢的速度。中間表在統計查詢中經常會用到，其優點如下:
中間表複製源表部分數據，並且與源表相“隔離”，在中間表上做統計查詢不
會對在線應用產生負面影響。
中間表上可以靈活的添加索引或增加臨時用的新字段,從而達到提高統計查詢
效率和輔助統計查詢作用。