为什么还有很多人不愿意放弃 mysql5.7

[unt]

切换至 8 的过程中究竟有哪些坑

[JinTianYi456]

java8 都没说话，[狗头]

[paradox8599]

我新项目都用 postgres 了

[wangkun025]

操作系统没跟上。

[adoal]

比如那些把聚合查询里 select 非聚合值这种不规范特性当宝又连 only full group by = false 选项都懒得设置的阿狗阿猫…

[NewYear]

为什么要放弃一个运行得好好的项目呢……

对于破坏性升级，除了要代码做兼容，意味着会有新的 bug ，数据库就更麻烦，未必能及时发现，何苦呢……

[NewYear]

另外就是一些新特性用不上，老的语言和版本还是用着很舒服的。

[unt]

@NewYear 主要是不肯学吧，老项目肯定没话讲啊，谁会干这种吃力不讨好的事儿。
我是说现在从 0 开始的项目。

[adoal]

跟你说个真事，上个月我评审了一个服务类项目验收，其中派工单用的平台是 2021 年交付的，竟然用的是 CentOS 6 + Java 6 + Tomcat 6 这个三兄弟全都 EoL 很多年的老六组合。

[unt]

@JinTianYi456 java8 不是挺好的吗

[unt]

@adoal 一套代码，卖 10 年

[mobbdeep]

新项目说不定就是老项目魔改一下呢，用老技术快速交付，省时省力同时满足用户需求的情况下，没什么问题吧

[webshe11]

什么时候出 5.7 了？我还在用 5.5 （ doge

[unt]

开这个标题主要是最近遇到两个事儿：
1. 有一个设备通信业务场景需要 json 数据，这个 json 逻辑很复杂，嵌套了 6 层应该，错任何一个参数设备都无法识别。我说你们就建张表，id,name,json 三个字段足以，所有数据前端往 json 字段里传。可是后端居然说 mysql 处理 json 很麻烦，不干，非要把所有字段拆散，然后返回的时候拼接。我真的会谢。然后我们说那我们把 json 转成字符串存总可以了吧。还是不干…………
2. 还有一件事是万级数据联合查询一次性返回，我在 mysql8 上用 json_ARRAYAGG 秒查，在 5.7 上花了 18s 多，他们在优化速度，速度极限是在 6s 多，始终提不上去，很浪费工作时间

[zealic]

COBOL 表示还能战到 2038 年

[unt]

@mobbdeep 不是，是从 0 开始的，新架构新技术，连服务器都是全新的。而且没有交付压力

[Donaldo]

@unt #15 程序员是老的，或者程序员看的教程是老的，想想看也挺正常，人肯定优先用自己最熟悉的版本来做产出。特别：学习新版本的特性很可能没有什么回报，还会引入不可知的问题。。

[unt]

@Donaldo 话确实如此，没毛病的，比如 centos 我用 7.9 ，node 用 16 ，等等。一个道理。但是 8 应该是趋势吧，早晚要用的，而且某些方面确实优化了一些，代码方面和设计方面能精简不少。我总感觉有些人不肯学。

[Donaldo]

@unt #17 就我个人而言，如果涉及到合作或者工作的项目，那就听领导的/听大伙的，绝不自己多说一句用什么新的好的，确实有这种“谨言慎行，少说少错”的心态。如果是我自己的项目，那我愿意去尝试一下新鲜事物。我估计有一部分人是我这样的心态

[yumizhao888]

一看就是学生。
运行正常的项目傻逼才乱折腾。

[laozhoubuluo]

坑的话肯定是要对着实现和 https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html 来做比对的。而且有些坑如果人员流动比较大的项目或者时间比较长的项目确实很难提前发现，比如 GROUP BY 隐式排序在 8.0.13 移除了之类的。
再比如项目使用的是 MyISAM 引擎，MySQL 5.7 和 8.x 对这个引擎基本没啥优化，没有生命周期限制的部门自然更没有动力去搞升级了。至于从 MySQL 5.6 + MyISAM 切换 MySQL 5.7 + InnoDB 那就又是额外的一堆坑了。

当然新项目那自然应该直接用新东西，这个倒是没啥疑问。MySQL 升级虽说有坑但也相对平顺了，总比 Java 8 升级 Java 11 事情少的多。