Mysql timestamp and int storage time

Mysql timestamp and int storage time SQL code www.2cto.com show create table 20130107 date; CREATE TABLE '30301_date' ('id' int (11) NOT NULL AUTO_INCREMENT, 'C _ date' timestamp not null default CURRENT_TIMESTAMP, 'c _ date_long 'int (20) not null, 'idx _ date' timestamp not null default '2017-00-00 00:00:00 ', 'idx _ date_long' int (11) not null, primary key ('id '), KEY '30301_date _ idx_date '('idx _ date'), KEY '20130107d Ate_idx_long '('idx _ date_long') ENGINE = InnoDB contains 90 million data records, all of which are random times. first look at the full table scan without an index www.2cto.com 1: SQL code select COUNT (*) from 20130107 date where c_date BETWEEN DATE ('20140901') and DATE ('20140901 ') this requires 1.54 s 2: SQL code select COUNT (*) from 20130107 date where c_date_long BETWEEN UNIX_TIMESTAMP ('123') and UNIX_TIMESTAMP ('123 ') this is 2.3 s, but we can do this 3: SQL code select UNIX_TIMESTAMP ('20140901'), UNIX_TIM ESTAMP ('200'); obtain the results 20110102 and 1293811200, and then select SQL code COUNT (*) from 1293897600 date where c_date_long BETWEEN 20130107 and 1293811200; the difference between 0.61 s 1 and 2 can be said to compare the gap between int and timestamp. What about the gap between 2 and 3? Is the extra time required for each record to evaluate UNIX_TIMESTAMP ('20140901 ')? Then use the index SQL code select COUNT (*) from 20130107 date where idx_date_long BETWEEN UNIX_TIMESTAMP ('20140901') and UNIX_TIMESTAMP ('20140901'); select COUNT (*) from 20130107 date where idx_date BETWEEN '20160301' and '20160301' are no suspense, and both are instantaneous.