O. *_*nes 14
TL;博士.使用microtime(false)并将结果存储在MySQL bigint中,以百万分之一秒为单位.否则你必须学习浮点运算,这是一个很大的毛球.
PHP microtime函数从一个系统调用中获取Unix时间戳(当前大约为十六进制50eb7c00或十进制1,357,609,984),并从另一个系统调用获取微秒时间.然后它将它们变成一个字符串.然后,如果你用(true)调用它,它会将该数字转换为64位IEEE 745浮点数,这是PHP调用的一个东西float.
截至今天,您需要在小数点左侧使用十位十进制数来存储整数UNIX时间戳.直到大约公元2280年,当你的后代开始需要11位数时,这种情况仍然存在.你需要在小数点右边六位数来存储微秒.
您不会获得总微秒精度.大多数系统保持其亚秒级系统时钟的分辨率在1-33毫秒的范围内.它取决于系统.
MySQL 5.6.4及更高版本允许您指定DATETIME(6)列,这些列将日期和时间保持为微秒分辨率.如果您正在使用这样的MySQL版本,那绝对是可行的方法.
在5.6.4版之前,您需要使用MySQL DOUBLE (IEEE 754 64位浮点)来存储这些数字.MySQL FLOAT(IEEE 754 32位浮点)在其尾数中没有足够的位来完全准确地存储甚至当前的UNIX时间(以秒为单位).
你为什么要存储这些时间戳？你希望这样做吗？
WHERE table.timestamp = 1357609984.100000
或类似的查询来查找特定项目？如果你在处理链的任何地方使用浮点数或双数字(即使你microtime(true)甚至只使用一次),那就充满了危险.即使你认为应该这样做,他们也因为不平等而臭名昭着.相反,你需要使用这样的东西.在0.001被称为"小量"的数字加工贸易.
WHERE table.timestamp BETWEEN 1357609984.100000 - 0.001
AND 1357609984.100000 + 0.001
或类似的东西.如果将这些时间戳存储为列中的小数或百万分之一秒,则不会出现此问题bigint.
IEEE 64位浮点具有53位尾数 - 精度.当前的UNIX Epoch时间戳(自1970年1月1日 - 00:00Z以来的秒)乘以100位使用51位.因此,如果我们关心低阶位,那么DOUBLE中没有太多额外的精度.另一方面,精度不会耗尽几个世纪.
使用int64(BIGINT)远远没有精度.如果我实际上只是存储微秒时间戳只是为了在MySQL中对它们进行排序,我会选择,DATETIME(6)因为我会免费获得大量的日期算术.如果我在做内存大批量应用程序,我会使用int64.