对于过于晦涩进入的原因，我有一个特定时间的毫秒表示，我有充满MySQL时间戳MySQL数据库和我很好奇，如果有可能只是做SQL本机的比较如select * from myTable where time_stamp_column > 1264665600000;或沿着这些线路。是否可以将一个MySQL TIMESTAMP与毫秒进行比较？
我一直在运行一些测试，结果非常奇怪。它不会投诉，但返回的行不符合标准。
在此先感谢。
[编辑] 好吧，如果在mySql中使用毫秒是非启动器，假设我在millis中开始并在java中进行比较，最好的方法是比较日期。
你没有得到毫秒精度，但在你的例子年底的零来看，你可能不需要它。
使用FROM_UNIXTIME到Unix时间戳转换到MySQL时间戳。它看起来像你必须毫秒自Unix纪元，所以只是将它们划分由1000转换：
SELECT * FROM myTable WHERE time_stamp_column > FROM_UNIXTIME(1264665600000/1000);
你可能因为SQL时间戳，完全令人沮丧，本地时间在这里调整时区/ DST问题。
显然，这是一个已知的bug：Bug 8523。见Once upon a timestamp(milliseconds)...
公平起见，MySQL的有确实 提供一种方法来保留毫和 微秒小数场
DECIMAL(17,3)，它也是 可查询，就好像它是一个时间戳 但为什么ISN” t有可能在 中存储一个DATETIME或TIMESTAMP字段？
不，TIMESTAMP和DATETIME列不幸以毫秒的精度存储值。解决此问题的方法是使用BIGINT列，并将您的时间戳设置为适当的毫秒数，即。 1264808431000.不幸的是，这意味着您的应用程序或MySQL中的任何比较逻辑必须以BIGINT为基础。
我不觉得这是一个个人缺陷。整数数据库和数据访问层的整数更简单，更统一，而不是混乱的日期类型。这可能不是意识形态上的纯粹，但没有实际的缺点;每次都是INT/BIGINT时间戳。 – bobince 2010-01-30 00:00:27
@bobince - 我觉得有时候会觉得有些笨拙，它确实使得使用某些RDBMS特定的日期函数变得更加困难。另一方面，有时你可以使用INT在记录上保存一个或两个字节。这是一个相当情况下的决定。 – zombat 2010-01-30 00:29:51
是的，我不这样做是为了节省存储空间，我做了预测：不必担心的DateFormats和时区这是我考虑的UI层的一部分，而不是任何我想要靠近我的后端数据存储在任何地方。我认为将我的时间戳转换为字符串非常愚蠢，因为MySQL可以将它转换回存储的时间戳（只有当本地时区被忽略时）。 – bobince 2010-01-30 09:15:12
如果你想在MySQL这个功能，随时让MySQL的开发团队知道通过表决对MySQL官方工作日志：
http://forge.mysql.com/worklog/task.php?id=946
http://blogs.mysql.com/peterg/2009/08/07/fractional-seconds-precision-in-mysql-datetime-data-types/
不，不，你说得对，我根本不关心毫秒级的精确度，我甚至可以通过已经减少了3个数量级的数字...我认为这将起作用。 – 2010-01-30 01:03:00