COALESCE从左到右返回首个非NULL值，后续参数不求值；全NULL时返回NULL；要求参数类型兼容，否则隐式转换可能出错；在WHERE中使用会导致索引失效，应改用IS NULL OR =；不处理空字符串等假空值，需配合NULLIF预处理。
COALESCE在MySQL中怎么处理多个NULL参数
它从左到右逐个检查，遇到第一个非NULL就立刻返回，后面的参数根本不会求值。比如COALESCE(NULL, NULL, 'hello', SUBSTRING('world', 1, 2))结果是'hello'，最后那个SUBSTRING压根没执行——这点对含子查询或函数调用的场景特别关键。
所有参数必须类型兼容，否则MySQL会尝试隐式转换，可能出意外：COALESCE(123, 'abc')返回123（数值优先级高），但COALESCE('abc', 123)返回'abc'（因为第一个就非NULL）。如果真要混合类型，建议显式CAST。
- 全为
NULL时结果就是NULL，不会自动转成空字符串或0 -
''（空字符串）、0、FALSE都不是NULL，会被当作有效值返回 - 想排除空字符串？得先用
NULLIF(col, '')把它转成NULL，再喂给COALESCE
多字段优先级取值时顺序写错会怎样
顺序决定逻辑走向，写反了就完全达不到兜底效果。比如用户显示名要按“昵称 > 真实姓名 > 邮箱前缀”取值，正确写法是：COALESCE(nickname, real_name, SUBSTRING(email FROM 1 FOR POSITION('@' IN email) - 1))。
如果把real_name放在第一位，而它恰好有值，后面字段哪怕更“合适”也永远用不上。典型错误是把业务优先级和SQL执行顺序搞混——数据库不理解“哪个更重要”，只认你写的顺序。
- 字段顺序 = 业务兜底顺序，别凭感觉排
- 邮箱前缀提取要用
SUBSTRING加POSITION，但若email为NULL或不含@，整个表达式可能报错；稳妥做法是先用NULLIF兜一层 - 测试时务必覆盖所有字段全
NULL、部分NULL、含空字符串等边界情况
WHERE子句里用COALESCE会导致索引失效
写成WHERE COALESCE(status, 'pending') = 'pending'看起来简洁，但MySQL无法使用status字段上的索引——因为函数包裹后，优化器没法做索引查找。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
等价且高效的做法是拆开：WHERE status IS NULL OR status = 'pending'。同样道理，避免在ON子句、ORDER BY里对字段套COALESCE做匹配，除非你确认该列几乎全是NULL。
- 索引失效不是警告，是真实性能损耗，大表上可能慢几秒甚至几十秒
- 如果真要在
WHERE中统一处理空值逻辑，考虑在应用层预判，或建生成列+索引 -
ORDER BY COALESCE(updated_at, created_at)这类用法可以，但要注意created_at是否也有索引，否则排序仍可能走文件排序
UPDATE语句中COALESCE容易误触全表更新
最常见错误是写成：UPDATE users SET name = COALESCE(name, 'anonymous');——没加WHERE条件，结果所有行都被重写一遍，哪怕name原本有值也白刷一次，触发器、binlog、复制延迟全跟着遭殃。
正确做法是限定范围：UPDATE users SET name = 'anonymous' WHERE name IS NULL;，或者把COALESCE嵌入更复杂的表达式，而不是作为SET的唯一逻辑。
- 参数类型不一致会隐式转换失败，比如
COALESCE(created_at, '2024-01-01')在严格模式下可能报错，建议统一用CAST('2024-01-01' AS DATETIME) - 复杂替换逻辑（如“
NULL填A，空字符串填B，其他转大写”）直接上CASE WHEN，硬套COALESCE只会让SQL越来越难维护 - 子查询当参数时，每次都会执行，别在
UPDATE的SET里反复调用同一个子查询
真正容易被忽略的是：COALESCE只解决NULL，不解决空字符串、0、空白字符这些“假空值”。业务上认为“没填”和数据库里存的是NULL还是''，必须提前对齐，否则再漂亮的COALESCE链也兜不住逻辑漏洞。
