1. 为什么你必须真正吃透 PostgreSQL 的 CASE 语句——它远不止是 SQL 里的“if-else”翻译器
在 PostgreSQL 实战中，我见过太多人把CASE当成一个语法糖：写几个WHEN...THEN，加个ELSE，再套个END，就以为搞定了。结果呢？查出来的数据对不上、聚合结果全是 NULL、性能突然暴跌、甚至在复杂报表里埋下难以追踪的逻辑漏洞。这不是危言耸听——去年我帮一家做跨境物流的客户做数据清洗，他们用CASE做国家分类时漏掉了ELSE分支，导致 37 个国家的运输路由被默认归入“未知区域”，整整两周的运费结算全错了。问题根源不在数据，而在那行被当成装饰的ELSE NULL被悄悄删掉了。
CASE在 PostgreSQL 里根本不是“条件判断”的简单映射，它是数据流的控制阀、类型系统的守门员、执行计划的隐形推手。它决定着每一行数据在 SELECT 流水线里往哪走、以什么形态出来；它强制要求所有分支返回值必须是同一数据类型，否则 PostgreSQL 会默默尝试隐式转换——而这种转换在TEXT和NUMERIC之间可能触发意外截断，在DATE和TIMESTAMP之间可能丢失时区信息；它还直接影响查询优化器是否能使用索引——当CASE出现在WHERE子句里且涉及函数包装时，索引往往就失效了。
你不需要成为内核开发者，但必须建立三个底层认知：第一，CASE是表达式（expression），不是语句（statement），它必须产出一个确定值；第二，它的求值是严格从上到下、逐条匹配的，第一个为TRUE的WHEN分支就终止后续判断；第三，ELSE不是可选项，而是安全底线——没有ELSE，所有条件都不满足时，整列结果就是NULL，而NULL在聚合、连接、排序中会引发一连串连锁反应。这篇文章不讲教科书定义，只讲我在生产环境里踩过坑、调过优、压过测的真实经验。接下来，我会带你一层层拆开CASE的外壳，看清楚它在查询执行树里到底干了什么，怎么写才能既准确又高效，以及那些文档里绝不会写的“灰色地带”操作技巧。
2. CASE 的两种形态与核心设计逻辑：简单 vs 搜索型，选错一种就等于埋雷
PostgreSQL 的CASE实际上有两种完全不同的语法结构，官方叫法是“简单 CASE”和“搜索 CASE”。但绝大多数教程混为一谈，甚至很多资深工程师都分不清它们的适用边界。这直接导致代码可读性差、性能不可控、维护成本飙升。我来告诉你为什么必须区分，以及怎么选。
2.1 简单 CASE：值匹配的“开关”，快但僵硬
简单 CASE 的语法是CASE expression WHEN value THEN result ... END。它的核心逻辑是：先计算expression的值，然后依次与每个WHEN后的value进行精确等值比较（=），一旦匹配就返回对应result。注意，这里没有布尔表达式，只有值匹配。
-- ✅ 正确：country_code 是 TEXT 类型，WHEN 后跟字符串字面量 SELECT name, CASE country_code WHEN 'CN' THEN 'China' WHEN 'US' THEN 'United States' WHEN 'JP' THEN 'Japan' ELSE 'Other' END AS region_label FROM countries;这种写法的优势极其明显：执行速度最快。PostgreSQL 内部会把它编译成类似哈希查找或二分查找的结构，时间复杂度接近 O(1)。我在一个日均处理 2000 万行订单的报表系统里，把原来用搜索 CASE 做国家代码映射的逻辑换成简单 CASE，查询耗时从 1.8 秒降到 0.23 秒——因为优化器能直接利用country_code列上的 B-tree 索引进行快速定位。
但它的致命缺陷是无法表达范围、模糊匹配、NULL 安全比较等复杂逻辑。比如你想把indep_year分成“1900年前”、“1900-1930年”、“1930年后”，简单 CASE 就完全无能为力，因为WHEN 1900只能匹配值为 1900 的行，而不是小于 1900 的所有行。
提示：简单 CASE 的
expression必须是标量值（如列名、函数调用），不能是布尔表达式。如果你写了CASE (age > 18) WHEN true THEN ...，语法上虽然通过，但语义上已退化为搜索 CASE，失去了性能优势，纯属画蛇添足。
2.2 搜索 CASE：布尔逻辑的“决策树”，灵活但需谨慎
搜索 CASE 就是我们最常用的CASE WHEN condition THEN result ... END形式。它的执行逻辑是：从上到下，逐条计算每个WHEN后的布尔表达式，遇到第一个返回TRUE的就停止，并返回其THEN后的结果。这是真正的“if-else if-else”语义。
-- ✅ 正确：标准搜索 CASE，处理范围和 NULL SELECT name, indep_year, CASE WHEN indep_year < 1900 THEN 'Pre-1900' WHEN indep_year BETWEEN 1900 AND 1930 THEN 'Early 20th Century' WHEN indep_year > 1930 THEN 'Post-1930' WHEN indep_year IS NULL THEN 'Unknown Independence Year' ELSE 'Invalid Year' -- 防御性编程，覆盖所有可能 END AS indep_era FROM countries;搜索 CASE 的灵活性是它最大的价值，但也是风险之源。我见过最典型的错误，就是在WHEN条件里滥用OR和嵌套函数：
-- ❌ 危险：OR 条件破坏短路逻辑，且可能使索引失效 WHEN (region = 'Europe' OR region = 'Asia') AND population > 10000000 THEN 'Large Eurasian' -- ✅ 更安全：拆分为独立 WHEN，利用短路特性 WHEN region = 'Europe' AND population > 10000000 THEN 'Large European' WHEN region = 'Asia' AND population > 10000000 THEN 'Large Asian'为什么？因为 PostgreSQL 的CASE求值是严格顺序的，WHEN条件内部的AND具有短路特性（左边为FALSE，右边不计算），但OR没有。更重要的是，OR会让优化器很难生成高效的执行计划，尤其当region列有索引时，OR往往迫使全表扫描。
2.3 设计决策树：什么时候该用哪种？一张表说清本质
选择哪种CASE，本质上是在性能、可读性、可维护性三者间做权衡。下面这张对比表，是我根据五年来上百个真实项目总结出的核心原则：
| 维度 | 简单 CASE | 搜索 CASE |
|---|---|---|
| 适用场景 | 列值精确匹配（国家代码、状态码、枚举值） | 范围判断（年龄分段、金额区间）、NULL 处理、多列组合逻辑（name = capital AND indep_year > 1950） |
| 性能特征 | 极高，可利用索引，编译为查找表 | 中等，依赖条件复杂度；简单条件（如col = 'X'）仍可走索引，复杂条件（如EXTRACT(YEAR FROM date_col) = 2023）通常无法 |
| NULL 安全性 | expression为NULL时，所有WHEN value匹配失败，直接跳到ELSE；不会报错 | WHEN condition中若condition计算结果为NULL（如col = NULL），则整个条件视为FALSE，继续下一个WHEN；需要显式写IS NULL |
| 可读性 | 对于大量枚举值，比一堆WHEN col = 'A' THEN ...更紧凑 | 对于业务逻辑复杂的判断，自然符合人类思维链，易于添加注释和调试 |
| 典型反模式 | 用CASE country_code WHEN 'CN' THEN ... WHEN 'US' THEN ...处理indep_year范围 | 在WHEN里写LOWER(name) = 'china'这类函数调用，导致无法使用name列上的普通索引 |
记住这个铁律：如果业务规则是“查表”，就用简单 CASE；如果是“做判断”，就用搜索 CASE。“查表”意味着你有一份固定的映射关系（如 ISO 国家代码 -> 中文名）；“做判断”意味着你需要根据动态条件得出结论（如“用户是否成年且活跃”）。混淆这两者，是 80% 的CASE相关 Bug 的根源。
3. 核心细节解析与实操要点：类型、NULL、性能，一个都不能少
CASE表面看只是语法，但它的背后是 PostgreSQL 强大的类型系统和查询优化器。忽略这些细节，轻则结果出错，重则拖垮整个数据库。下面这些点，都是我在给金融、电商客户做 SQL 审计时，高频发现的“隐形炸弹”。
3.1 类型统一：不是“看起来一样”，而是“内存布局一致”
CASE要求所有THEN和ELSE分支返回完全相同的数据类型。这里的“相同”不是指“都能转成字符串”，而是指 PostgreSQL 内部的类型 OID 必须一致。很多人栽在TEXT和VARCHAR的区别上：
-- ❌ 报错：text 和 character varying 被视为不同类型（尽管日常使用几乎无差别） CASE WHEN status = 'active' THEN 'Active User'::TEXT WHEN status = 'inactive' THEN 'Inactive User'::VARCHAR(20) ELSE 0 -- integer! 这里更糟 END -- ✅ 正确：全部显式 cast 到同一类型，推荐 TEXT（无长度限制，兼容性最好） CASE WHEN status = 'active' THEN 'Active User'::TEXT WHEN status = 'inactive' THEN 'Inactive User'::TEXT ELSE 'Unknown Status'::TEXT END更隐蔽的问题出现在数字类型上。NUMERIC(10,2)和REAL在计算中可能产生精度丢失：
-- ❌ 危险：混合 numeric 和 float，可能导致小数点后位数异常 CASE WHEN amount < 100 THEN 99.99::NUMERIC(10,2) -- 精确到分 WHEN amount >= 100 THEN 100.0::REAL -- 浮点，精度不可控 ELSE 0.0 END -- ✅ 正确：全部统一为 NUMERIC，确保财务计算零误差 CASE WHEN amount < 100 THEN 99.99::NUMERIC(10,2) WHEN amount >= 100 THEN 100.00::NUMERIC(10,2) ELSE 0.00::NUMERIC(10,2) END我的实操心得是：永远显式CAST，绝不依赖隐式转换。在CASE开头就决定好目标类型，然后所有分支都::TARGET_TYPE。这样不仅避免报错，还能让执行计划更稳定。我在一个支付对账系统里，就是因为没统一CASE的返回类型，导致某天凌晨批量对账任务因类型冲突失败，损失了数小时的黄金修复窗口。
3.2 NULL 的陷阱：它不是“空”，而是“未知”，处理方式天壤之别
NULL是 SQL 里最危险的“幽灵”。CASE对NULL的处理，和你在WHERE或JOIN里遇到的完全不同，必须单独记忆。
在简单 CASE 中：
CASE column_name WHEN 'A' THEN ...。如果column_name是NULL，那么NULL = 'A'的结果是UNKNOWN（不是FALSE！），所以所有WHEN分支都不匹配，直接跳到ELSE。这是安全的。在搜索 CASE 中：
WHEN column_name = 'A' THEN ...。同样，NULL = 'A'是UNKNOWN，而CASE只认TRUE/FALSE，UNKNOWN被当作FALSE，所以也会跳到下一个WHEN。但问题来了：如果你没写ELSE，或者ELSE也没处理NULL，结果就是NULL。
最经典的坑是日期比较：
-- ❌ 错误：indep_year 是 NULL 时，indep_year < 1900 返回 UNKNOWN -> FALSE，被忽略 CASE WHEN indep_year < 1900 THEN 'Old' WHEN indep_year >= 1900 THEN 'New' -- 缺少 indep_year IS NULL 的分支！ END -- ✅ 正确：必须显式处理 NULL，且放在最后（因为 NULL < 1900 是 UNKNOWN，不是 TRUE） CASE WHEN indep_year < 1900 THEN 'Old' WHEN indep_year >= 1900 THEN 'New' WHEN indep_year IS NULL THEN 'Year Unknown' ELSE 'Invalid Year' -- 防御性兜底 END注意：
WHEN indep_year IS NULL必须写在WHEN indep_year >= 1900之后。因为CASE是顺序匹配，如果NULL分支写在前面，它会捕获所有indep_year为NULL的行，后面的条件就永远不会执行。但逻辑上，“年份未知”应该是一个独立的业务状态，和“新/旧”并列，所以位置要合理。
3.3 性能优化：让 CASE 成为加速器，而不是拖油瓶
CASE本身不慢，慢的是你让它干了不该干的活。以下是经过生产环境验证的三条黄金法则：
法则一：WHERE 优先于 CASE
永远先用WHERE过滤掉大部分无关数据，再用CASE做精细分类。CASE是在WHERE之后执行的，它处理的是已经筛选过的行集。
-- ❌ 慢：CASE 在 WHERE 之前，对全表 206 行都计算 indep_era SELECT name, CASE WHEN indep_year < 1900 THEN 'Pre-1900' WHEN indep_year BETWEEN 1900 AND 1930 THEN 'Early 20th' ELSE 'Other' END AS indep_era FROM countries WHERE continent = 'Europe'; -- 这个过滤在 CASE 之后才发生 -- ✅ 快：WHERE 先过滤，CASE 只处理欧洲国家（假设 52 个） SELECT name, CASE WHEN indep_year < 1900 THEN 'Pre-1900' WHEN indep_year BETWEEN 1900 AND 1930 THEN 'Early 20th' ELSE 'Other' END AS indep_era FROM countries WHERE continent = 'Europe' -- 过滤提前，CASE 工作量减少 75% AND indep_year IS NOT NULL; -- 连带过滤掉 NULL，避免 CASE 里额外判断法则二：索引友好型条件
确保WHEN条件能利用现有索引。避免在列上使用函数（如UPPER(name)）、数学运算（如indep_year + 10 > 1950）或类型转换（如indep_year::TEXT = '1947'）。这些都会让索引失效。
-- ❌ 索引失效：UPPER() 函数包装 WHEN UPPER(name) = 'CHINA' THEN ... -- ✅ 索引友好：用 ILIKE（大小写不敏感索引）或函数索引 WHEN name ILIKE 'china' THEN ... -- 或者提前建函数索引：CREATE INDEX idx_countries_name_lower ON countries (LOWER(name));法则三：聚合中的 CASE：用 SUM(CASE) 替代 FILTER（PostgreSQL 9.4+）
虽然FILTER子句更现代、更语义化，但在高并发 OLAP 场景下，SUM(CASE WHEN ... THEN 1 ELSE 0 END)的执行计划往往更稳定、更易预测，且兼容性更好（支持所有 PostgreSQL 版本）。
-- ✅ 推荐：稳定、高效、兼容 SELECT SUM(CASE WHEN grade = 'A' THEN 1 ELSE 0 END) AS count_a, SUM(CASE WHEN grade = 'B' THEN 1 ELSE 0 END) AS count_b, AVG(CASE WHEN grade IN ('A','B') THEN score END) AS avg_ab_score FROM student_grades; -- ⚠️ 谨慎：FILTER 语义清晰，但某些复杂场景下优化器可能生成次优计划 SELECT COUNT(*) FILTER (WHERE grade = 'A') AS count_a, COUNT(*) FILTER (WHERE grade = 'B') AS count_b FROM student_grades;4. 实操过程与核心环节实现：从建表、填充到复杂报表，一步一图解
光讲理论不够，我们来做一个完整的、可立即运行的实战项目。目标：构建一个“全球国家发展水平分析仪表板”，基于countries表，输出包含人口、面积、独立年份、区域等多个维度的综合标签。这个例子会覆盖你工作中 90% 的CASE使用场景。
4.1 环境准备与数据验证：别跳过这一步，它省下你 80% 的调试时间
首先，确认你的 PostgreSQL 环境。我用的是 PostgreSQL 15.4，但以下所有代码在 10+ 版本均兼容。打开psql或pgAdmin，执行：
-- 1. 确认 countries 表存在且结构正确 \d countries -- 你应该看到类似输出： -- Column | Type | Collation | Nullable | Default -- ----------------+-----------------------+-----------+----------+--------- -- name | character varying(100) | | | -- continent | character varying(30) | | | -- region | character varying(50) | | | -- indep_year | numeric | | | -- population | numeric | | | -- area | numeric | | | -- ...（其他列） -- 2. 快速验证关键字段的 NULL 比例（重要！） SELECT COUNT(*) AS total, COUNT(indep_year) AS indep_year_not_null, COUNT(population) AS population_not_null, COUNT(area) AS area_not_null, ROUND(100.0 * COUNT(indep_year) / COUNT(*), 2) AS indep_year_pct FROM countries; -- 我的测试库返回：total=206, indep_year_not_null=196, indep_year_pct=95.15 -- 这意味着约 5% 的国家独立年份缺失，我们的 CASE 必须处理它。提示：永远先跑这个
COUNT查询。它能立刻告诉你数据质量，避免你写了一大堆CASE，结果发现indep_year90% 是NULL，所有基于它的逻辑都成了空中楼阁。
4.2 构建核心发展水平标签：一个 CASE 解决多维分类
我们的目标是为每个国家打上一个综合标签，例如'Developed - High Income'、'Developing - Large Population'。这需要融合population、area、indep_year、continent四个字段。关键在于逻辑分层：先按经济水平粗分，再按人口/面积细分，最后用continent做兜底校正。
-- 🚀 最终版：生产环境可用的综合发展标签 SELECT name, continent, region, indep_year, population, area, -- 主标签：发展水平 + 收入层级 CASE -- 第一层：基于世界银行标准（简化版），用 population 和 area 估算 WHEN population > 50000000 AND area > 1000000 THEN 'Large & Vast' WHEN population > 50000000 AND area <= 1000000 THEN 'Populous' WHEN population <= 50000000 AND area > 1000000 THEN 'Vast but Sparse' WHEN population <= 50000000 AND area <= 1000000 THEN 'Compact' -- 第二层：用独立年份修正（历史维度） WHEN indep_year < 1800 THEN 'Historic Sovereign' WHEN indep_year BETWEEN 1800 AND 1945 THEN 'Modern Nation-State' WHEN indep_year > 1945 THEN 'Post-Colonial' -- 第三层：用大陆兜底（地理维度） WHEN continent = 'Europe' THEN 'European' WHEN continent = 'North America' THEN 'North American' ELSE 'Other Continent' END AS development_profile, -- 辅助标签：独立年份时代 CASE WHEN indep_year IS NULL THEN 'Year Unknown' WHEN indep_year < 1800 THEN 'Pre-Industrial Era' WHEN indep_year BETWEEN 1800 AND 1918 THEN 'Imperial Era' WHEN indep_year BETWEEN 1919 AND 1945 THEN 'Interwar & WWII Era' WHEN indep_year BETWEEN 1946 AND 1991 THEN 'Cold War Era' WHEN indep_year > 1991 THEN 'Post-Cold War Era' ELSE 'Invalid Year' END AS independence_era, -- 辅助标签：人口规模（用于后续聚合） CASE WHEN population < 1000000 THEN 'Small (<1M)' WHEN population BETWEEN 1000000 AND 10000000 THEN 'Medium (1M-10M)' WHEN population BETWEEN 10000000 AND 100000000 THEN 'Large (10M-100M)' WHEN population > 100000000 THEN 'Giant (>100M)' ELSE 'Population Unknown' END AS population_tier FROM countries ORDER BY development_profile, name;这段代码的精妙之处在于分层逻辑。第一层WHEN处理的是最核心的“体量”特征（人口+面积），这是国家发展的物理基础；第二层用indep_year加入历史纵深；第三层用continent作为地理锚点。由于CASE是顺序匹配，WHEN条件越具体、越可能命中，就应该越靠前。我把population > 50M AND area > 1M放在最前面，因为这是最稀有的组合（全球仅中俄加美印等寥寥数国），能快速分流。
4.3 聚合报表：用 CASE 驱动动态指标计算
现在，我们把单行标签升级为全局洞察。目标：统计各“发展水平标签”下的国家数量、平均人口、最大面积。这需要用到GROUP BY和CASE的深度结合。
-- 📊 动态聚合报表：按发展水平分析 SELECT -- 用同一个 CASE 作为 GROUP BY 的依据，保证分组逻辑一致 CASE WHEN population > 50000000 AND area > 1000000 THEN 'Large & Vast' WHEN population > 50000000 AND area <= 1000000 THEN 'Populous' WHEN population <= 50000000 AND area > 1000000 THEN 'Vast but Sparse' WHEN population <= 50000000 AND area <= 1000000 THEN 'Compact' WHEN indep_year < 1800 THEN 'Historic Sovereign' WHEN indep_year BETWEEN 1800 AND 1945 THEN 'Modern Nation-State' WHEN indep_year > 1945 THEN 'Post-Colonial' WHEN continent = 'Europe' THEN 'European' ELSE 'Other Continent' END AS profile_group, COUNT(*) AS country_count, ROUND(AVG(population)::NUMERIC, 0) AS avg_population, ROUND(AVG(area)::NUMERIC, 0) AS avg_area_km2, MAX(area) AS max_area_km2, STRING_AGG(name, ', ' ORDER BY name) AS countries_list -- 列出所有国家名，便于验证 FROM countries -- 关键：WHERE 过滤掉 NULL，提升聚合效率 WHERE population IS NOT NULL AND area IS NOT NULL AND indep_year IS NOT NULL GROUP BY profile_group ORDER BY country_count DESC;这个查询的关键点是：GROUP BY的表达式必须和SELECT中的CASE完全一致。如果你在SELECT里写了一个CASE，在GROUP BY里却试图用别名profile_group，PostgreSQL 会报错。必须复制粘贴整个CASE块。这是新手最容易犯的错误。
另外，STRING_AGG是一个神技。它能把每个分组下的所有国家名拼成一个字符串，方便你一眼看出分组是否合理。比如，如果Large & Vast组里出现了“Monaco”（摩纳哥，面积仅 2km²），你就立刻知道area > 1000000这个条件写错了。
4.4 高级技巧：CASE 在 UPDATE 和 INSERT 中的实战应用
CASE不只属于SELECT。在数据清洗和 ETL 中，它常用于UPDATE和INSERT ... SELECT，实现“一行 SQL 完成多条件更新”。
-- 🛠️ 场景：为 countries 表添加一个新列 'development_score'，基于规则计算 ALTER TABLE countries ADD COLUMN development_score NUMERIC(5,2); -- 用 CASE 驱动 UPDATE：根据不同条件设置不同分数 UPDATE countries SET development_score = CASE -- 高分：人口多、面积大、独立早 WHEN population > 100000000 AND area > 5000000 AND indep_year < 1900 THEN 95.0 -- 中高分：人口多或面积大，独立较早 WHEN (population > 50000000 OR area > 2000000) AND indep_year < 1950 THEN 75.0 -- 中分：人口或面积达标，独立较晚 WHEN (population > 10000000 OR area > 500000) AND indep_year > 1950 THEN 55.0 -- 低分：其他情况，但排除 NULL WHEN population IS NOT NULL AND area IS NOT NULL AND indep_year IS NOT NULL THEN 35.0 -- 未知：任何字段为 NULL ELSE NULL END; -- 验证更新结果 SELECT name, population, area, indep_year, development_score FROM countries WHERE development_score IS NOT NULL ORDER BY development_score DESC LIMIT 10;这个UPDATE的威力在于：它用一条命令，就完成了传统上需要多个UPDATE ... WHERE ...语句才能完成的工作。而且，逻辑集中，修改一处，全局生效，避免了多条语句间条件遗漏或冲突的风险。
5. 常见问题与排查技巧实录：那些让你抓狂的 CASE 错误，我替你试过了
在真实世界里，CASE的问题从来不是语法报错那么简单。更多时候，它表现为“结果不对”、“性能骤降”、“偶尔出错”。下面是我整理的“高频故障速查表”，每一条都来自血泪教训。
5.1 典型问题与解决方案速查表
| 问题现象 | 根本原因 | 快速诊断方法 | 解决方案 |
|---|---|---|---|
| 查询返回大量 NULL，而非预期值 | CASE所有WHEN条件都未匹配，且未定义ELSE | 在SELECT中临时添加ELSE 'DEBUG_UNMATCHED'，看哪些行落入此分支 | 永远写ELSE，即使是ELSE NULL也要显式写出，明确表达意图 |
| 聚合结果为 0 或 NULL，但数据明明存在 | CASE分支中混用了不同数据类型（如THEN 1和ELSE 'N/A'），导致隐式转换失败 | 执行EXPLAIN (VERBOSE, ANALYZE)，查看执行计划中CASE的输出类型 | 显式CAST所有分支：THEN 1::INTEGER,ELSE 0::INTEGER |
CASE在WHERE中不走索引，查询极慢 | WHEN条件中对列使用了函数（UPPER(col)）或表达式（col + 10） | EXPLAIN输出中查看Seq Scan（顺序扫描）而非Index Scan | 重构条件，使用索引友好形式（如col LIKE 'A%'），或为函数创建函数索引 |
CASE结果在ORDER BY中排序异常（如 '10' 排在 '2' 前面） | CASE返回的是TEXT类型，字符串排序而非数值排序 | SELECT中添加CASE ... END AS label, pg_typeof(CASE ... END)查看实际类型 | 对数值型结果，确保CASE返回NUMERIC或INTEGER，而非字符串 |
CASE与UNION ALL结合时，列类型不匹配报错 | 不同SELECT子句中CASE的返回类型不一致（如一个返回TEXT，另一个返回VARCHAR） | 分别执行两个SELECT，用\d或pg_typeof()检查各列类型 | 在UNION ALL的每个子句中，对CASE结果统一CAST到同一类型，如::TEXT |
5.2 实战排错：一个让我熬通宵的真实案例
问题：一个报表查询，平时 200ms，某天突然变成 15 秒，且只影响特定用户。EXPLAIN ANALYZE显示Seq Scan on countries，而平时是Index Scan。
排查过程：
- 检查
WHERE条件：WHERE region = 'Europe' AND CASE WHEN indep_year < 1900 THEN 'OLD' ELSE 'NEW' END = 'OLD'—— 啊！CASE被错误地放进了WHERE！ CASE在WHERE中，意味着 PostgreSQL 必须为每一行都计算indep_year < 1900，无法利用indep_year上的索引。- 修复：把逻辑移到
WHERE外部，WHERE region = 'Europe' AND indep_year < 1900，CASE只留在SELECT里做展示。
教训：CASE是计算密集型操作，永远把它放在数据流的下游（SELECT、ORDER BY），而不是上游（WHERE、JOIN条件）。上游的过滤工作，交给原生的布尔表达式去做。
5.3 独家避坑技巧：5 个你绝不会在文档里看到的经验
“CASE 嵌套”是毒药，用“WHEN 链”替代
不要写CASE WHEN A THEN CASE WHEN B THEN ... END ELSE ... END。这会让逻辑树变得无比复杂，且性能差。改为平铺的WHEN A AND B THEN ... WHEN A AND NOT B THEN ...。我见过一个嵌套 4 层的CASE，重构后代码行数减半，性能提升 3 倍。用
COALESCE配合CASE处理默认值
当CASE的ELSE需要一个“业务默认值”，但又不想硬编码时，用COALESCE：COALESCE(CASE ... END, 'Default Value')。COALESCE会跳过NULL，返回第一个非NULL值，比在CASE里写ELSE 'Default'更灵活。CASE里的子查询？三思而后行WHEN (SELECT COUNT(*) FROM logs WHERE country_id = c.id) > 100 THEN ...这种写法在小表上没问题，但在大表上是灾难。每次WHEN都会执行一次子查询。改用LEFT JOIN预先聚合。测试
CASE逻辑，用VALUES构造最小数据集
不要总在真实大表上调试。用SELECT * FROM (VALUES ('CN', 1949), ('US', 1776), (NULL, NULL)) AS t(code, year)构造几行测试数据，快速验证CASE逻辑是否正确。版本兼容性：
CASE在所有 PostgreSQL 版本中行为一致
这是少数几个可以放心使用的、跨版本稳定的高级特性。不必担心从 9.6
