VirtualBox环境Ubuntu Server改MySQL密码时查mysql.user全表后终端乱码

该现象既不属于Ubuntu系统配置损坏、MySQL运行逻辑故障，也不是VirtualBox的硬件模拟类bug，本质是VirtualBox内置文本终端的转义序列处理缺陷，叠加MySQL宽表输出的字符流触发了终端状态机错乱。

各维度异常排除 #

• Ubuntu系统层面：系统默认终端编码、shell环境均未出现损坏。单独执行SELECT user FROM mysql.user;可以正常返回结果，说明终端的基础渲染能力正常；退出MySQL后乱码仍留存，只是终端的字符解码状态被外部输入的错误转义序列临时修改，并非系统文件、编码配置出现持久故障。
• MySQL层面：MySQL的查询逻辑、数据存储均无异常。SELECT * FROM mysql.user;返回的所有字段值（包括密码哈希值、权限标识等）都是按定义的表结构正常存储返回，即便你之前设置的密码是字面量<db-password>，MySQL也只会将其转换为合规的哈希值存储，不会主动生成乱码、更不会修改终端的显示状态。
• VirtualBox层面：问题属于内置终端的兼容性缺陷，而非功能故障。VirtualBox默认的文本控制台对不完整的CSI控制转义序列没有做边界过滤，当输出的字符流碰巧包含终端控制指令片段（比如字符集切换、光标重定位、显示属性修改的转义码）时，终端会直接修改自身的解码状态，且因为转义序列不完整，状态机卡在错误的解码模式上，不会自动恢复。

初始猜测的误区澄清 #

• 你猜测的authentication_string字段密码哈希，本身为固定长度的十六进制可见字符，正常存储状态下不会包含能触发终端乱码的控制字符；单独查询user字段时显示正常，是因为该字段为纯用户名文本，输出字符全为可见ASCII，不会拼接生成异常转义序列。
• 你提到的密码中包含的<、-、>特殊字符不是触发乱码的直接原因——这类字符属于标准可见ASCII，本身不会触发终端异常；真正的触发点是全表查询时输出的列宽计算、长字符串拼接过程中，字符流碰巧形成了不完整的终端控制转义序列，才导致虚拟终端渲染异常。

可落地的解决方法 #

• 乱码状态即时恢复：不需要重启虚拟机，在当前乱码的终端界面盲输命令reset后按回车，终端的状态机会自动重置为正常的UTF-8显示模式，乱码会立刻消失。
• 避免同类问题重复出现：
  • 日常查询用户表时，避免直接执行SELECT * FROM mysql.user全表查询，改为手动指定需要查询的字段，缩短输出的字符流长度，减少转义序列触发概率。
  • 修正之前配置的非规范密码：进入MySQL交互界面后，执行合规的用户密码修改语句，将带尖括号的字面量密码替换为常规字符组合的密码，执行FLUSH PRIVILEGES生效即可。
  • 长期使用建议：替代VirtualBox内置文本终端，通过SSH工具连接Ubuntu Server操作，SSH终端对转义序列的处理兼容性远高于VirtualBox内置控制台，不会出现同类状态卡死问题。

内容的提问来源于stack exchange，提问作者Darren Quinn