Grafana下拉变量含INT型id与VARCHAR型name时如何编写兼容WHERE子句

核心思路 #

把原来拆分的两个独立下拉合并为统一的单下拉选项池，通过「展示文本与提交值分离」「查询逻辑加类型前置判断」的方式，既解决双下拉需要反复重置、交互割裂的问题，又避免INT字段匹配字符串时出现的类型报错。

具体配置步骤 #

1. 重构变量选项池，替代双下拉 #

把原来分别生成id选项、name选项的两个独立变量，合并为一个Query类型的Grafana变量，用UNION查询生成统一的选项列表：

-- 语法适配MySQL，可根据自身数据源语法调整
SELECT 
  -- 作为变量实际提交的查询值，统一转为字符串格式
  CAST(id AS CHAR) AS option_value,
  -- 作为下拉给用户展示的文本，加类型标签避免识别混淆
  CONCAT('[ID] ', id, ' | ', name) AS display_text
FROM table
UNION ALL
SELECT 
  name AS option_value,
  CONCAT('[名称] ', name) AS display_text
FROM table

在Grafana变量配置中，把option_value字段绑定为变量值，display_text字段绑定为下拉展示文本：

• 用户看到的每个选项都会明确标注是ID类型还是名称类型，不会和原来无标识的拼接选项一样产生选择困惑
• 变量存储的提交值统一为字符串格式，不管选的是id选项还是name选项，都不会出现格式层面的不兼容

2. 调整查询语句，适配双字段匹配 #

不要直接套用最初的查询语句，因为原始写法中INT类型的id字段如果直接匹配带文本的字符串，会触发数据库类型转换报错。需要增加前置的类型判断逻辑：

SELECT * FROM table
WHERE
  -- 传入值为纯数字时，转为整数匹配id字段
  (${identifier} REGEXP '^[0-9]+$' AND id = CAST(${identifier} AS UNSIGNED))
  OR
  -- 传入值为普通字符串时，直接匹配name字段
  name = '${identifier}'

实操注意事项 #

• 不要给这个变量开「自由输入」权限，所有选项都从数据库实际值生成，避免用户随意输入的内容触发查询报错
• 如果要支持多值选择，需要把上述判断逻辑适配为遍历多值数组的形式，不要直接改成IN()匹配，否则多值拼接后的逗号格式会破坏正则判断逻辑
• 下拉选项的类型标识不要省略，毕竟ID和名称在同个列表里，没有标识用户很容易选错

内容的提问来源于stack exchange，提问作者Mak Suriya Jacobsen