鍍金池/ 問答/數(shù)據(jù)庫  網(wǎng)絡(luò)安全/ mysql時(shí)間字段查詢效率的問題?

mysql時(shí)間字段查詢效率的問題?

項(xiàng)目開始的時(shí)候,由于僅僅是標(biāo)記時(shí)間的作用,就把字段設(shè)成varchar(10),就是2017-08-01的樣子。但是到了項(xiàng)目中段的時(shí)候,需要用它判斷時(shí)間前后,經(jīng)常用到sql:select * from table where d>2017-08-01。

目前vchar類型,判斷日期,也還湊合,但是不知道數(shù)據(jù)一多,效率會(huì)不會(huì)下來?

需要重新修改字段屬性嗎?

回答
編輯回答
朕略萌

將日期改成20170801這樣的整型吧,直觀,查詢效率又高。

2017年1月25日 21:59
編輯回答
萢萢糖

數(shù)據(jù)量大時(shí),效率肯定會(huì)降低。如果目前數(shù)據(jù)量不是太大的話,可以修改成int類型

2017年6月28日 02:34
編輯回答
愛礙唉

首先可以說你當(dāng)前的做法并不好 , 確切說 , 非常不好 . 有兩條路子你可以嘗試 .

  1. 將這個(gè)varchar類型修改成datetime等mysql內(nèi)置支持的時(shí)間日期類型 , 添加索引 . 即便修改成日期類型 , 據(jù)我自己的一些經(jīng)驗(yàn) , 我還是要告訴你 , 如果根據(jù)某日期條件篩選出來的 數(shù)據(jù)量/數(shù)據(jù)總量 在超過某個(gè)比例的時(shí)候 , mysql會(huì)走全表掃描 , 不會(huì)走索引 , 你可以通過explain執(zhí)行計(jì)劃多嘗試幾次 .

  2. 將這個(gè)varchar類型改成int類型 , 也就是將日期轉(zhuǎn)換成unix時(shí)間戳 , 然后建立索引 , 效率會(huì)更好一些 .

2018年2月23日 16:28