CHOOSE函数在SQL Server中按1起始的整数索引从值列表返回对应项，索引超界或为NULL时返回NULL；适用于状态码等固定位置映射，不支持条件判断或范围匹配。
CHOOSE函数在SQL Server里怎么用
CHOOSE 是 SQL Server 2012+ 引入的标量函数，它按整数索引从一串表达式中返回对应位置的值。索引从 1 开始，不是 0 —— 这是初学者最常踩的坑。
基本用法：CHOOSE(index, val1, val2, val3, ...)。如果 index 是 2，就返回 val2；如果是 0、负数或大于参数个数，返回 NULL。
-
CHOOSE(3, 'a', 'b', 'c', 'd')→'c' -
CHOOSE(0, 'x', 'y')→NULL -
CHOOSE(NULL, 'a', 'b')→NULL（任何参数为 NULL，结果就是 NULL）
为什么不能直接替代 CASE WHEN
CHOOSE 看似简洁，但本质只是“位置查表”，不支持条件判断逻辑。它不能替代 CASE WHEN score > 90 THEN 'A'... 这类带比较运算的分支。
常见误用场景：
- 想用
CHOOSE(score/10, 'F','F','F','F','F','D','C','B','A')给分数分级？不行 ——score/10可能是小数，而CHOOSE要求索引是整数，且会截断（8.9变成8），还无法处理边界如 100 分（100/10 = 10，但只有 9 个选项） - 想传变量做动态索引？可以，但必须确保变量是整型且范围可控，否则静默返回
NULL，难排查
CHOOSE 和 IIF、CASE 的性能与可读性对比
在简单等值映射场景下（比如状态码转文字），CHOOSE 比 CASE 更紧凑；但比 IIF（仅支持两分支）表达力强，又不如 CASE 灵活。
实测影响：
- 执行计划上三者几乎无差别，都是简单计算，无额外开销
- 可读性取决于上下文：映射 3–5 个固定值时，
CHOOSE一行搞定；超过 7 个，列太多易错行，不如CASE分段清晰 - 所有参数都会被求值 —— 即使索引是 1，
val2到valN仍会执行（可能触发函数调用、子查询），这点和CASE不同（CASE是短路求值）
实际可用的典型场景示例
适合用 CHOOSE 的地方，一定是「已知索引范围 + 静态值列表」的映射。例如：
SELECT order_id, CHOOSE(status_id, 'Draft', 'Submitted', 'Approved', 'Rejected', 'Shipped') AS status_text FROM orders;
注意点：
-
status_id必须是TINYINT或兼容整型，且只取 1–5；若存在0或6，对应行status_text为NULL，别漏掉数据校验 - 别把复杂表达式塞进参数列表，比如
CHOOSE(id, GETDATE(), SYSDATETIME(), ...)—— 时间函数每次都会执行，浪费且结果不可控 - 跨版本兼容性：SQL Server 2012+ 支持，Azure SQL 支持，但 PostgreSQL / MySQL / Oracle 均无此函数，写之前确认数据库类型
真正要用好 CHOOSE，关键是守住“索引确定、值静态、分支少”这三条线。越想让它干更多事，越容易掉进 NULL 和隐式转换的坑里。
