Go SQL 占位符为什么有的用问号有的用美元符号

Go 里写 SQL 时，MySQL 常见的是问号占位符 ?，PostgreSQL 常见的是美元加序号 $1、$2。这不是 database/sql 随机规定的差异，而是驱动和数据库协议各自接受的参数标记不同。换句话说，先看驱动，再写占位符；不能把一套 SQL 原样拿到另一种驱动上。

为什么 database/sql 不统一占位符

database/sql 提供的是统一的 Go 调用形状，例如 db.QueryRow(query, args...)。查询字符串如何解析、参数标记长什么样，则交给实现 database/sql/driver 的驱动。驱动还要把参数交给具体数据库，因此最终要服从后端的 SQL 方言。

Go 官方文档明确提醒：预处理语句的参数占位符会随数据库和驱动变化，并以 PostgreSQL 的 pq 需要 $1 而不是 ? 为例。下面这张关系图的重点不是执行顺序，而是三层责任边界。

MySQL 用 ?，PostgreSQL 用 $1

以同一个“按用户编号查邮箱”的任务为例，SQL 的业务含义相同，字符串中的参数标记不同。MySQL 驱动文档把 ? 作为调用 Query、Exec 时的占位符；lib/pq 的文档则使用 PostgreSQL 原生的序号标记。

// MySQL：问号按参数出现顺序绑定。
func findEmailMySQL(ctx context.Context, db *sql.DB, id int64) (string, error) {
    var email string
    err := db.QueryRowContext(ctx,
        "SELECT email FROM users WHERE id = ?", id, // 第一个 ? 对应 id
    ).Scan(&email)
    return email, err
}

// PostgreSQL：使用从 $1 开始的序号参数。
func findEmailPostgres(ctx context.Context, db *sql.DB, id int64) (string, error) {
    var email string
    err := db.QueryRowContext(ctx,
        "SELECT email FROM users WHERE id = $1", id, // $1 对应第一个参数
    ).Scan(&email)
    return email, err
}

PostgreSQL 的序号还有一个容易被忽略的特点：同一个占位符可以重复使用。例如条件中两次都引用同一个值时可以写成 $1，调用方仍只传一个参数；而 ? 通常按出现位置配对，重复出现往往意味着要传两次对应参数。实际行为要以所用驱动文档为准。

占位符只放值，不能拼表名和列名

占位符解决的是“把一个值交给数据库绑定”的问题，不是 SQL 语法树的替换器。下面的写法看起来像参数化，实际上不能把 users 当成表名：

// 错误思路：参数只能代表值，不能代表表名。
_, err := db.ExecContext(ctx,
    "SELECT count(*) FROM ? WHERE id = ?", tableName, id,
)

// 正确思路：表名从固定白名单中选择，id 仍然作为参数绑定。
tables := map[string]string{
    "user":  "users",
    "admin": "admin_users",
}
table, ok := tables[kind] // 只允许代码预先声明的表名
if !ok {
    return fmt.Errorf("unsupported table kind: %s", kind)
}
query := "SELECT count(*) FROM " + table + " WHERE id = ?"
_, err = db.ExecContext(ctx, query, id) // id 是值，继续走参数绑定

示例中的表名不是来自用户字符串的直接拼接，而是由固定映射选出。若项目还支持 PostgreSQL，应把最后的 ? 也放进驱动方言层，或者使用明确的查询构造器完成重绑定。不要用 fmt.Sprintf 把用户输入直接塞进值条件；Go 官方 SQL 注入说明把这种做法列为风险。

跨数据库项目怎么维护这类 SQL

如果项目只连接一种数据库，最稳妥的做法是让每个仓储方法直接使用该驱动的语法，并在连接初始化处写清驱动名称。如果同一业务需要适配 MySQL 和 PostgreSQL，可以按下面的清单收口：

迁移时不要做全局的“问号替换美元符号”。先确认驱动、参数顺序、重复参数规则和返回值扫描方式，再为适配层补一条针对真实数据库的集成测试。rows、Stmt 等资源也要按生命周期关闭；这和占位符符号不同，却同样属于查询改造不能漏掉的部分。

相关问题

为什么 PostgreSQL 写成 ? 会报语法错误？

因为当前驱动通常期待 PostgreSQL 的序号参数，例如 $1。把查询和驱动文档中的占位符格式对齐即可，不要先怀疑 QueryRow 本身。

能不能把 $1 当成表名参数？

不能。它表示一个值参数，不会替换 SQL 结构。表名、列名和排序方向应从固定选项中选择。

使用 db.Exec 就不需要关心占位符吗？

仍然需要。Exec 只是表示语句通常不返回行，参数解析依旧由驱动和数据库决定。

记住一个判断顺序：先看连接驱动，再看它接受的占位符；参数值交给绑定接口，SQL 结构交给受控代码。这样从问号切到美元序号时，改的是明确的方言边界，而不是整段业务逻辑。