这问题我碰到过不少，核心原因其实是你的MariaDB 5.5.60版本不支持带小数秒的DATETIME类型，咱们一步步拆解你遇到的现象和解决办法：

为什么会出现这些问题？ #

MariaDB从10.0.1版本才开始引入小数秒支持（也就是DATETIME(n)、TIMESTAMP(n)这类带精度的日期类型），而你用的5.5.60是更早的版本，完全不认识DATETIME(3)这种写法，所以才会出现各种异常：

1. Workbench图形界面提示“No Changes Detected” #

当你在Workbench里尝试把字段改成DATETIME(3)时，Workbench会先检测当前数据库版本支持的类型。因为5.5不支持这个类型，它会自动判定你的修改是无效的，所以提示“没有检测到变更”，根本不会把修改提交到数据库。

2. 执行ALTER语句后出现“Error Parsing DLL”错误 #

你手动执行的ALTER TABLE语句里用了DATETIME(3)，但数据库无法识别这个类型，所以这条语句实际上没有生效——表字段还是原来的DATETIME类型。Workbench在读取表结构时，可能因为之前记录了你执行的带精度的语句，和实际返回的表结构产生冲突，导致解析DDL时出错。

你可以执行这条命令验证一下实际的表结构：

SHOW CREATE TABLE ALLOCATED_HISTORY;

会看到DATE_EFFECTIVE字段仍然是DATETIME类型，没有任何精度后缀。

解决方案 #

根据你的需求，有两种可选方向：

方案1：升级MariaDB版本（推荐） #

如果你的业务需要存储毫秒级时间，最根本的解决办法是把MariaDB升级到10.0.1或更高版本。升级后，DATETIME(3)就能正常使用，不管是Workbench图形界面还是手动执行ALTER语句都能生效。

方案2：绕过版本限制存储毫秒（临时方案） #

如果暂时无法升级数据库，可以用替代方案存储毫秒：

• 新增一个INT类型的字段（比如DATE_EFFECTIVE_MS），用来存储毫秒数，和原有的DATETIME字段配合使用；
• 或者把时间存储为字符串类型（格式如'YYYY-MM-DD HH:MM:SS.fff'），但这种方式会失去日期类型的索引、排序等查询优势，只适合临时场景。

内容的提问来源于stack exchange，提问作者pundip