问题现象
问题单：22.2.12.100升级到22.2.13.100失败
现象：如下图，从22.2.12.100升级到22.2.13.100失败，报错。
问题风险及影响
版本升级失败，影响上线
问题发生版本
客户版本：22.2.12.100
现在版本已经修改掉这个问题，升级比较时忽略掉"----"开头的分隔符和结果前后的空格。
问题发生原因
表现原因：执行升级脚本，/home/yashan2/yasdb_home/yashandb/22.2.13.100/upgrade_tmp/admin/upgrade/22.2.12/preupgrade.sql后，结果和preupgrade.out匹配失败，导致升级失败。
根因：服务端是gbk、客户端是utf-8编码。yasql对于gbk和utf打印格式不同，导致结果匹配失败
解决方式及规避方法
规避方法：
原生客户端和升级客户端编码格式都设置为GBK编码
1、vi 22.2.12.100/client/yasc_env.ini
CHARACTER_SET=GBK
2、vi 22.2.13.100/client/yasc_env.ini
CHARACTER_SET=GBK
3、./bin/yasboot cluster upgrade -c yashandb --package /home/yashan2/tmp_upgrade/yashandb-22.2.13.100-linux-x86_64.tar.gz
可以正常升级成功。
解决方式：提问题单修改
问题分析和处理过程
问题分析：
查看yasagent.log，发现是执行脚本后，报错。
对比preupgrade.out结果文件，发现是"----------"长度对比不上，导致的问题
代码分析：
-
asqlPrintColumnTitles打印列头信息，根据columns[i].colWidth长度来做
-
columnDesc->colWidth = (CodInt16)MIN(columnDesc->bindSize, ASQL_MAX_DISPLAY_WIDTH);
-
bindsize = column->size*maxRatio + 1
-
maxRatio 默认为1；当客户端和服务端编码不一致时，maxRatio = clientMaxWidth > serverMinWidth ? (clientMaxWidth - 1) / serverMinWidth + 1 : 1;
确认根因为编码不同导致的问题，然后定下规避方案
经验总结
yashandb版本升级流程中，会调用preupgrade.sql、postupgrade.sql脚本，并比较结果判断是否升级成功。
标签：12.100,升级,YashanDB,编码,GBK,22.2,13.100 From： https://www.cnblogs.com/YashanDB/p/18324826