SQLServer 字符集的学习与验证

背景

因为开发JDBC for SQLServer的一群大佬自作主张的进行了 AsUnicode的默认参数值设置.
导致数据库采用了 varchar的列 到出现了隐式转换,有非常大的性能损耗.

单独改过来又担心出现乱码的问题(毕竟这个比较2的选项就是为了解决乱码问题)
没办法的情况下,只能学习一下数据库的相关设置, 但是检查思路比较稀缺

判断 nationaltion的字段数量

select * from sys.types 
主要有如下三个:
ntext 99 nchar 239 nvarchar 231

然后判断数据库中存在的列
注意 id 是我这边自己查的. 

SELECT
	col.name column_name ,
	obj.name table_name
FROM
	sys.columns col
	INNER JOIN sys.objects obj ON col.object_id = obj.object_id 
WHERE
	col.system_type_id IN ( 99, 231, 239 ) AND 
	col.object_id IN ( SELECT object_id FROM sys.objects WHERE schema_ID = 5 ) 
ORDER BY
	2

查看数据库的字符集以及codepage

SELECT SERVERPROPERTY(N'Collation')
SELECT COLLATIONPROPERTY( 'chinese_prc_ci_as', 'codepage' )
第二条查询结果很明显的就是CP936 与windows 系统使用的 GBK字符集是相同的代码页

需要注意 微软从 SQL2019开始支持UTF8
他的字符变的更多了:
SQLServer2012支持的字符集为: 3885条
SQLServer2022支持的字符集为: 5508条

他增加的字符集比如:
SELECT COLLATIONPROPERTY( 'Chinese_Simplified_Pinyin_100_CI_AS_SC_UTF8', 'codepage' )

需要说明
select * from fn_helpcollations() where name like '%chinese%' and name like '%utf8%'
可以看到与之前字符集比较相同的一个:
Chinese_PRC_90_CI_AS_SC_UTF8
Chinese-PRC-90, case-insensitive, accent-sensitive, kanatype-insensitive, width-insensitive, supplementary characters, UTF8

需要说明的是 90/100的关系 100 好像是更新版本的 unicode字符集的含义

一些简单理解

SQLServer 的字符集非常多, 主要是微软的本地化做的足够牛B.
使用GBK字符集时出现 ASCII之外都是双字节字符. 非常便于计算,性能也好,兼容性也好. 

改用UTF8之后会变成变长字符集, 需要进行一定程度的判断,所以性能会比较差. 

理论上改用utf8之后没必要使用 nvarchar的字符类型了.
nvarchar sqlserver 一般默认存 unicode编码. oracle存储的是 utf16编码(Oracle跟java和js类似. )