TDengine中varchar与nchar字符类型区别、与MySQL选型对比及说明

一、TDengine中varchar与nchar的核心差异 #

• 编码与长度规则不同：nchar采用Unicode定长编码，单个字符固定占4字节，定义的长度为可容纳的字符总数，比如nchar(10)最多可存储10个任意语言字符，总固定占用40字节；varchar采用UTF-8变长编码，定义的长度为可容纳的最大字节数，英文单字符占1字节，中文占3-4字节，比如varchar(10)最多仅可存储3个左右中文字符。
• 存储填充逻辑不同：nchar为定长存储，存入内容不足定义长度时，会自动补空格填充到固定长度，查询返回时会自动截断尾部填充的空格；varchar为变长存储，仅占用实际内容对应的存储空间，会保留输入的尾部空格。
• 读写性能不同：nchar无需处理变长字段的偏移量计算逻辑，读写性能比同场景下的varchar高15%左右，过滤、聚合查询的性能优势更明显。

二、TDengine与MySQL字符存储的适用场景对比 #

MySQL侧适用逻辑 #

MySQL作为通用关系型数据库，面向通用业务场景，存储空间灵活度和成本优先级更高：

• 字符类型char/varchar的长度定义均为字符数，无需额外计算多语言的字节占用
• 90%以上场景优先使用varchar，仅手机号、身份证号这类完全固定长度的字段才会使用char类型，尽可能节省存储成本。

TDengine侧适用逻辑 #

TDengine作为时序数据库，核心面向物联网、工业互联网等时序数据场景，写入性能和查询效率优先级远高于存储成本：

• 字符字段大多为设备ID、测点编码、分组标签这类长度固定或波动极小的内容，定长的nchar更适配场景特性
• 时序场景下标签字段过滤、分组聚合的操作频率极高，nchar的性能优势会被放大。

三、TDengine字符类型选型细则 #

TDengine官方更推荐优先使用nchar，实际选型可参考以下规则：

• 优先选择nchar的场景：
  • 所有标签字段：比如设备SN、区域编码、设备型号这类高频过滤、分组的标签字段，nchar可带来显著的查询性能提升
  • 长度波动≤3个字符的普通字段：比如事件编码、测点状态描述这类长度变化很小的字段，定长存储的额外空间开销可忽略，性能收益更高
  • 涉及多语言存储的场景：无需计算不同语言的字节占用，直接按实际需要的字符数定义长度即可，不会出现中文存不下的兼容性问题
• 必须选择varchar的场景：
  • 字符长度波动极大的字段：比如设备上报的异常日志、自定义扩展字段，长度可能从几个字符到上千字符，varchar可大幅节省存储空间
  • 需要保留尾部空格的特殊场景：比如存储加密字符串、base64编码内容这类尾部空格有业务含义的场景。

内容的提问来源于stack exchange，提问作者naissance