在关系型数据库中，VARCHAR 是最常用的字符串数据类型之一，用于存储变长字符数据。对于不了解的用户，可能会不清楚不同数据库中 VARCHAR 的区别。不同数据库对 VARCHAR 的实现逻辑、字符集支持及使用细节存在显著差异，其中 SQL Server 与 PostgreSQL 的差异比较典型，会直接影响查询语法。

　　本文将以 SQL Server 与 PostgreSQL 为例，系统梳理两者中 VARCHAR 的区别，解析加“N”的底层逻辑与使用场景。

SQL Server 与 PostgreSQL 中 VARCHAR 的区别

　　SQL Server 需通过 VARCHAR（非 Unicode）和 NVARCHAR（Unicode）区分字符类型，而 PostgreSQL 的 VARCHAR 本身就是 Unicode 类型，使用更灵活。其主要区别如下：

　　SQL Server 用 VARCHAR 和 NVARCHAR 两种类型区分字符串，是因为历史原因，当时 Unicode 还未流行，需要兼顾单字节编码效率；而 PostgreSQL 的 VARCHAR 则是  Unicode 成为主流后，基于 UTF-8 设计的简化方案 。

为什么查询要对字符串加“N”？

　　在字符串前加 N'...'（N 代表 "National Character Set"）是标识 Unicode 字符串的语法，起源于 SQL Server，但并非其独有。这一语法的核心作用是告诉数据库 —— 该字符串包含 Unicode 字符，需按 Unicode 编码（如 UTF-16）处理，主要用于匹配 NVARCHAR 等 Unicode 类型的字段，其核心目的是区分 “非 Unicode 字符串” 与 “Unicode 字符串”，避免字符转换错误与性能问题。

　　这一设计的根源是 —— SQL Server 早期不支持 UTF-8，需通过 NVARCHAR 类型单独处理 Unicode 字符（如中文），而 VARCHAR 仅支持单字节编码，两者的编码体系完全独立，必须通过 N 前缀明确区分。

何时必须加“N”？何时不需要“N”？

SQL Server 场景

　　当满足以下两个条件时，必须加 N，否则会出现乱码、数据丢失或查询不匹配：

　　- 字符串包含 Unicode 字符 Unicode 字符包括：中文、日文、韩文、俄文、emoji（如 😂）、特殊符号（如 ①）等。

　　- 对应的列类型是 NVARCHAR/NCHAR

　　NVARCHAR 是 SQL Server 专门存储 Unicode 字符的类型，若字符串不加 N，SQL Server 会将其按非 Unicode 编码处理，再强制转换为 NVARCHAR，导致：

　　- 字符丢失：最直接的问题是非英文字符（如中文、日文、俄文、emoji 等）会被错误转换，导致乱码或变成 ?。

　　- 索引失效：隐式转换（VARCHAR → NVARCHAR）会导致 NVARCHAR 列的索引无法使用，查询性能下降。

　　- 数据不匹配：转换后的乱码与 NVARCHAR 列中的正常字符无法匹配，导致查询结果为空。

　　以下场景中，加 N 不仅多余，还可能导致问题：

　　- 列类型是 VARCHAR（非 Unicode 类型）：VARCHAR 不支持 Unicode 字符，若加 N，SQL Server 会将 N'字符串'（Unicode）隐式转换为 VARCHAR 类型，可能导致 Unicode 字符丢失和索引失效。

　　字符串是纯 ASCII 字符，列是 NVARCHAR 时，若字符串仅包含 ASCII 字符如 'Zhang San'，即使列是 NVARCHAR，不加 N 也不会出错（SQL Server 可自动将 ASCII 转换为 Unicode）。但不推荐这么做。若后续字符串新增 Unicode 字符，容易忘记加 N 导致错误。而且，为避免混淆，建议对 NVARCHAR 列的所有字符串常量都加 N。

PostgreSQL 场景：永远不需要加“N”   

　　PostgreSQL 中没有 N 前缀的语法，原因是 —— PostgreSQL 的 VARCHAR 类型默认使用 UTF-8 编码，原生支持所有 Unicode 字符。

小结

　　在使用数据库时，务必要了解清楚，数据库的 VARCHAR 是哪种情况。合理使用 VARCHAR、NVARCHAR 类型和“N”前缀，避免字符串存储乱码、查询失效等问题，确保数据库操作的正确性。

​    ​    ​转自https://www.cnblogs.com/MeteorSeed/p/19062714