MySQL MEMBER OF 判断 JSON 数组成员时为什么类型不匹配

MySQL 的 MEMBER OF() 不是把数组转成字符串再搜索，而是判断左侧值是否等于 JSON 数组中的一个完整元素。数组里存的是数字 1 时，查询字符串 "1" 不会自动变成同一个 JSON 数字；反过来也一样。先统一应用参数和 JSON 数组的值域，类型不匹配的问题就能稳定复现和修正。

官方文档：https://dev.mysql.com/doc/refman/8.4/en/json-search-functions.html

为什么 1 和 "1" 在 MEMBER OF 里不是一回事

先用两个数组把问题缩小。下面的示例没有依赖业务表，便于确认问题来自 JSON 类型，而不是索引或 ORM。

SELECT
  1 MEMBER OF(JSON_ARRAY(1, 2)) AS number_hit,
  '1' MEMBER OF(JSON_ARRAY(1, 2)) AS string_in_number_array,
  '1' MEMBER OF(JSON_ARRAY('1', '2')) AS string_hit;
-- 第一列为 1；第二列为 0；第三列为 1，分别表示数字域和字符串域的比较结果。

第一列的左侧是 JSON 数字，第二列的左侧是 SQL 字符串，右侧数组元素是 JSON 数字；第三列则让两边都落在字符串域。不要只看 SQL 字面量的外观，关键是表达式传给 JSON 比较器后被当成了哪一种 JSON 值。

先确认两侧到底是什么 JSON 类型

排查时先看数据，不要马上把条件改成 LIKE。假设 user_profile.labels 保存了标签数组，可以同时准备数字数组和字符串数组：

CREATE TABLE user_profile (
  id BIGINT PRIMARY KEY,
  labels JSON NOT NULL
);

INSERT INTO user_profile (id, labels) VALUES
  (1, JSON_ARRAY(1, 2)),
  (2, JSON_ARRAY('1', '2'));
-- 同一个可见文本 1，分别落在 JSON 数字域和 JSON 字符串域。

查询时把数组原值带出来：

SELECT
  id,
  labels,
  1 MEMBER OF(labels) AS numeric_probe,
  CAST(JSON_QUOTE('1') AS JSON) MEMBER OF(labels) AS string_probe
FROM user_profile;
-- numeric_probe 检查数字 1；string_probe 检查 JSON 字符串 "1"。

如果一行只有 numeric_probe=1，说明数组保存的是数字 1；如果只有 string_probe=1，说明它保存的是字符串 "1"。这一步能把“查询没查到”拆成可验证的类型差异。

按数据域修正查询值，别用字符串模糊替代类型判断

修正方式取决于业务字段的真实定义，而不是取决于前端传来的是数字还是字符串。用户年龄、状态码这类字段应统一为数字；外部系统编号、带前导零的编码则应统一为字符串。

-- 数字标签：参数 ? 应该代表可校验的无符号整数。
SELECT CAST(? AS UNSIGNED) MEMBER OF(labels) FROM user_profile;

-- 字符串标签：先 JSON_QUOTE，再转成 JSON 字符串值。
SELECT CAST(JSON_QUOTE(?) AS JSON) MEMBER OF(labels) FROM user_profile;

-- 对象标签：对象数组用 JSON_ARRAY 构造，避免把对象当普通文本。
SELECT JSON_OBJECT('code', 'vip') MEMBER OF(
  JSON_ARRAY(JSON_OBJECT('code', 'vip'))
);
-- 三个示例分别对应数字、字符串和对象的精确成员判断。

不要用 labels LIKE '%1%' 代替成员判断：它可能把 10 或对象中的其他文本一起命中，也无法表达 JSON 元素的类型边界。

用结果清单核对 NULL、部分匹配和索引边界

MEMBER OF() 返回 1 表示命中，0 表示没有相同的完整元素；左值或数组为 SQL NULL 时返回 NULL，它不是“未命中”。应用层如果只把结果转成布尔值，可能把数据库的未知状态误当成否定。

• 先记录数组实际类型：数字数组、字符串数组还是对象数组。
• 再记录参数来源：绑定参数是数值、普通字符串，还是已经编码的 JSON。
• 最后分别测试精确命中、类型不同、NULL 和相似但不相等的值。

当条件直接作用于 InnoDB 的 JSON 列时，MySQL 文档还给出了使用多值索引优化 MEMBER OF() 的方向；但索引只能改善访问路径，不能把数字和字符串变成同一种 JSON 值。先把数据域定下来，再评估索引，排错顺序会更可靠。

相关问题

MEMBER OF 能判断字符串的一部分吗？

不能。它判断完整数组元素，'a' 不会因为数组里有 'abc' 就命中。

为什么 MEMBER OF 返回 NULL 而不是 0？

只要左侧值或目标数组为 SQL NULL，结果就是 NULL；应用层应单独处理这个状态。

数字字符串能不能直接 CAST 成 JSON？

要先明确要的是 JSON 数字还是 JSON 字符串。数字参数可转为数值类型；字符串参数应按 JSON 字符串构造，不能只看文本内容相同。

JSON_OBJECT 为什么要配合 JSON_ARRAY？

MEMBER OF() 的右侧必须是 JSON 数组。对象数组应由 JSON_ARRAY(JSON_OBJECT(...)) 生成，保持数组和元素的 JSON 类型都正确。