mysql的字符集设置有多个层级，在mysql中存储中文，如果不能正确设置字符集，很容易出现数据乱码。今天就有一个用户反馈他数据库中的数据下午1点多开始出现了乱码。在这里，我分享下具体问题的排查过程，以及解决的办法。
（1） 排除客户端设置导致的显示乱码
如果用户设置的mysql character_set_client跟客户端显示的字符集不一致，很容易导致中文数据乱码。
设置session字符集为utf8：set names utf8，设置客户端显示字符集为utf8，然后从表中select出有乱码的数据。
上面显示，在character_set_client跟客户端的字符集一致的情况下，还是出现了乱码，这个排除是用户显示字符集设置不对的可能。下面通过hex(item_title)列来查看这个列在底层的存储字符集是否正确。
通过上面的查询，可以确认这个数据乱码不是显示问题，而是存储的数据内容本身就是错误的。
（2） 定位存储乱码原因
1> 用户确认这个记录插入时能够正常显示，但是后来update之后，数据就乱码了。根据这个信息到binlog中查找更改正确内容对应的update语句。
上面的binlog日志显示这个sql将原来数据库中正确的内容，更新成一堆乱码。所以导致数据库中的存储数据乱码。
从binlog日志可以看出在更新时，是用latin1的方式写入到数据库中。Update后面的set语句中item_title字段的内容是乱码的，所以确认是导入数据源本身内容有问题，从而导致更新后的数据乱码。跟用户确认这个update语句的更新内容，是先从库中load 出来，后拼接成的update sql，所以怀疑load出来的数据就已经是乱码了，然后直接用这个错误的数据更新原来正确的数据，导致所有的正确的数据乱码。所以，需要确认这个update导入的数据源是否正确，即load出来的数据是否是正确的。
2> 导入数据源确认
开启实例的全日志开关，然后比对日志，从上面update语句对应的连接运行的sql中查找数据导出语句，以及对应的字符集设置。
从上面的日志内容可以看出，这个连接建立后没有进行任何字符集的设置，直接从数据库中将内容select出来。在mysql中，如果没有设置session级别的字符集，那么使用默认的配置，配置如下：
即输出会按照latin1的格式显示。在默认字符集的配置下，手动运行SELECT `main_table`.* FROM `promo_item` AS `main_table` WHERE promo_item_id ='500186324' 命令，可以发现，在character_set_results 设置为latin1的情况下，输出结果中的item_title确实为一堆问号。
由于latin1不能正确表示中文字符，所以显示为一堆问号，用户直接将这个内容update 原来正确的内容，所以导致存储内容乱码。
（3）小结
在使用mysql存储中文字符时，需要注意以下几点：
1> 确认更新的数据源同mysql 的session级别的字符集保持一致，Session级别的字符集可以用set names charset_name来设置。
2> 如果要正确显示中文，需要将character_set_results设置为GBK或是utf8。同时，客户端的显示字符集需要跟character_set_results的配置一致。
