建表到查询全链路指南)
1. 毫秒精度这件事先搞清楚卡在哪前段时间一位做后端的同行拿着他的订单表来问我说他们系统里同一秒内下的两笔单按创建时间排序翻页的时候顺序会飘第二页偶尔蹦出第一页已经看过的记录。我让他把建表语句发过来一眼就看到问题create_time datetime DEFAULT CURRENT_TIMESTAMP。字段类型没带精度声明默认值也没带精度参数整条链路从上到下都在按秒处理前端传过来的.123毫秒部分在第一个环节就被抹干净了。这类问题在日志、埋点、支付流水、消息投递记录这些场景里特别常见业务方要的是谁先谁后数据库给的却是同一秒中间那点毫秒差就是排序错乱、去重失效、幂等判断出岔子的根源。MySQL 的日期时间字段要精确到毫秒从来不是改一个字段类型就完事的事情。它牵扯到建表语句里的小数秒精度声明、默认值和自动更新子句的写法、JDBC 驱动发送参数的开关、应用层时间对象的精度、SQL 里取当前时间的函数是否带参、格式化函数怎么输出、甚至索引体积和主从复制格式。任何一个环节掉链子最终落库的都是.000。这篇内容我按建表—写入—查询—性能—排查的顺序把这几个环节逐个拆开讲每一处都给你可以直接抄的写法和踩过的坑。适合正在做时间敏感型业务的后端、DBA也适合刚接手老系统、发现时间字段精度不够想升级的同行。1.1 三种时间类型的能力边界与版本门槛先把基础盘清楚。MySQL 里能存日期时间的类型主要有三个DATETIME、TIMESTAMP外加只存时间的TIME。这三个类型都支持小数秒写法是在类型名后面加括号括号里填 0 到 6 的整数表示小数秒位数业内通常叫它fspfractional seconds precision。DATETIME(3)就是精确到毫秒DATETIME(6)精确到微秒DATETIME(0)和不写括号等价精确到秒。DATE类型只存年月日压根没有时间部分别指望它。这个能力有明确的版本门槛MySQL 5.6.4 才开始支持小数秒。5.5 及更早的版本DATETIME(3)这种写法会直接报语法错误。所以如果你接手的是一个跑在老版本上的系统第一步不是改表是先确认版本。用SELECT VERSION();看一眼或者SHOW VARIABLES LIKE version%;。版本低于 5.6.4 的话只能退而求其次用BIGINT存毫秒时间戳或者在应用层把毫秒拼成CHAR(23)的字符串存。这两种土办法我在老项目里都见过BIGINT的好处是排序、比较、索引都快坏处是可读性差写 SQL 排查问题时得手动转字符串方案可读性好但排序是按字典序格式不统一就会出乱子而且没法用日期函数。还有一个容易被忽略的点fsp 上限是 6。你写DATETIME(9)会报错。有些从其他数据库迁过来的同行习惯性地写 9 位纳秒在 MySQL 这里行不通。真需要纳秒级只能自己用BIGINT存纳秒数或者拆成两列。实际业务里毫秒3 位足够覆盖 99% 的场景微秒6 位主要用于金融撮合、高频埋点这类对顺序极度敏感的场合。另外TIME类型也支持 fspTIME(3)表示精确到毫秒的时长或时刻但它只存时分秒不存日期跨天的时间差计算要格外小心负数时长的表示方式也和直觉不太一样。业务里用TIME存营业时间每日提醒时刻是可以的用它算两个时间点之间的间隔就容易踩坑。1.2 精度丢失的四个典型现场我把这些年遇到过的时间精度丢失归纳成四类现场你可以对照自己的系统排查。第一类是建表时压根没写精度。字段是DATETIME或TIMESTAMP括号都没带那这列天生就只能存到秒。这种最常见也最好改一条ALTER TABLE就能解决但要注意存量数据的小数部分本来就已经是 0改完类型也补不回来。第二类是取当前时间的函数没带参数。NOW()、CURRENT_TIMESTAMP、SYSDATE()不带括号里的数字时返回的都是秒精度。哪怕列是DATETIME(3)INSERT INTO t VALUES (NOW())落进去也是.000。必须写成NOW(3)或CURRENT_TIMESTAMP(3)。这个坑极其隐蔽因为 SQL 不报错数据看起来也正常只有做排序或比对时才发现少了三位。第三类是应用层格式化时把毫秒截掉了。比如 Java 里用SimpleDateFormat(yyyy-MM-dd HH:mm:ss)转字符串再拼 SQLDate对象里明明有毫秒格式化模板里没有SSS直接就没了。又比如某些序列化框架默认输出秒级时间戳前端拿到再传回来精度已经丢了一轮。第四类是驱动或连接参数层面被截断。JDBC 驱动某些版本在特定配置下不会发送小数秒或者服务端预处理语句的元数据里精度信息不对导致setTimestamp的值到达服务端时已经被削平。这一类最难查因为代码看起来完全正确得抓包或者开 general_log 才能看到真实发送的 SQL。把这四类记住基本上排查方向就有了。下面按链路顺序展开。2. 建表阶段类型选型与精度声明的写法建表是一切的地基。我见过太多项目在表结构设计阶段随手写个DATETIME等业务跑了半年发现排序有问题再回头改表、改代码、补数据成本翻好几倍。所以在建表时就把精度定下来是最省事的做法。2.1 DATETIME(n) 和 TIMESTAMP(n) 怎么选这两个类型都支持小数秒但底层行为和适用场景差别不小选错了后面会很难受。DATETIME存的是字面时间不带时区信息。你写进去2024-03-15 10:00:00.123读出来就是2024-03-15 10:00:00.123不管服务器时区怎么变、会话时区怎么设值都不变。范围是1000-01-01 00:00:00.000000到9999-12-31 23:59:59.999999够用一辈子。TIMESTAMP存的是 UTC 时间戳写入时按当前会话的time_zone转换成 UTC 存储读取时再转回会话时区。范围窄得多带 fsp 的情况下是1970-01-01 00:00:01.000000UTC 到2038-01-19 03:14:07.999999UTC就是著名的 2038 问题。它的好处是自动处理时区跨时区业务读出来的本地时间是对的。我的选择习惯是业务时间用DATETIME(3)需要跨时区展示的用TIMESTAMP(3)。订单创建时间、支付时间、日志时间这类业务方关心的是当时当地是几点用DATETIME最直观也不会因为数据库服务器迁移到别的时区就整体偏移。而像用户最后登录时间这种要按用户所在时区展示的TIMESTAMP更合适。还有一点要注意TIMESTAMP的小数秒部分在时区转换时是独立保存的不会被转换过程吃掉。这一点不用担心但前提是你的列定义带了 fsp。给一张对照表方便直接查类型存储字节fsp0存储字节fsp3存储字节fsp6时区处理范围上限DATETIME578不转换存字面值9999 年TIMESTAMP467按会话时区转 UTC2038 年TIME356不转换838 小时小数秒的字节数是这么算的fsp 为 1 到 2 占 1 字节3 到 4 占 2 字节5 到 6 占 3 字节。所以DATETIME(3)是 527 字节DATETIME(6)是 538 字节。这个账后面讲性能时还要用。2.2 默认值与自动更新的精度对齐这是最容易报错的地方。很多人建表时写了CREATE TABLE t_order ( id BIGINT PRIMARY KEY, create_time DATETIME(3) DEFAULT CURRENT_TIMESTAMP, update_time DATETIME(3) DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP );执行下去大概率直接抛ERROR 1067 (42000): Invalid default value for create_time。原因就是列声明了 fsp默认值函数也必须带同样的 fsp。正确写法是CREATE TABLE t_order ( id BIGINT PRIMARY KEY, order_no VARCHAR(32) NOT NULL, create_time DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3), update_time DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3) ON UPDATE CURRENT_TIMESTAMP(3) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;DEFAULT和ON UPDATE两处的函数括号都要跟列精度一致少一个就报错。这个规则在 5.6.4 之后的版本都成立我经手过的 5.7 和 8.0 都验证过。还有一个和默认值相关的变量explicit_defaults_for_timestamp。在 5.6 和 5.7 里它默认是OFF意味着表里第一个TIMESTAMP列如果没显式声明NULL和默认值MySQL 会自动给它加上NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP而且这个自动行为是不带 fsp 的。到了 8.0这个变量默认变成ON自动加默认值的行为取消了。跨版本迁移的时候这一条会让表结构悄悄变化建议建表时把所有默认值都显式写全不依赖隐式规则。另外提醒一句sql_mode里如果开了NO_ZERO_DATE和NO_ZERO_IN_DATE5.7 之后默认开启DATETIME列不允许0000-00-00 00:00:00这种零值默认写DEFAULT 0000-00-00 00:00:00.000一样报 1067。要么给个合法默认值要么允许NULL。2.3 存储字节、索引与分区的连带影响精度不是白给的多出来的字节会在存储和索引上放大。单个列多 2 字节看着不多但一张日增百万行的流水表一年就是三亿多行主键加几个时间索引累计的额外空间能到 GB 级别。我在一个日志表上做过对比把三个DATETIME列改成DATETIME(3)单行数据从 186 字节涨到 192 字节看起来只涨了 3%但加上二级索引之后整体表空间涨了接近 8%。这个数字不算吓人但你要提前有预期。索引方面DATETIME(3)作为索引列时InnoDB 的二级索引叶子节点存的是索引列值 主键值索引列从 5 字节变 7 字节如果主键是BIGINT8 字节一条索引记录从 13 字节变 15 字节涨了 15% 左右。范围扫描的页数会略微增加但通常感知不到。真正需要警惕的是把高精度时间列拿来做联合索引的第一列再配合大主键索引膨胀会比较明显。分区表这里有个细节用RANGE COLUMNS(create_time)做分区时分区键支持DATETIME类型包括带 fsp 的。但如果你用RANGE (TO_DAYS(create_time))这种函数分区MySQL 8.0 里对函数分区的支持是受限的而且分区裁剪的效率不如RANGE COLUMNS。我一般建议按RANGE COLUMNS加日期边界来做比如每月一个分区边界值写成2024-04-01 00:00:00.000。注意边界值是小于语义PARTITION p202403 VALUES LESS THAN (2024-04-01 00:00:00.000)这样三月的最后一条23:59:59.999会稳稳落在三月分区里不会因为精度问题越界。3. 写入链路从应用层到库表的全链路保真建表正确只是第一步。数据从应用内存到最终落盘中间要过驱动、连接、SQL 解析好几道关每一道都可能把毫秒削掉。3.1 驱动与连接参数里被忽略的开关Java 生态里最常见的是 JDBC。Connector/J 8.0 系列默认会把java.sql.Timestamp里的小数秒发出去前提是列的类型元数据里带 fsp。但有几个参数会改变这个行为。sendFractionalSeconds这个参数控制是否向服务端发送小数秒默认是true。有些团队为了兼容老版本数据库或者排查问题会把它关掉结果就是所有时间都被截到秒。这个参数在连接串里长这样jdbc:mysql://host:3306/db?sendFractionalSecondstrue。还有一个sendFractionalSecondsForTime专门控制TIME类型默认也是true。serverTimezone8.0 之后推荐用connectionTimeZone必须配。不配的话驱动可能报无法确定服务端时区的错或者干脆按 UTC 处理导致TIMESTAMP列读出来差好几个小时。这个和毫秒精度没直接关系但会把时间整体搞错排查时容易混淆。还有一个隐蔽的点使用服务端预处理语句useServerPrepStmtstrue时参数类型和列类型的匹配更严格。如果代码里用setObject(index, localDateTime)而不指定类型某些驱动版本会按字符串发送服务端再隐式转换精度可能保不住。稳妥的做法是用setTimestamp或setObject时显式传java.sql.Types.TIMESTAMP。至于java.util.Date它本身只有毫秒精度转成Timestamp不会丢但LocalDateTime在 Java 8 上通过LocalDateTime.now()拿到的实际精度取决于系统时钟Linux 上通常是毫秒Java 9 之后可以到微秒。如果你要写DATETIME(6)用 Java 8 的LocalDateTime.now()后三位永远是 0得用Clock.systemUTC().instant()再转换或者直接依赖数据库的NOW(6)。给一段可以直接用的写入代码作为参考String sql INSERT INTO t_order (order_no, create_time, update_time) VALUES (?, ?, ?); try (PreparedStatement ps conn.prepareStatement(sql)) { ps.setString(1, orderNo); ps.setTimestamp(2, Timestamp.valueOf(LocalDateTime.now())); ps.setTimestamp(3, Timestamp.valueOf(LocalDateTime.now())); ps.executeUpdate(); }这里Timestamp.valueOf(LocalDateTime)会保留LocalDateTime的纳秒字段驱动再按列精度发出去。如果你不确定驱动行为最稳的办法是让数据库自己取时间见下一节。3.2 几种常见写法的时间生成位置时间到底在哪一层生成直接决定了精度和一致性。我把常见写法列一下各自的取舍很清楚。写法一数据库取时间NOW(3)。SQL 写成INSERT INTO t_order (order_no, create_time) VALUES (?, NOW(3))。好处是时间源统一所有实例写入的时间都以数据库服务器时钟为准不会因为应用服务器之间有几毫秒时钟差导致顺序错乱。坏处是数据库时钟如果没做好同步整体会偏。另外要记住NOW(3)在一条语句里多次调用返回同一个值这是 MySQL 的保证所以同一行里create_time和update_time用NOW(3)会完全一致做幂等比对时很方便。写法二应用生成LocalDateTime参数传入。好处是应用可以精确控制时间比如从上游消息里带过来的事件时间必须原样落库。坏处是应用服务器之间的时钟偏差会带进数据里多实例部署时尤其明显。这种场景我一般建议配好 NTP并且接受毫秒级乱序这个事实靠业务主键或序列号来保证真正的顺序。写法三前端传毫秒时间戳后端转换。这种在对接前端或移动端时很常见。要注意FROM_UNIXTIME(1700000000123 / 1000)的写法MySQL 里FROM_UNIXTIME接受带小数的秒数返回值会带小数秒。但如果你在应用层用new Date(1700000000123L)再转LocalDateTime精度就是毫秒落DATETIME(6)列时后三位补 0这个不算错只是要知道。写法四SYSDATE(3)。它和NOW(3)的区别是NOW()返回的是语句开始执行的时间SYSDATE()返回的是函数被调用那一刻的时间。绝大多数场景用NOW(3)就够了SYSDATE(3)更适合在长语句里记录实际执行到这一步的时间点。还有个小细节CURRENT_TIMESTAMP(3)和NOW(3)是完全等价的选一个团队内统一就行别一半人写这个一半人写那个搜代码的时候容易漏。3.3 批量写入与存量迁移批量插入时INSERT INTO t (a, b) VALUES (?, NOW(3)), (?, NOW(3))这种写法里多个NOW(3)在同一条语句内返回同一个值。这意味着同一批插入的行时间戳完全一样如果你指望靠时间排序区分批内顺序是做不到的。真需要批内有序得在应用层生成递增的时间或者额外加一个自增序列列。存量数据迁移到高精度列一般的做法是ALTER TABLE t_order MODIFY COLUMN create_time DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3), MODIFY COLUMN update_time DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3) ON UPDATE CURRENT_TIMESTAMP(3), ALGORITHMINPLACE, LOCKNONE;ALGORITHMINPLACE和LOCKNONE能不能用取决于版本和列的变更类型。把DATETIME扩成DATETIME(3)属于扩展存储长度在 5.7 和 8.0 上通常可以走在线 DDL但这个操作会重建表大表上执行时间长建议在低峰期做并且先用pt-online-schema-change或gh-ost之类的工具在影子表上验证。我做过的几次都是几千万行的表用在线工具跑了四十分钟左右业务无感知但磁盘 IO 和主从延迟要盯着。迁移过程中还有个坑主从延迟期间从库上的表结构可能还是旧的。如果这时有读请求打到从库读到的还是秒精度数据。要么在迁移窗口内把读流量切到主库要么接受这个短暂的不一致。4. 查询侧格式化、比较与时区数据存对了读出来还得对。查询这一侧的问题主要集中在格式化函数和区间比较上。4.1 DATE_FORMAT、STR_TO_DATE 与 UNIX_TIMESTAMPDATE_FORMAT的%f占位符输出的是 6 位微秒不管你的列是DATETIME(3)还是DATETIME(0)它都输出 6 位。DATETIME(3)的值2024-03-15 10:00:00.123经过DATE_FORMAT(create_time, %Y-%m-%d %H:%i:%s.%f)会变成2024-03-15 10:00:00.123000。如果你要的是毫秒字符串得自己截LEFT(DATE_FORMAT(create_time, %Y-%m-%d %H:%i:%s.%f), 23)或者用CONCAT(DATE_FORMAT(create_time, %Y-%m-%d %H:%i:%s), ., LPAD(FLOOR(MICROSECOND(create_time)/1000), 3, 0))。后一种写法虽然啰嗦但语义最清楚。STR_TO_DATE反过来格式串里带%f才能解析小数部分返回值是DATETIME(6)。这里有个大坑格式串带%f但输入字符串里没有小数部分函数直接返回NULL。比如STR_TO_DATE(2024-03-15 10:00:00, %Y-%m-%d %H:%i:%s.%f)返回NULL不是报错是静默返回空值。如果你的导入脚本里有这种写法数据会悄悄丢掉一批。稳妥做法是给输入补上.000或者用两个格式串分别尝试。UNIX_TIMESTAMP(create_time)返回的是DECIMAL类型带小数秒。对DATETIME(3)的值返回类似1710471600.123。这个函数在做时间戳比较、导出给前端时很方便。反过来FROM_UNIXTIME(1710471600.123)返回带小数秒的DATETIME精度能保住。但要记住FROM_UNIXTIME的结果最终落到哪个精度的列还是由列定义决定。4.2 区间统计和时区叠加下的精度表现按天、按小时统计是最常见的查询。假设要统计 2024 年 3 月 15 日全天的订单正确写法是SELECT COUNT(*) FROM t_order WHERE create_time 2024-03-15 00:00:00.000 AND create_time 2024-03-16 00:00:00.000;用左闭右开不要用BETWEEN。因为BETWEEN 2024-03-15 00:00:00 AND 2024-03-15 23:59:59在秒精度下没问题但在DATETIME(3)下会漏掉23:59:59.001到23:59:59.999这 999 毫秒的数据。这个坑我见过不止一次统计报表每天少几百单排查了两天才定位到。时区方面TIMESTAMP(3)列在会话时区变化时日期部分可能跨越边界但小数秒部分不受影响。比如 UTC 时间2024-03-15 23:59:59.999在东八区会话里读出来是2024-03-16 07:59:59.999毫秒还是 999。所以按时区分组统计时边界条件要跟着会话时区走别拿 UTC 的日期边界去卡东八区的数据。还有一个和精度相关的排序问题ORDER BY create_time DESC LIMIT 10时如果多行时间完全相同比如批量插入用同一个NOW(3)返回顺序是不确定的翻页会出现重复或遗漏。解决办法是在排序里加一个唯一列兜底ORDER BY create_time DESC, id DESC。这个改动很小但能彻底解决翻页乱序。5. 性能与稳定性精度不是免费的毫秒精度带来的额外字节和时钟依赖在高并发场景下会以另一种方式体现出来。5.1 存储与索引的实测代价前面算过字节账这里给一个更贴近真实的观测。我在一个测试环境里造了两张结构相同的表各 500 万行一张时间列用DATETIME一张用DATETIME(3)都建了(create_time)的二级索引。结果如下指标DATETIME表DATETIME(3)表差异表数据大小约 612 MB约 648 MB5.9%二级索引大小约 138 MB约 156 MB13%单行全表扫描耗时基准2% 左右基本可忽略时间范围查询1 天基准1% 到 3%基本可忽略结论是存储和索引体积的增幅是实打实的查询性能的影响基本可以忽略。所以决策点不在性能而在你是否真的需要毫秒。日志表、流水表这类写入量大、查询以范围扫描为主的场景多出来的 5% 存储换来的排序准确性是值得的。而配置表、字典表这种几万行的小表随便用不用纠结。如果要压存储有个折中方案只在真正需要排序或去重的列上用毫秒精度其他辅助时间列保持秒精度。比如订单表里create_time用DATETIME(3)而sync_time、report_time这种只做展示的列用DATETIME就行。5.2 时钟回拨、单调性与并发写入NOW(3)取的是数据库服务器的系统时间。服务器做了 NTP 同步如果偏差较大被一次性校正系统时间可能出现回拨表现为后写入的数据时间反而更小。这会导致什么问题如果你的业务逻辑依赖时间更大 更新比如增量同步用WHERE update_time #{lastSyncTime}回拨期间写入的数据会被漏掉。应对办法有几个。第一增量同步不要只依赖时间加一个自增 ID 或者版本号做兜底用(update_time, id)组合条件。第二对时间回拨极度敏感的场景用应用侧生成的单调递增序列做主键时间字段只做展示。第三监控数据库服务器的时间偏移SHOW GLOBAL STATUS LIKE Uptime配合系统层面的时间检查偏移超过阈值就告警。并发写入时还有个小现象同一毫秒内写入的多行如果表上有基于时间的唯一索引会冲突。比如你用(user_id, create_time)做唯一键来防重复提交用户手速快一点两次请求落在同一毫秒第二次就报唯一键冲突。这种情况要么把唯一键换成业务令牌要么接受冲突并做幂等处理别指望毫秒精度能完全区分并发。6. 常见问题速查与排查实录这一节把我遇到过的问题整理成对照表遇到现象可以直接查。6.1 报错、现象与根因对照表现象或报错可能原因处理方式ERROR 1067 Invalid default value列声明了 fspDEFAULT或ON UPDATE的函数没带同样的 fsp两处都改成CURRENT_TIMESTAMP(3)这类带参写法建表报语法错误MySQL 版本低于 5.6.4不支持 fsp升级版本或改用BIGINT存毫秒落库的小数部分全是.000字段类型没带(3)或NOW()没带参数改列类型SQL 里改用NOW(3)应用传了毫秒但库里没有格式化模板缺SSS或驱动sendFractionalSecondsfalse检查序列化配置和连接串参数插入.9995变成下一秒.000MySQL 对超出精度的部分做四舍五入会进位业务侧先截断到目标精度再写入避免跨秒STR_TO_DATE返回NULL格式串带%f但输入串没有小数部分输入补齐.000或改用不带%f的格式串按天统计少数据用了BETWEEN ... 23:59:59漏掉毫秒部分改成左闭右开区间翻页出现重复记录排序值相同返回顺序不稳定排序加唯一列兜底如, id DESC从库读到的时间精度不对主从表结构不一致或迁移期间延迟确认表结构已同步迁移窗口切主库读TIMESTAMP读出来差几小时连接串没配时区或会话time_zone不一致配connectionTimeZone统一会话时区关于四舍五入那条值得单独说一句。MySQL 对小数秒的处理是四舍五入不是截断。DATETIME(3)列插入2024-03-15 23:59:59.9996会进位成2024-03-16 00:00:00.000。如果你的业务是按天归档、按分区写入这个进位会让数据落到下一天的分区里跨天对账时对不上。稳妥做法是在应用层就把时间截断到毫秒用LocalDateTime.truncatedTo(ChronoUnit.MILLIS)别让数据库替你做这个决定。6.2 存量数据的精度升级方案最后说一个完整的升级流程从老表到新表我按实际操作顺序写一遍。第一步盘点影响面。查information_schema.columns找出所有DATETIME和TIMESTAMP列按表大小、是否有索引、是否被其他表外键引用排序。优先处理业务核心表日志表可以放后面。SELECT table_schema, table_name, column_name, column_type, column_default, extra FROM information_schema.columns WHERE data_type IN (datetime, timestamp) AND table_schema your_db ORDER BY table_name, ordinal_position;第二步评估锁和耗时。在测试环境的同规模数据上跑一遍ALTER记录耗时。几百万行以内、ALGORITHMINPLACE可用的直接在线改。上千万行的用在线 DDL 工具。第三步改表结构。注意DEFAULT和ON UPDATE两处都要改别只改类型。ALTER TABLE t_order MODIFY COLUMN create_time DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3), MODIFY COLUMN update_time DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3) ON UPDATE CURRENT_TIMESTAMP(3);第四步同步改代码。所有写入这一列的 SQL、ORM 映射、序列化配置、前端时间格式都要跟着改。这一步最容易被遗漏尤其是前后端约定的时间格式前端如果按秒解析多出来的.123可能直接导致解析报错。第五步验证。写一条测试数据用SELECT create_time, MICROSECOND(create_time) FROM t_order ORDER BY id DESC LIMIT 1;确认小数部分不是 0。再跑一遍按天统计的 SQL对比改表前后的数据量确认没有因为边界问题漏数。第六步观察主从和监控。改表后的 24 小时内盯着主从延迟、慢查询、错误日志。DATETIME(3)的隐式转换比DATETIME更容易触发全表扫描如果查询条件里的字面量没带小数部分优化器可能用不上索引。这一点用EXPLAIN确认一下执行计划就行。我个人在几次升级里体会到的是改表本身不难难的是把链路上所有环节都对齐。有一次改完表之后落库还是.000查了半天发现是持久层框架里的自定义 TypeHandler 在设置参数时调用了setObject把一个LocalDateTime当成字符串处理了格式模板里只有到秒。这种问题没有捷径只能沿着链路一段一段抓日志验证。还有一个建议如果你们团队正在做新项目别等到出问题再改。建表规范里直接约定业务时间字段统一用DATETIME(3)默认值写CURRENT_TIMESTAMP(3)SQL 里取时间写NOW(3)把这三条写进 code review checklist能省掉后面 90% 的返工。 
长河君 · 2026/11/3 4:18:05 · 阅读 1.2k MySQL毫秒精度实战：DATETIME(3)建表到查询全链路指南
1. 毫秒精度这件事先搞清楚卡在哪前段时间一位做后端的同行拿着他的订单表来问我说他们系统里同一秒内下的两笔单按创建时间排序翻页的时候顺序会飘第二页偶尔蹦出第一页已经看过的记录。我让他把建表语句发过来一眼就看到问题create_time datetime DEFAULT CURRENT_TIMESTAMP。字段类型没带精度声明默认值也没带精度参数整条链路从上到下都在按秒处理前端传过来的.123毫秒部分在第一个环节就被抹干净了。这类问题在日志、埋点、支付流水、消息投递记录这些场景里特别常见业务方要的是谁先谁后数据库给的却是同一秒中间那点毫秒差就是排序错乱、去重失效、幂等判断出岔子的根源。MySQL 的日期时间字段要精确到毫秒从来不是改一个字段类型就完事的事情。它牵扯到建表语句里的小数秒精度声明、默认值和自动更新子句的写法、JDBC 驱动发送参数的开关、应用层时间对象的精度、SQL 里取当前时间的函数是否带参、格式化函数怎么输出、甚至索引体积和主从复制格式。任何一个环节掉链子最终落库的都是.000。这篇内容我按建表—写入—查询—性能—排查的顺序把这几个环节逐个拆开讲每一处都给你可以直接抄的写法和踩过的坑。适合正在做时间敏感型业务的后端、DBA也适合刚接手老系统、发现时间字段精度不够想升级的同行。1.1 三种时间类型的能力边界与版本门槛先把基础盘清楚。MySQL 里能存日期时间的类型主要有三个DATETIME、TIMESTAMP外加只存时间的TIME。这三个类型都支持小数秒写法是在类型名后面加括号括号里填 0 到 6 的整数表示小数秒位数业内通常叫它fspfractional seconds precision。DATETIME(3)就是精确到毫秒DATETIME(6)精确到微秒DATETIME(0)和不写括号等价精确到秒。DATE类型只存年月日压根没有时间部分别指望它。这个能力有明确的版本门槛MySQL 5.6.4 才开始支持小数秒。5.5 及更早的版本DATETIME(3)这种写法会直接报语法错误。所以如果你接手的是一个跑在老版本上的系统第一步不是改表是先确认版本。用SELECT VERSION();看一眼或者SHOW VARIABLES LIKE version%;。版本低于 5.6.4 的话只能退而求其次用BIGINT存毫秒时间戳或者在应用层把毫秒拼成CHAR(23)的字符串存。这两种土办法我在老项目里都见过BIGINT的好处是排序、比较、索引都快坏处是可读性差写 SQL 排查问题时得手动转字符串方案可读性好但排序是按字典序格式不统一就会出乱子而且没法用日期函数。还有一个容易被忽略的点fsp 上限是 6。你写DATETIME(9)会报错。有些从其他数据库迁过来的同行习惯性地写 9 位纳秒在 MySQL 这里行不通。真需要纳秒级只能自己用BIGINT存纳秒数或者拆成两列。实际业务里毫秒3 位足够覆盖 99% 的场景微秒6 位主要用于金融撮合、高频埋点这类对顺序极度敏感的场合。另外TIME类型也支持 fspTIME(3)表示精确到毫秒的时长或时刻但它只存时分秒不存日期跨天的时间差计算要格外小心负数时长的表示方式也和直觉不太一样。业务里用TIME存营业时间每日提醒时刻是可以的用它算两个时间点之间的间隔就容易踩坑。1.2 精度丢失的四个典型现场我把这些年遇到过的时间精度丢失归纳成四类现场你可以对照自己的系统排查。第一类是建表时压根没写精度。字段是DATETIME或TIMESTAMP括号都没带那这列天生就只能存到秒。这种最常见也最好改一条ALTER TABLE就能解决但要注意存量数据的小数部分本来就已经是 0改完类型也补不回来。第二类是取当前时间的函数没带参数。NOW()、CURRENT_TIMESTAMP、SYSDATE()不带括号里的数字时返回的都是秒精度。哪怕列是DATETIME(3)INSERT INTO t VALUES (NOW())落进去也是.000。必须写成NOW(3)或CURRENT_TIMESTAMP(3)。这个坑极其隐蔽因为 SQL 不报错数据看起来也正常只有做排序或比对时才发现少了三位。第三类是应用层格式化时把毫秒截掉了。比如 Java 里用SimpleDateFormat(yyyy-MM-dd HH:mm:ss)转字符串再拼 SQLDate对象里明明有毫秒格式化模板里没有SSS直接就没了。又比如某些序列化框架默认输出秒级时间戳前端拿到再传回来精度已经丢了一轮。第四类是驱动或连接参数层面被截断。JDBC 驱动某些版本在特定配置下不会发送小数秒或者服务端预处理语句的元数据里精度信息不对导致setTimestamp的值到达服务端时已经被削平。这一类最难查因为代码看起来完全正确得抓包或者开 general_log 才能看到真实发送的 SQL。把这四类记住基本上排查方向就有了。下面按链路顺序展开。2. 建表阶段类型选型与精度声明的写法建表是一切的地基。我见过太多项目在表结构设计阶段随手写个DATETIME等业务跑了半年发现排序有问题再回头改表、改代码、补数据成本翻好几倍。所以在建表时就把精度定下来是最省事的做法。2.1 DATETIME(n) 和 TIMESTAMP(n) 怎么选这两个类型都支持小数秒但底层行为和适用场景差别不小选错了后面会很难受。DATETIME存的是字面时间不带时区信息。你写进去2024-03-15 10:00:00.123读出来就是2024-03-15 10:00:00.123不管服务器时区怎么变、会话时区怎么设值都不变。范围是1000-01-01 00:00:00.000000到9999-12-31 23:59:59.999999够用一辈子。TIMESTAMP存的是 UTC 时间戳写入时按当前会话的time_zone转换成 UTC 存储读取时再转回会话时区。范围窄得多带 fsp 的情况下是1970-01-01 00:00:01.000000UTC 到2038-01-19 03:14:07.999999UTC就是著名的 2038 问题。它的好处是自动处理时区跨时区业务读出来的本地时间是对的。我的选择习惯是业务时间用DATETIME(3)需要跨时区展示的用TIMESTAMP(3)。订单创建时间、支付时间、日志时间这类业务方关心的是当时当地是几点用DATETIME最直观也不会因为数据库服务器迁移到别的时区就整体偏移。而像用户最后登录时间这种要按用户所在时区展示的TIMESTAMP更合适。还有一点要注意TIMESTAMP的小数秒部分在时区转换时是独立保存的不会被转换过程吃掉。这一点不用担心但前提是你的列定义带了 fsp。给一张对照表方便直接查类型存储字节fsp0存储字节fsp3存储字节fsp6时区处理范围上限DATETIME578不转换存字面值9999 年TIMESTAMP467按会话时区转 UTC2038 年TIME356不转换838 小时小数秒的字节数是这么算的fsp 为 1 到 2 占 1 字节3 到 4 占 2 字节5 到 6 占 3 字节。所以DATETIME(3)是 527 字节DATETIME(6)是 538 字节。这个账后面讲性能时还要用。2.2 默认值与自动更新的精度对齐这是最容易报错的地方。很多人建表时写了CREATE TABLE t_order ( id BIGINT PRIMARY KEY, create_time DATETIME(3) DEFAULT CURRENT_TIMESTAMP, update_time DATETIME(3) DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP );执行下去大概率直接抛ERROR 1067 (42000): Invalid default value for create_time。原因就是列声明了 fsp默认值函数也必须带同样的 fsp。正确写法是CREATE TABLE t_order ( id BIGINT PRIMARY KEY, order_no VARCHAR(32) NOT NULL, create_time DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3), update_time DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3) ON UPDATE CURRENT_TIMESTAMP(3) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;DEFAULT和ON UPDATE两处的函数括号都要跟列精度一致少一个就报错。这个规则在 5.6.4 之后的版本都成立我经手过的 5.7 和 8.0 都验证过。还有一个和默认值相关的变量explicit_defaults_for_timestamp。在 5.6 和 5.7 里它默认是OFF意味着表里第一个TIMESTAMP列如果没显式声明NULL和默认值MySQL 会自动给它加上NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP而且这个自动行为是不带 fsp 的。到了 8.0这个变量默认变成ON自动加默认值的行为取消了。跨版本迁移的时候这一条会让表结构悄悄变化建议建表时把所有默认值都显式写全不依赖隐式规则。另外提醒一句sql_mode里如果开了NO_ZERO_DATE和NO_ZERO_IN_DATE5.7 之后默认开启DATETIME列不允许0000-00-00 00:00:00这种零值默认写DEFAULT 0000-00-00 00:00:00.000一样报 1067。要么给个合法默认值要么允许NULL。2.3 存储字节、索引与分区的连带影响精度不是白给的多出来的字节会在存储和索引上放大。单个列多 2 字节看着不多但一张日增百万行的流水表一年就是三亿多行主键加几个时间索引累计的额外空间能到 GB 级别。我在一个日志表上做过对比把三个DATETIME列改成DATETIME(3)单行数据从 186 字节涨到 192 字节看起来只涨了 3%但加上二级索引之后整体表空间涨了接近 8%。这个数字不算吓人但你要提前有预期。索引方面DATETIME(3)作为索引列时InnoDB 的二级索引叶子节点存的是索引列值 主键值索引列从 5 字节变 7 字节如果主键是BIGINT8 字节一条索引记录从 13 字节变 15 字节涨了 15% 左右。范围扫描的页数会略微增加但通常感知不到。真正需要警惕的是把高精度时间列拿来做联合索引的第一列再配合大主键索引膨胀会比较明显。分区表这里有个细节用RANGE COLUMNS(create_time)做分区时分区键支持DATETIME类型包括带 fsp 的。但如果你用RANGE (TO_DAYS(create_time))这种函数分区MySQL 8.0 里对函数分区的支持是受限的而且分区裁剪的效率不如RANGE COLUMNS。我一般建议按RANGE COLUMNS加日期边界来做比如每月一个分区边界值写成2024-04-01 00:00:00.000。注意边界值是小于语义PARTITION p202403 VALUES LESS THAN (2024-04-01 00:00:00.000)这样三月的最后一条23:59:59.999会稳稳落在三月分区里不会因为精度问题越界。3. 写入链路从应用层到库表的全链路保真建表正确只是第一步。数据从应用内存到最终落盘中间要过驱动、连接、SQL 解析好几道关每一道都可能把毫秒削掉。3.1 驱动与连接参数里被忽略的开关Java 生态里最常见的是 JDBC。Connector/J 8.0 系列默认会把java.sql.Timestamp里的小数秒发出去前提是列的类型元数据里带 fsp。但有几个参数会改变这个行为。sendFractionalSeconds这个参数控制是否向服务端发送小数秒默认是true。有些团队为了兼容老版本数据库或者排查问题会把它关掉结果就是所有时间都被截到秒。这个参数在连接串里长这样jdbc:mysql://host:3306/db?sendFractionalSecondstrue。还有一个sendFractionalSecondsForTime专门控制TIME类型默认也是true。serverTimezone8.0 之后推荐用connectionTimeZone必须配。不配的话驱动可能报无法确定服务端时区的错或者干脆按 UTC 处理导致TIMESTAMP列读出来差好几个小时。这个和毫秒精度没直接关系但会把时间整体搞错排查时容易混淆。还有一个隐蔽的点使用服务端预处理语句useServerPrepStmtstrue时参数类型和列类型的匹配更严格。如果代码里用setObject(index, localDateTime)而不指定类型某些驱动版本会按字符串发送服务端再隐式转换精度可能保不住。稳妥的做法是用setTimestamp或setObject时显式传java.sql.Types.TIMESTAMP。至于java.util.Date它本身只有毫秒精度转成Timestamp不会丢但LocalDateTime在 Java 8 上通过LocalDateTime.now()拿到的实际精度取决于系统时钟Linux 上通常是毫秒Java 9 之后可以到微秒。如果你要写DATETIME(6)用 Java 8 的LocalDateTime.now()后三位永远是 0得用Clock.systemUTC().instant()再转换或者直接依赖数据库的NOW(6)。给一段可以直接用的写入代码作为参考String sql INSERT INTO t_order (order_no, create_time, update_time) VALUES (?, ?, ?); try (PreparedStatement ps conn.prepareStatement(sql)) { ps.setString(1, orderNo); ps.setTimestamp(2, Timestamp.valueOf(LocalDateTime.now())); ps.setTimestamp(3, Timestamp.valueOf(LocalDateTime.now())); ps.executeUpdate(); }这里Timestamp.valueOf(LocalDateTime)会保留LocalDateTime的纳秒字段驱动再按列精度发出去。如果你不确定驱动行为最稳的办法是让数据库自己取时间见下一节。3.2 几种常见写法的时间生成位置时间到底在哪一层生成直接决定了精度和一致性。我把常见写法列一下各自的取舍很清楚。写法一数据库取时间NOW(3)。SQL 写成INSERT INTO t_order (order_no, create_time) VALUES (?, NOW(3))。好处是时间源统一所有实例写入的时间都以数据库服务器时钟为准不会因为应用服务器之间有几毫秒时钟差导致顺序错乱。坏处是数据库时钟如果没做好同步整体会偏。另外要记住NOW(3)在一条语句里多次调用返回同一个值这是 MySQL 的保证所以同一行里create_time和update_time用NOW(3)会完全一致做幂等比对时很方便。写法二应用生成LocalDateTime参数传入。好处是应用可以精确控制时间比如从上游消息里带过来的事件时间必须原样落库。坏处是应用服务器之间的时钟偏差会带进数据里多实例部署时尤其明显。这种场景我一般建议配好 NTP并且接受毫秒级乱序这个事实靠业务主键或序列号来保证真正的顺序。写法三前端传毫秒时间戳后端转换。这种在对接前端或移动端时很常见。要注意FROM_UNIXTIME(1700000000123 / 1000)的写法MySQL 里FROM_UNIXTIME接受带小数的秒数返回值会带小数秒。但如果你在应用层用new Date(1700000000123L)再转LocalDateTime精度就是毫秒落DATETIME(6)列时后三位补 0这个不算错只是要知道。写法四SYSDATE(3)。它和NOW(3)的区别是NOW()返回的是语句开始执行的时间SYSDATE()返回的是函数被调用那一刻的时间。绝大多数场景用NOW(3)就够了SYSDATE(3)更适合在长语句里记录实际执行到这一步的时间点。还有个小细节CURRENT_TIMESTAMP(3)和NOW(3)是完全等价的选一个团队内统一就行别一半人写这个一半人写那个搜代码的时候容易漏。3.3 批量写入与存量迁移批量插入时INSERT INTO t (a, b) VALUES (?, NOW(3)), (?, NOW(3))这种写法里多个NOW(3)在同一条语句内返回同一个值。这意味着同一批插入的行时间戳完全一样如果你指望靠时间排序区分批内顺序是做不到的。真需要批内有序得在应用层生成递增的时间或者额外加一个自增序列列。存量数据迁移到高精度列一般的做法是ALTER TABLE t_order MODIFY COLUMN create_time DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3), MODIFY COLUMN update_time DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3) ON UPDATE CURRENT_TIMESTAMP(3), ALGORITHMINPLACE, LOCKNONE;ALGORITHMINPLACE和LOCKNONE能不能用取决于版本和列的变更类型。把DATETIME扩成DATETIME(3)属于扩展存储长度在 5.7 和 8.0 上通常可以走在线 DDL但这个操作会重建表大表上执行时间长建议在低峰期做并且先用pt-online-schema-change或gh-ost之类的工具在影子表上验证。我做过的几次都是几千万行的表用在线工具跑了四十分钟左右业务无感知但磁盘 IO 和主从延迟要盯着。迁移过程中还有个坑主从延迟期间从库上的表结构可能还是旧的。如果这时有读请求打到从库读到的还是秒精度数据。要么在迁移窗口内把读流量切到主库要么接受这个短暂的不一致。4. 查询侧格式化、比较与时区数据存对了读出来还得对。查询这一侧的问题主要集中在格式化函数和区间比较上。4.1 DATE_FORMAT、STR_TO_DATE 与 UNIX_TIMESTAMPDATE_FORMAT的%f占位符输出的是 6 位微秒不管你的列是DATETIME(3)还是DATETIME(0)它都输出 6 位。DATETIME(3)的值2024-03-15 10:00:00.123经过DATE_FORMAT(create_time, %Y-%m-%d %H:%i:%s.%f)会变成2024-03-15 10:00:00.123000。如果你要的是毫秒字符串得自己截LEFT(DATE_FORMAT(create_time, %Y-%m-%d %H:%i:%s.%f), 23)或者用CONCAT(DATE_FORMAT(create_time, %Y-%m-%d %H:%i:%s), ., LPAD(FLOOR(MICROSECOND(create_time)/1000), 3, 0))。后一种写法虽然啰嗦但语义最清楚。STR_TO_DATE反过来格式串里带%f才能解析小数部分返回值是DATETIME(6)。这里有个大坑格式串带%f但输入字符串里没有小数部分函数直接返回NULL。比如STR_TO_DATE(2024-03-15 10:00:00, %Y-%m-%d %H:%i:%s.%f)返回NULL不是报错是静默返回空值。如果你的导入脚本里有这种写法数据会悄悄丢掉一批。稳妥做法是给输入补上.000或者用两个格式串分别尝试。UNIX_TIMESTAMP(create_time)返回的是DECIMAL类型带小数秒。对DATETIME(3)的值返回类似1710471600.123。这个函数在做时间戳比较、导出给前端时很方便。反过来FROM_UNIXTIME(1710471600.123)返回带小数秒的DATETIME精度能保住。但要记住FROM_UNIXTIME的结果最终落到哪个精度的列还是由列定义决定。4.2 区间统计和时区叠加下的精度表现按天、按小时统计是最常见的查询。假设要统计 2024 年 3 月 15 日全天的订单正确写法是SELECT COUNT(*) FROM t_order WHERE create_time 2024-03-15 00:00:00.000 AND create_time 2024-03-16 00:00:00.000;用左闭右开不要用BETWEEN。因为BETWEEN 2024-03-15 00:00:00 AND 2024-03-15 23:59:59在秒精度下没问题但在DATETIME(3)下会漏掉23:59:59.001到23:59:59.999这 999 毫秒的数据。这个坑我见过不止一次统计报表每天少几百单排查了两天才定位到。时区方面TIMESTAMP(3)列在会话时区变化时日期部分可能跨越边界但小数秒部分不受影响。比如 UTC 时间2024-03-15 23:59:59.999在东八区会话里读出来是2024-03-16 07:59:59.999毫秒还是 999。所以按时区分组统计时边界条件要跟着会话时区走别拿 UTC 的日期边界去卡东八区的数据。还有一个和精度相关的排序问题ORDER BY create_time DESC LIMIT 10时如果多行时间完全相同比如批量插入用同一个NOW(3)返回顺序是不确定的翻页会出现重复或遗漏。解决办法是在排序里加一个唯一列兜底ORDER BY create_time DESC, id DESC。这个改动很小但能彻底解决翻页乱序。5. 性能与稳定性精度不是免费的毫秒精度带来的额外字节和时钟依赖在高并发场景下会以另一种方式体现出来。5.1 存储与索引的实测代价前面算过字节账这里给一个更贴近真实的观测。我在一个测试环境里造了两张结构相同的表各 500 万行一张时间列用DATETIME一张用DATETIME(3)都建了(create_time)的二级索引。结果如下指标DATETIME表DATETIME(3)表差异表数据大小约 612 MB约 648 MB5.9%二级索引大小约 138 MB约 156 MB13%单行全表扫描耗时基准2% 左右基本可忽略时间范围查询1 天基准1% 到 3%基本可忽略结论是存储和索引体积的增幅是实打实的查询性能的影响基本可以忽略。所以决策点不在性能而在你是否真的需要毫秒。日志表、流水表这类写入量大、查询以范围扫描为主的场景多出来的 5% 存储换来的排序准确性是值得的。而配置表、字典表这种几万行的小表随便用不用纠结。如果要压存储有个折中方案只在真正需要排序或去重的列上用毫秒精度其他辅助时间列保持秒精度。比如订单表里create_time用DATETIME(3)而sync_time、report_time这种只做展示的列用DATETIME就行。5.2 时钟回拨、单调性与并发写入NOW(3)取的是数据库服务器的系统时间。服务器做了 NTP 同步如果偏差较大被一次性校正系统时间可能出现回拨表现为后写入的数据时间反而更小。这会导致什么问题如果你的业务逻辑依赖时间更大 更新比如增量同步用WHERE update_time #{lastSyncTime}回拨期间写入的数据会被漏掉。应对办法有几个。第一增量同步不要只依赖时间加一个自增 ID 或者版本号做兜底用(update_time, id)组合条件。第二对时间回拨极度敏感的场景用应用侧生成的单调递增序列做主键时间字段只做展示。第三监控数据库服务器的时间偏移SHOW GLOBAL STATUS LIKE Uptime配合系统层面的时间检查偏移超过阈值就告警。并发写入时还有个小现象同一毫秒内写入的多行如果表上有基于时间的唯一索引会冲突。比如你用(user_id, create_time)做唯一键来防重复提交用户手速快一点两次请求落在同一毫秒第二次就报唯一键冲突。这种情况要么把唯一键换成业务令牌要么接受冲突并做幂等处理别指望毫秒精度能完全区分并发。6. 常见问题速查与排查实录这一节把我遇到过的问题整理成对照表遇到现象可以直接查。6.1 报错、现象与根因对照表现象或报错可能原因处理方式ERROR 1067 Invalid default value列声明了 fspDEFAULT或ON UPDATE的函数没带同样的 fsp两处都改成CURRENT_TIMESTAMP(3)这类带参写法建表报语法错误MySQL 版本低于 5.6.4不支持 fsp升级版本或改用BIGINT存毫秒落库的小数部分全是.000字段类型没带(3)或NOW()没带参数改列类型SQL 里改用NOW(3)应用传了毫秒但库里没有格式化模板缺SSS或驱动sendFractionalSecondsfalse检查序列化配置和连接串参数插入.9995变成下一秒.000MySQL 对超出精度的部分做四舍五入会进位业务侧先截断到目标精度再写入避免跨秒STR_TO_DATE返回NULL格式串带%f但输入串没有小数部分输入补齐.000或改用不带%f的格式串按天统计少数据用了BETWEEN ... 23:59:59漏掉毫秒部分改成左闭右开区间翻页出现重复记录排序值相同返回顺序不稳定排序加唯一列兜底如, id DESC从库读到的时间精度不对主从表结构不一致或迁移期间延迟确认表结构已同步迁移窗口切主库读TIMESTAMP读出来差几小时连接串没配时区或会话time_zone不一致配connectionTimeZone统一会话时区关于四舍五入那条值得单独说一句。MySQL 对小数秒的处理是四舍五入不是截断。DATETIME(3)列插入2024-03-15 23:59:59.9996会进位成2024-03-16 00:00:00.000。如果你的业务是按天归档、按分区写入这个进位会让数据落到下一天的分区里跨天对账时对不上。稳妥做法是在应用层就把时间截断到毫秒用LocalDateTime.truncatedTo(ChronoUnit.MILLIS)别让数据库替你做这个决定。6.2 存量数据的精度升级方案最后说一个完整的升级流程从老表到新表我按实际操作顺序写一遍。第一步盘点影响面。查information_schema.columns找出所有DATETIME和TIMESTAMP列按表大小、是否有索引、是否被其他表外键引用排序。优先处理业务核心表日志表可以放后面。SELECT table_schema, table_name, column_name, column_type, column_default, extra FROM information_schema.columns WHERE data_type IN (datetime, timestamp) AND table_schema your_db ORDER BY table_name, ordinal_position;第二步评估锁和耗时。在测试环境的同规模数据上跑一遍ALTER记录耗时。几百万行以内、ALGORITHMINPLACE可用的直接在线改。上千万行的用在线 DDL 工具。第三步改表结构。注意DEFAULT和ON UPDATE两处都要改别只改类型。ALTER TABLE t_order MODIFY COLUMN create_time DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3), MODIFY COLUMN update_time DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3) ON UPDATE CURRENT_TIMESTAMP(3);第四步同步改代码。所有写入这一列的 SQL、ORM 映射、序列化配置、前端时间格式都要跟着改。这一步最容易被遗漏尤其是前后端约定的时间格式前端如果按秒解析多出来的.123可能直接导致解析报错。第五步验证。写一条测试数据用SELECT create_time, MICROSECOND(create_time) FROM t_order ORDER BY id DESC LIMIT 1;确认小数部分不是 0。再跑一遍按天统计的 SQL对比改表前后的数据量确认没有因为边界问题漏数。第六步观察主从和监控。改表后的 24 小时内盯着主从延迟、慢查询、错误日志。DATETIME(3)的隐式转换比DATETIME更容易触发全表扫描如果查询条件里的字面量没带小数部分优化器可能用不上索引。这一点用EXPLAIN确认一下执行计划就行。我个人在几次升级里体会到的是改表本身不难难的是把链路上所有环节都对齐。有一次改完表之后落库还是.000查了半天发现是持久层框架里的自定义 TypeHandler 在设置参数时调用了setObject把一个LocalDateTime当成字符串处理了格式模板里只有到秒。这种问题没有捷径只能沿着链路一段一段抓日志验证。还有一个建议如果你们团队正在做新项目别等到出问题再改。建表规范里直接约定业务时间字段统一用DATETIME(3)默认值写CURRENT_TIMESTAMP(3)SQL 里取时间写NOW(3)把这三条写进 code review checklist能省掉后面 90% 的返工。