在历年的MySQL升级需求中，一个让我很意外的现象是，推动业务从MySQL5.5升级到MySQL5.7的一大因素就是JSON的特性。业务担心从MySQL5.7升级到MySQL8.0的主要原因之一是驱动版本升级，所以对于从MySQL5.7升级到MySQL8.0，整体升级动力明显较低，但规划的一个好处是可以把一些工作放在前面，或者让它的实施更顺利。比如我们新业务的实现，默认是按照MySQL8.0的方案来实现的。如果要说MySQL5.7和MySQL8.0的一些区别，在我看来，变化其实非常大，但是细细盘点之后，很多特性似乎是对业务的一种友好或者透明的支持。细节一：比如我们在MySQL5.7中全面实现了GTID，那么之前createtablexxxasselect*fromxx的使用方式就不行了，那么推荐使用：createtablexxxlikexxxxx;insertintoxxselect*fromxxxxx;这种使用模式，以及MySQL8.0带来的很多特性，都是在体验和性能方面的提升。以前不推荐的模式都可以支持，很多业务方都是事后诸葛亮。我们养成的习惯让我们有点凌乱。细节2：在MySQL5.7中允许使用rank字段，但是在8.0中，因为window函数的原因，rank字段会报错。顺着这样的思路，我们其实就对窗口函数有了一瞥。其实你会发现不仅是rank，字段名first_value也是不行的，而且由此产生的SQL语法错误，一开始可能会让人觉得有点懵。创建表test3（idint主键，first_valuevarchar（30））；ERROR1064(42000):你的SQL语法有错误；检查与您的MySQL服务器版本对应的手册，了解在第1行的'first_valuevarchar(30))'附近使用的正确语法详细信息3：顺便说一下，这里配置了airflow的表结构。MySQL5.7中airflow表结构如下：CREATETABLEkube_resource_version(one_row_idBOOLNOTNULLDEFAULTtrue,resource_versionVARCHAR(255),PRIMARYKEY(one_row_id),CONSTRAINTkube_resource_version_oneK_row_id)(CH,CHECK(one_row_idIN(0,1)));QueryOK,0rowsaffected(0.06sec)MySQL中默认会转换为如下表结构：CREATETABLE`kube_resource_version`(`one_row_id`tinyint(1)NOTNULLDEFAULT'1',`resource_version`varchar(255)DEFAULTNULL,PRIMARYKEY(`one_row_id`))ENGINE=InnoDBDEFAULTCHARSET=utf8;如果查看线上业务的实际数据如下：mysql>select*fromkube_resource_version;+------------+----------------+|one_row_id|resource_version|+------------+------------------+|1||+------------+----------------+1rowinset(0.01sec)貌似是这个boolean类型真的很鸡肋。数据库中已经默认使用tinyint(1)间接转义，但实际上还是错误的。问题是在MySQL5.7可以创建成功，但是在8.0会报错：CREATETABLEkube_resource_version(one_row_idBOOLNOTNULLDEFAULTtrue,resource_versionVARCHAR(255),PRIMARYKEY(one_row_id),CONSTRAINTkube_resource_version_one_row_idCHECK(one_row_id),CHECK(one_row_idIN(0,1)));ERROR3812(HY000):Anexpressionofnon-booleantypespecifiedtoacheckconstraint'kube_resource_version_one_row_id.0比较合理，至少分析后报错比较合理。我觉得8.0对数据层面的要求确实变高了。细节4：如果在MySQL中删除了一个大表，那真是尴尬。在MySQL5.7中，在showprocesslist的输出中有点晚。State和Info栏分别显示：Executingeventanddeletefromxxxxx，而Seconds_Behind_Master显示为0，其实数据已经产生了很多延迟。相反，在MySQL8.0中，State和Info栏分别显示：Applyingbatchofrowchanges(delete)anddeletefromxxxxx可以清楚的表明是批量操作。当然，延迟真的不怎么样，真的很大。小结：MySQL8.0的很多细节还是很接地气的，不能下意识的认为它是100%兼容的。需要保证的东西必须有深入的测试和案例研究来支持。本文转载自微信公众号《杨建荣的学习笔记》，可通过以下二维码关注。转载本文请联系杨建荣学习笔记公众号。
