MYSQL是不是内部还有一层编码？

Question

在建数据库的时候指定数据库的编码为GBK，这样就数据库的编码被设置为了GBK。但是在MYSQL执行SQL的时候它是用的什么编码呢？
我做了几个项目，发现就算指定了数据库编码为GBK，但是MYSQL在执行SQL的时候和自己指定的编码并不一致，最明显的就是注释语句中的中文，如：
/*你好*/
select * from aaa where bb='世界';
这个上面的“你好”就会变成乱码！奇怪的是“世界”没有变成乱码。

Answer 1

MYSQL的编码涉及到好几个方面
现show variables like '%char%';
看是不是都是GBK；终端输入的时候
先SET NAMES GBK;
确保终端是GBK编码。

Answer 2

先看下这个吧
CREATE ALGORITHM=UNDEFINED DEFINER=`root`@`localhost` SQL SECURITY DEFINER VIEW `isusedby1` AS select count(`infor_report_data`.`id`) AS `isusedby1_total`,`infor_report_data`.`cname` AS `cname` from `infor_report_data` where (`infor_report_data`.`is_used_by_1` = _gbk'ʇ') group by `infor_report_data`.`cname`;
这个是用PM导出的，如果就这样再导回去，肯定会出错。问题是，现在MYSQL是可以正常查询的，也就是说，里面的那个乱码'ʇ'在MYSQL内部是可以识别的，但是我不知道此时MYSQL到底是用的什么编码！
我突然发觉，除了视图，其他的表默认都为GBK编码（即PM中的“整理”），而视图竟然没有编码，如果以“表”的概念来看视图，那么，这个“视图表”此时应该就是MYSQL数据库安装时候的编码（可能就是LANTIN1），不知道是否有方法来指定这个“视图表”的编码吗？

Answer 3

呵呵
稍微有点眉目了
我直接DUMP出来的文件，如果使用ANSI编码打开，则视图的SQL显示正常，使用UTF8打开，视图是乱码，但是其他的非视图则正常
看来我的猜测是对的，MYSQL安装的时候是UTF8，而视图所产生的虚拟表由于无法设置字符集，所以继承了最高级的字符集设置，也就是MYSQL安装时候的字符集，被设置成了UTF8。这也就是为什么导出的SQL有两种字符集的问题。不管用什么文本查看器，都不可能同时支持UTF8和GB，所以总有一部分是乱码。
要解决这个问题，只有将全部数据库的字符集设置为UTF8,或者更改MYSQL数据库字符集为GB（个人猜测）。
大家有遇到我这个问题的吗？

Answer 4

现在进一步明白了
因为我在新建数据库的时候指定编码为GBK，所以建的视图会强行将字符加上“_gbk''”并以GBK编码保存,但是，上面说过“视图表”的问题，所以，打印出来的视图结构又会以UTF8形式显示，于是就出现了“_gbk'?????'”的问题
注意，以上都是个人猜测，有待高人解答