今天解析DEDECMS時發現deder的MYSQL時間字段,都是用php
`senddata` int(10) unsigned NOT NULL DEFAULT '0'; |
隨後又在網上找到這篇文章,看來若是時間字段有參與運算,用int更好,一來檢索時不用在字段上轉換運算,直接用於時間比較!二來以下所述效率也更高。mysql
歸根結底:用int來代替data類型,更高效。web
環境:sql
Windows XP PHP Version 5.2.9 MySQL Server 5.1 |
第一步、建立一個表date_test(非定長、int時間)數據庫
CREATE TABLE `test`.`date_test` ( `id` INT NOT NULL AUTO_INCREMENT , `start_time` INT NOT NULL , `some_content` VARCHAR( 255 ) NOT NULL , PRIMARY KEY ( `id` ) ) ENGINE = InnoDB; |
第二步、建立第二個表date_test2(定長、int時間)函數
CREATE TABLE `test`.`date_test2` ( `id` INT NOT NULL AUTO_INCREMENT , `start_time` INT NOT NULL , `some_content` CHAR( 255 ) NOT NULL , PRIMARY KEY ( `id` ) ) ENGINE = InnoDB; |
第三步、建立第三個表date_test3(varchar、datetime時間)測試
CREATE TABLE `test`.`date_test3` ( `id` INT NOT NULL AUTO_INCREMENT , `start_time` DATETIME NOT NULL , `some_content` VARCHAR( 255 ) NOT NULL , PRIMARY KEY ( `id` ) ) ENGINE = InnoDB; |
第四步、建立第四個表date_test3(char、datetime時間)大數據
CREATE TABLE `test`.`date_test4` ( `id` INT NOT NULL AUTO_INCREMENT , `start_time` DATETIME NOT NULL , `some_content` CHAR( 255 ) NOT NULL , PRIMARY KEY ( `id` ) ) ENGINE = InnoDB; |
ok,如今咱們開始作測試,環境是php,先向各個表插入一百萬條數據。插入的時候分200次,每次進庫5000條。spa
表一執行記錄:頁面運行時間: 26.5997889042 秒,插入的時候發現一個有趣的現象:SELECT count( id ) FROM `date_test` WHERE 1 的結果是100w,而直接select * from `date_test`倒是1,000,374條結果。(後來看到這是一個可能接近的值,請參看MySQL FAQ 3.11)。設計
表二執行記錄:頁面運行時間: 62.3908278942 秒,此次記錄是1,000,066條。
表三執行記錄:頁面運行時間: 30.2576560974 秒,此次的是1,000,224條。
表四執行記錄:頁面運行時間: 67.5393900871 秒,此次的是:1,000,073條。
如今把四個表的start_time字段一一加上索引。
測試四個表的更新,分別update 100條記錄,並記錄時間:
表一:頁面運行時間: 2.62180089951 秒(非定長,int時間)
表二:頁面運行時間: 2.5475358963 秒(定長,int時間)
表三:頁面運行時間: 2.45077300072 秒(varchar,datetime時間)
表四:頁面運行時間: 2.82798409462 秒(char,datetime時間)
測試四個表的讀取,分別select 100條隨機記錄,以主鍵id爲條件查詢,並記錄時間:
表一:頁面運行時間: 0.382651090622 秒(非定長,int時間)
表二:頁面運行時間: 0.542181015015 秒(定長,int時間)
表三:頁面運行時間: 0.334048032761 秒(varchar,datetime時間)
表四:頁面運行時間: 0.506206989288 秒(char,datetime時間)
測試四個表的讀取,分別select 10條隨機記錄,以star_time爲條件查詢,並記錄時間:
表一:頁面運行時間: 30.1972880363 秒(非定長,int時間)
表二:頁面運行時間: 65.1926910877 秒(定長,int時間)
表三:頁面運行時間: 39.7210869789 秒(varchar,datetime時間)
表四:頁面運行時間: 70.4632740021 秒(char,datetime時間)
由於量比較小,因此咱們默認即便是微小的變化,也是有意義的。
結論:
大數據量下,若是存在大量的select * from table where 時間>XX這樣的查詢,在MySQL5.1時使用int換datetime是有意義的。
-----------------------------------------------------------------------------------------
mysql中timestamp,datetime,int類型的區別與優劣
int
1. 佔用4個字節
2. 創建索引以後,查詢速度快
3. 條件範圍搜索可使用使用between
4. 不能使用mysql提供的時間函數
結論:適合須要進行大量時間範圍查詢的數據表
datetime
1. 佔用8個字節
2. 容許爲空值,能夠自定義值,系統不會自動修改其值。
3. 實際格式儲存(Just stores what you have stored and retrieves the same thing which you have stored.)
4. 與時區無關(It has nothing to deal with the TIMEZONE and Conversion.)
5. 不能夠設定默認值,因此在不容許爲空值的狀況下,必須手動指定datetime字段的值才能夠成功插入數據。
6. 能夠在指定datetime字段的值的時候使用now()變量來自動插入系統的當前時間。
結論:datetime類型適合用來記錄數據的原始的建立時間,由於不管你怎麼更改記錄中其餘字段的值,datetime字段的值都不會改變,除非你手動更改它。
timestamp
1. 佔用4個字節
2. 容許爲空值,可是不能夠自定義值,因此爲空值時沒有任何意義。
3. TIMESTAMP值不能早於1970或晚於2037。這說明一個日期,例如'1968-01-01',雖然對於DATETIME或DATE值是有效的,但對於TIMESTAMP值卻無效,若是分配給這樣一個對象將被轉換爲0。
4.值以UTC格式保存( it stores the number of milliseconds)
5.時區轉化 ,存儲時對當前的時區進行轉換,檢索時再轉換回當前的時區。
6. 默認值爲CURRENT_TIMESTAMP(),其實也就是當前的系統時間。
7. 數據庫會自動修改其值,因此在插入記錄時不須要指定timestamp字段的名稱和timestamp字段的值,你只須要在設計表的時候添加一個timestamp字段便可,插入後該字段的值會自動變爲當前系統時間。
8. 之後任什麼時候間修改表中的記錄時,對應記錄的timestamp值會自動被更新爲當前的系統時間。
結論:timestamp類型適合用來記錄數據的最後修改時間,由於只要你更改了記錄中其餘字段的值,timestamp字段的值都會被自動更新。