Re: [討論] PHP 在 MySQL 用 UNIXTIMESTAMP 與 DAT …

看板PHP作者 (3WA問題解決專家)時間15年前 (2010/10/01 22:07), 編輯推噓2(2015)
留言17則, 5人參與, 最新討論串3/3 (看更多)
※ 引述《JoeHorn (每天都在公司玩OLG)》之銘言: : → Kelunyang:用int存實作compare的時候搜尋速度應該也比string這些 09/30 12:52 : → Kelunyang:快吧@@? 09/30 12:53 : 依據這個測試看來,似乎是 DATETIME 比較好: : * MySQL DATETIME vs TIMESTAMP vs INT performance and benchmarking with MyISAM : http://goo.gl/6XZe : * MySQL DATETIME vs TIMESTAMP vs INT performance and benchmarking with InnoDB : http://goo.gl/cOqD : 另外,BETWEEN 的 benchmark 也是值得試試看的。 :p 作者的結論~ Anyway, what I’ve tried to demonstrate was usage scenarios that you’ll need to consider for your own real cases: INT remain smaller in storage (50%) and will only perform better if INSERTs and SELECTs are already fed with an INT value - and this is specially relevant for WRITE-intensive scenarios - but DATETIME alleviates extra responsability/care from the developer. Programmers don’t usually care about this, and want the most flexibility from the database, so it’s up to you to find with them a compromise. I may have provided both enough arguments for an endless discussion, though… 我文章看下來,int 確實比較小又比較快,但: 需注意的是,你在下 select ,查詢的內容必需先行轉成用(timestamp)int 的值去算 才會快 如果你在下查詢還要把資料庫的值翻轉跟你要日期比對,那當然慢。 所以他的圖表才會分成 int 跟 int * 吧 但 如果使用 datetime 就不用考慮這麼多。 如果是這樣,我倒覺得 int 的確比較小,寫查詢時注意一下有沒有先把要查的時間 轉成 (timestamp)的int ,如此一來,確實可以比較快些。 我應該沒看錯文章內容吧,請多指教~ -- 3WA訓練家的工作室 宗旨:諸葛單中,謝謝 個人佈弱格 網址:http://3wa.tw -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 123.240.83.60 ※ 編輯: shadowjohn 來自: 123.240.83.60 (10/01 22:09) ※ 編輯: shadowjohn 來自: 123.240.83.60 (10/01 22:11)

10/01 22:44, , 1F
如果要先轉 INT 才會快,32-bit 的問題呢?
10/01 22:44, 1F

10/01 22:45, , 2F
至於容量... 第一篇就講了...
10/01 22:45, 2F

10/01 22:53, , 3F
除了可以無視的容量,我感覺不到 DATETIME 有啥不好..
10/01 22:53, 3F

10/01 22:53, , 4F
畢竟,目前看來,能放到 9999-12-31 的也就只有它了..XD
10/01 22:53, 4F

10/01 23:16, , 5F
我看你舉例的網頁,我以為你只是要拚大小跟速度...
10/01 23:16, 5F

10/01 23:23, , 6F
如果沒轉換,速度還是比較快啊;轉換則會遇到 overflow...
10/01 23:23, 6F

10/01 23:27, , 7F
話說... 用 BETWEEN,速度的差距應該還會有變化...
10/01 23:27, 7F

10/02 12:57, , 8F
現在寫的程式2019年跑不跑都不知道,誰管他9999年啊 -_-
10/02 12:57, 8F

10/02 22:57, , 9F
喔,請教一下樓上,如果遇到「forever」,該如何定義該值?
10/02 22:57, 9F

10/03 00:32, , 10F
forever不是時間吧?
10/03 00:32, 10F

10/03 02:25, , 11F
不然是什麼? 如果讓你遇到了,明明有時間欄位可用..
10/03 02:25, 11F

10/03 02:25, , 12F
難道還要另外開一個 `forever` 的欄位來記 0 跟 1?
10/03 02:25, 12F

10/03 02:30, , 13F
當時,就是有人沒想 Y2K,有人沒想民國百年,不是嗎?
10/03 02:30, 13F

10/03 23:47, , 14F
forever可以用NULL啊,我自己有用過這樣@@"
10/03 23:47, 14F

10/03 23:48, , 15F
不知道其他人有什麼想法
10/03 23:48, 15F

10/09 14:34, , 16F
只好拿IEEE754的INF來用XD (半誤)
10/09 14:34, 16F

10/09 14:35, , 17F
不過其實應該用NULL就好了 如果沒有需要用到這個狀態的話
10/09 14:35, 17F
文章代碼(AID): #1CfUijK5 (PHP)
文章代碼(AID): #1CfUijK5 (PHP)