MYSQL varchar和nvarchar一些学习
背景
先试用 utfmb3的格式进行一下简单验证
注意脚本都是一样的.
create database zhaobsh ;
use zhaobsh ;
create table zhaobsh (zhaobshvarchar varchar(30),zhaobshnvarchar nvarchar(30)) ;
insert into zhaobsh values ('123abc','123abc') ;
insert into zhaobsh values ('abcd赵1234','abcd赵1234') ;
insert into zhaobsh values ('abcde한국12345','abcde한국12345') ;
insert into zhaobsh values ('abcde한국12345',N'abcde한국12345') ;winhex的显示结果
Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F
00010090 31 32 33 61 62 63 31 32 33 61 62 63 0B 123abc123abc
000100A0 0B 00 00 00 18 00 31 00 00 00 02 D0 C4 00 00 00 1 心
000100B0 3C A8 0E 81 00 00 0E A2 01 10 61 62 63 64 E8 B5 <? ? abcd璧
000100C0 B5 31 32 33 34 61 62 63 64 E8 B5 B5 31 32 33 34 ?234abcd璧?234
000100D0 10 10 00 00 00 20 00 3B 00 00 00 02 D0 C5 00 00 ; 信
000100E0 00 3C A8 13 82 00 00 02 D6 01 10 61 62 63 64 65 <?? ? abcde
000100F0 ED 95 9C EA B5 AD 31 32 33 34 35 61 62 63 64 65 頃滉淡12345abcde
00010100 ED 95 9C EA B5 AD 31 32 33 34 35 10 10 00 00 00 頃滉淡12345
00010110 28 FF 5D 00 00 00 02 D0 C6 00 00 00 3C A8 14 81 (] 衅 <?
00010120 00 00 00 8B 01 10 61 62 63 64 65 ED 95 9C EA B5 ? abcde頃滉?
00010130 AD 31 32 33 34 35 61 62 63 64 65 ED 95 9C EA B5 ?2345abcde頃滉?
00010140 AD 31 32 33 34 35 ?2345
需要注意 全新的一个数据库就见了一个表 会产生一个ibd文件
ibd文件大小为 112KB
这个存储的位置在 76页/136页
存储的位置也比较奇怪.MySQL的结果分析
1. 关于ASCII字符集
MySQL采用 utf8mb3的字符集时
不管是 varchar和nvarchar, 其实存储ASCII的编码 使用的位置和大小是完全一样的:
31 32 33 61 62 63 31 32 33 61 62 63
不会因为是 nvarchar 就浪费空间. 跟SQLServer的处理方式不一样.
2. 关于中文汉字
61 62 63 64 E8 B5 B5 31 32 33 34 61 62 63 64 E8 B5 B5 31 32 33 34
因为 赵的 UTF8的编码为:
赵 Unicode (UTF-8) utf-8 E8B5B5
这一点与SQLServer的存储页面是不一样的. SQLServer存储的是 unicode的具体数值:
赵 Unicode utf-16 758D
3. 关于韩文:
61 62 63 64 65 ED 95 9C EA B5 AD 31 32 33 34 35 61 62 63 64 65 ED 95 9C EA B5 AD 31 32 33 34 35
可以看到 韩文的
한국 Unicode (UTF-8) utf-8 ED959CEAB5AD
varchar 和 nvarchar的存储其实是完全一样的.结论
MySQL的 nvarchar其实就是掩人耳目的
MySQL的nvarchar 其实就是 varchar的完全一样的一个别名
这一点PG数据库比较有操守, 觉得没必要有 nvarchar 就没有实现.
SQLServer的国际化其实比 utf8字符集还要早
而且是一个很重视商业和向前兼容的数据库.
所以sqlserver的表现与PG和MySQL其实完全不一样.
SQLServer接纳utf8也很慢也非常晚.
下一步需要验证一下 信创数据库的varchar和nvarchar的相关信息了.