ELT函数按1起始的数字索引返回对应字符串，索引越界或为0/负数/NULL时返回NULL；适用于固定整数到字符串的等值映射，参数宜≤10个且避免子查询。
ELT函数怎么用：按数字索引取对应字符串
ELT 就是个“查表工具”——你给它一个位置编号（从1开始），它就返回参数列表里对应位置的值。不是数组下标，是严格从 1 开始数：第一个值是第1个，不是第0个。
常见错误是传了 0 或负数，或者索引超出参数个数，这时 ELT 直接返回 NULL，不报错也不提示，容易漏掉逻辑断点。
-
ELT(2, 'apple', 'banana', 'cherry')→'banana' -
ELT(0, 'a', 'b')→NULL -
ELT(5, 'x', 'y')→NULL（只有2个值，索引5越界）
为什么不用CASE WHEN而选ELT：场景和可读性权衡
当你的分支逻辑本质是“根据一个整数列的值，映射到固定几条文本”，比如状态码转中文名、年级编号转年级名称，ELT 比写一长串 CASE WHEN 更紧凑。
但它只支持等值映射，且所有返回值必须是同一类型（MySQL会隐式转换，但可能出意外）。一旦涉及范围判断（如 score >= 90）、空值处理或表达式计算，ELT 就无能为力，硬套反而难维护。
- 适合：
status TINYINT字段，取值固定为1/2/3，想转成'待审'/'通过'/'驳回' - 不适合：把
age分段为'少年'/'青年'/'中年'（需要条件判断） - 注意：
ELT(status, '待审', '通过', '驳回')中，如果status是NULL，结果也是NULL，不会 fallback
参数数量限制和性能影响：别堆几十个值
MySQL 对 ELT 的参数个数没硬性上限，但实际受 max_allowed_packet 和函数内部栈限制。超过 50 个参数时，SQL 可读性骤降，执行计划也可能变慢——因为每个调用都要逐个检查索引是否匹配。
更关键的是，如果参数里混了子查询或函数调用（比如 ELT(1, (SELECT name FROM user WHERE id=1), 'default')），那些表达式会在每次调用时重复执行，哪怕索引根本没选到它。
- 安全建议：参数控制在
10个以内；超了就该考虑用关联表或CASE - 避免在参数里写子查询，尤其不能写相关子查询
- 所有参数会被强制转为字符串比较，
ELT(1, 100, 'abc')返回的是字符串'100'，不是数字
和FIELD函数容易搞混：它们根本不是一对儿
ELT 是“给索引，要值”；FIELD 是“给值，要索引”。名字像，行为相反，用途也不同。FIELD 常用于排序（如 ORDER BY FIELD(status, 3,1,2)），而 ELT 是纯值映射。
有人试图用 ELT(FIELD(x, 'a','b','c'), 'A','B','C') 做双向转换，这不仅绕，还多一层 NULL 风险：如果 x 不在 'a','b','c' 中，FIELD 返回 0，再喂给 ELT 就得 NULL。
- 记法口诀：
ELT= “Index → Value”，FIELD= “Value → Index” -
ELT(2, 'x','y','z')→'y'；FIELD('y', 'x','y','z')→2 - 两者都不支持通配或正则，纯精确匹配
真正麻烦的是索引来源不可靠——比如从另一个表 JOIN 过来的字段可能为 NULL，或类型被隐式转成浮点导致截断（ELT(1.9, 'a','b') 实际取第1个，因为 MySQL 截掉小数部分），这种细节不打日志很难发现。
