choose函数从值列表中按1起始的整数索引返回对应项，索引小于1或大于参数个数时返回null；适用于固定位置映射如状态码转文字，不支持条件判断或范围匹配，且需注意null输入、类型隐式转换及性能影响。
CHOOSE 函数的基本用法和索引规则
CHOOSE 在 SQL Server 2012+ 和 Azure SQL 中可用，它不是“查表”，而是从一组按顺序列出的值中，根据给定的整数索引返回对应项。索引从 1 开始，不是 0 —— 这是绝大多数人第一次用就出错的地方。
语法是：CHOOSE(index, value1, value2, ..., valueN)。如果 index 小于 1 或大于参数个数，结果为 NULL（不报错，但容易漏掉这个边界）。
-
CHOOSE(2, 'a', 'b', 'c')→ 返回'b' -
CHOOSE(0, 'a', 'b')→ 返回NULL -
CHOOSE(3, 'x', 'y')→ 也返回NULL（只有两个值，索引超限）
CHOOSE vs CASE：什么时候该用哪个？
当逻辑是“固定位置映射”（比如状态码转中文名、月份序号转缩写），CHOOSE 比等价的 CASE 更紧凑；但它不能做条件判断或范围匹配，也不能处理动态生成的值列表。
例如把订单状态码 1/2/3 转成文字：
CHOOSE(StatusID, '待付款', '已发货', '已完成')
这比写三层 CASE WHEN StatusID = 1 THEN ... 少一半字符，也更易读。但如果要表达 “StatusID BETWEEN 1 AND 3”，就必须用 CASE。
-
CHOOSE要求所有参数类型兼容（SQL Server 会尝试隐式转换，可能引发意外截断或精度丢失） - 若参数中混用
INT和VARCHAR，最终类型由数据类型优先级决定，建议显式转换统一 - 在 WHERE 子句里慎用
CHOOSE，它无法利用索引，可能拖慢查询
常见错误：NULL 输入、类型不一致与性能陷阱
最常踩的坑是把可能为 NULL 的列直接当 index 参数传进去：CHOOSE(OrderPriority, '低', '中', '高')。一旦 OrderPriority 是 NULL，整个表达式结果就是 NULL，而不是你想看到的默认值。
- 安全写法：用
ISNULL(OrderPriority, 1)或COALESCE(OrderPriority, 1)提供兜底索引 - 混合类型如
CHOOSE(1, 123, 'hello')会把123转成字符串，但若第一个值是DECIMAL(5,2)，后面整数会被转成带两位小数的形式，影响显示 - 在大表 JOIN 中频繁调用
CHOOSE做字段转换，CPU 开销会上升——它本质是运行时逐行计算，没有优化空间
替代方案：兼容性与更灵活的场景
如果你用的是 PostgreSQL、MySQL 或旧版 SQL Server（CHOOSE 根本不可用。此时得靠 CASE 或查找表（lookup table）模拟。
对于需要“动态长度列表”的情况（比如从 JSON 数组取第 N 项），CHOOSE 无能为力，得转向 STRING_SPLIT + ROW_NUMBER() 或 JSON 函数（SQL Server 2016+）。
- PostgreSQL 可用数组下标：
ARRAY['a','b','c'][n]，注意它从1开始，和CHOOSE一致 - MySQL 8.0+ 没有内置类似函数，常用
ELT(n, 'a','b','c')，行为几乎一样，但同样要求n ≥ 1 - 哪怕在支持
CHOOSE的环境里，如果值列表来自配置表，别硬编码进CHOOSE，应改用JOIN—— 更易维护，也支持运行时变更
真正要注意的不是“怎么写对”，而是“它只适合静态、短列表、确定索引的场景”。一但业务规则变复杂，硬塞 CHOOSE 只会让后续人 debug 到怀疑人生。
