MySQL5。7和MySQL8。0的4个细节差异

　　在这些年的MySQL升级需求中，让我大跌眼镜的一个现象是：驱动业务从MySQL5。5升级到MySQL5。7的很大一个因素是因为JSON这个特性。
　　而让业务有所顾虑从MySQL5。7升级到MySQL8。0的一个主要原因是：驱动版本升级，所以对于MySQL5。7升级到MySQL8。0来说，总体的升级动力明显要低一些，但是规划的一个优点就是可以把一些工作前置，或者让它的推行更加顺畅，比如我们对于新业务的推行，都是默认按照MySQL8。0的方案来做。
　　如果要说MySQL5。7升级到MySQL8。0的一些差异，从我的角度来说，其实变化是很大的，但是细数盘点，很多特性似乎是对于业务的一种友好或者透明支持。
　　细节1：
　　比如我们在MySQL5。7版本中全面推行GTID，所以之前的createtablexxxasselectfromxx的使用模式就不奏效了，进而我们建议使用：
　　createtablexxxlikexxxxx；
　　insertintoxxxselectfromxxxxx；
　　这种使用模式，而MySQL8。0带来的很多特性是在体验和性能改造方面，原来不建议使用的模式竟然可以支持了，而很多业务侧是后知后觉，原本已经培养的习惯，让我们有些凌乱。
　　细节2：
　　在MySQL5。7中字段名为rank是可以的，但是在8。0中因为有了窗口函数，字段名为rank就报错，顺着这个思路，其实我们一窥窗口函数。
　　其实就会发现不光是rank，字段名是firstvalue也不可以了，随之带来的就是SQL语法错误，可能会让人开始有点抓不着头脑。
　　createtabletest3（idintprimarykey，firstvaluevarchar（30））；
　　ERROR1064（42000）：YouhaveanerrorinyourSQLsyntax；checkthemanualthatcorrespondstoyourMySQLserverversionfortherightsyntaxtousenearfirstvaluevarchar（30））atline1
　　细节3：
　　这里顺便吐槽下airflow的表结构配置
　　airflow的一个表结构在MySQL5。7中如下：
　　CREATETABLEkuberesourceversion（onerowidBOOLNOTNULLDEFAULTtrue，resourceversionVARCHAR（255），PRIMARYKEY（onerowid），CONSTRAINTkuberesourceversiononerowidCHECK（onerowid），CHECK（onerowidIN（0，1）））；QueryOK，0rowsaffected（0。06sec）
　　在MySQL中其实会被默认转换为如下的表结构：
　　CREATETABLEkuberesourceversion（onerowidtinyint（1）NOTNULLDEFAULT1，resourceversionvarchar（255）DEFAULTNULL，PRIMARYKEY（onerowid））ENGINEInnoDBDEFAULTCHARSETutf8；
　　如果查看在线业务的实际数据如下：
　　mysqlselectfromkuberesourceversion；onerowidresourceversion11rowinset（0。01sec）
　　看起来这个boolean类型真是有些鸡肋，在数据库中已经默认使用tinyint（1）来间接转义了，但是实际上还是不对味。
　　带来的问题是在MySQL5。7中可以成功创建，但是在8。0会报错：
　　CREATETABLEkuberesourceversion（onerowidBOOLNOTNULLDEFAULTtrue，resourceversionVARCHAR（255），PRIMARYKEY（onerowid），CONSTRAINTkuberesourceversiononerowidCHECK（onerowid），CHECK（onerowidIN（0，1）））；ERROR3812（HY000）：Anexpressionofnonbooleantypespecifiedtoacheckconstraintkuberesourceversiononerowid。
　　而经过分析，其实8。0的报错提示更加合理，至少我觉得8。0对于数据层面的要求确实变高了。
　　细节4：
　　在MySQL里面如果对一张大表做delete，真是一件让人尴尬的事情，在MySQL5。7里面有点后知后觉，在showprocesslist的输出中。State和Info列分别显示：
　　Executingevent和deletefromxxxxx
　　同时SecondsBehindMaster显示为0，实际上数据已经产生大量延迟了。
　　而相反在MySQL8。0里面，State和Info列分别显示：
　　Applyingbatchofrowchanges（delete）和deletefromxxxxx
　　可以明确的提示出批量操作，当然这延迟确实不体面，真是非常大。
　　简单小结：MySQL8。0里面的很多细节还是很接地气，也不能潜意识的认为是100兼容，要拍胸脯保证的事情，得有深入的测试和案例分析支撑。