MySQL升级过程中的一些心得-1
自己公众号原文链接： https://mp.weixin.qq.com/s/k3sb-AqGXgx37zIrRVcktA
我查了一下9月7日的公众号发过《 MySQL8升级遇到的各式各样问题 》感兴趣的去看看。最近还发现了一些新的。但是我总结来说，问题归问题，但是全都不是数据库的问题。
有人反馈说5.7升级到8以后个别功能写入的时候失败。很奇怪是个别功能，这些功能涉及的表有一个。报错是写入ERROR 1406 (22001): Data too long for column 。如图。
这个比较明显是长度不够，问了一下这个是什么字段。回答是时间。第一感觉时间怎么可能会出现超长？然后马上想到一种情况，有些开发喜欢用字符串代表时间（这是一个很不好的习惯，甚至可以说是错误的）。一看果然是字符串。
而这个表其他时间字段是标准的时间。可能是历史原因吧。我一看字段是varchar(19) 。典型的硬套。因为比如2021-12-22 21:47:52带上空格就是19位。那么我们模拟一下。
给时间字段和字符串字段写入同样的数据。而且是一样的函数。结果是一样。也就是说即使数据类型用错了，只要按照数据库标准获取时间的函数来做也没有问题。那怎么模拟呢？
第3条数据在22后面多加了一个空格。超长了。也就是说的确是多一位是写不进去的。很奇怪的。那么我们先扩一下字段，看看会发生什么吧？
字段加到50以后，走一下程序逻辑，不报错。写入成功了，看了一下表在原有的时间后面加了.0 比如 2021-12-22 21:47:52.0 这都是为什么？不知道，但是一定是框架或者是实现的时候选择了非常规的方式去转换。如果是用数据库自带的，即使数据类型错误也容错了。但是遗憾的是，没有这样做。
上面的驱动典型的MySQL8
运行结果
即使用程序写和用命令行写是一样的。
小结一下：一定要按照规范定义数据结构。而且用常规手段操作数据库最佳。不要用花里胡哨的转换。原生是最好的。
明天打算说另外一个问题。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/637517/viewspace-2849611/ ，如需转载，请注明出处，否则将追究法律责任。
