在 mysql 中 定义 数据库，表，列时，设定的各个的编码格式

 CREATE TABLE `category` ( `Id` binary(16) NOT NULL,
  `UniqueName` varchar(64) NOT NULL,
  `Name` varchar(64) NOT NULL,
  `CreatedAt` datetime NOT NULL,
  PRIMARY KEY (`Id`),
  KEY `IX_Category_UniqueName_CreatedAt` (`UniqueName`,`CreatedAt`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

我把表的编码格式改成 utf8. 查看表category 发现表的DDL 变成了，

 CREATE TABLE `category` (

  `Id` binary(16) NOT NULL,
  `UniqueName` varchar(64)  character set latin1 NOT NULL,
  `Name` varchar(64) character set latin1 NOT NULL,
  `CreatedAt` datetime NOT NULL,
  PRIMARY KEY (`Id`),
  KEY `IX_Category_UniqueName_CreatedAt` (`UniqueName`,`CreatedAt`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

 发现在原来的表中之前定义的列（字段）的编码类型不会因为表的编码格式而变化，还是latin1(拉丁文格式)， 但新建列的类型为是UTF8格式的。由此可见MYSQL中的数据编码格式已经粒子化到 单位“列”。 在建 数据库的时候可以指定数据库编码格式，在这之后所建的表和列的编码格式都会以此格式为默认格式。若之后想改数据库的编码格式的话，想要把之前的表和列的编码格式都改过来的话就要一一改过来了。

  KIGG例子中 EF + MYSQL 的乱码原因是因为程序提交给数据库是文件是UTF8格式的但数据库中字段接收的格式却是latin1 格式的，所以只要将列改为UTF8格式即可。

 总结：对于惯用微软的的SQLSERVER 的用户来说很少观注数据库数据的编码格式，因为微软已经帮用户做完了那些边角的工作，所以使我们忽略很多重要的事。在用MYSQL中要注意 其中的数据库，表，列 对应的编码格式没有包含关系，最终决定内容以什么编码格式保存下来还是 定义列时指定的编码（`Name` varchar(64) character set latin1 NOT NULL,），在建库和表时设置编码格式只是相当与为自己的下一级设置默认编码格式