子查询在分区表where条件中必须返回单值，否则报错；mysql不支持子查询参与分区裁剪，需用预处理语句或应用层计算边界值；pg需通过系统表动态识别热分区并显式union all，禁用拼接表名防注入。
子查询在分区表 WHERE 条件中必须返回单值，否则报错 Subquery returns more than 1 row
MySQL / PostgreSQL 中对分区表做冷热分离时，常想用子查询动态算出「热数据截止时间」，比如「只查最近 90 天的分区」。但直接写 WHERE dt >= (SELECT DATE_SUB(CURDATE(), INTERVAL 90 DAY)) 看似合理，一旦子查询因 GROUP BY、JOIN 或 LIMIT 缺失导致多行返回，就会炸。这不是分区专属问题，但分区表常配合时间字段做 LIST/RANGE 分区，更容易触发该错误。
实操建议：
- 子查询必须加
LIMIT 1（MySQL）或用聚合函数兜底，例如(SELECT MAX(dt) FROM meta_hot_window) - 避免在
WHERE中嵌套含IN或EXISTS的子查询——它们天然多行语义，不适合用于单值比较 - PostgreSQL 用户注意：
ANY和ALL可显式支持多值比较，但无法触发分区裁剪（Partition Pruning），实际性能可能更差
MySQL 5.7+ 的 RANGE COLUMNS 分区 + 子查询无法自动裁剪，需手动展开
MySQL 对子查询结果不参与分区裁剪优化。哪怕你写了 WHERE create_time >= (SELECT '2024-01-01')，优化器仍可能扫描所有 create_time 分区，而不是只读 2024 年及之后的分区。这是硬限制，和是否加索引无关。
实操建议：
- 用预处理语句（
PREPARE+EXECUTE）先查出边界值，再拼成静态 SQL 执行，例如：SET @hot_start = (SELECT DATE_SUB(CURDATE(), INTERVAL 90 DAY)); PREPARE stmt FROM 'SELECT * FROM orders WHERE create_time >= ?'; EXECUTE stmt USING @hot_start;
- 在应用层（如 Python/Java）计算好日期字符串，传入参数化查询，绕过 SQL 层解析子查询
- 确认分区键类型与子查询返回类型严格一致：比如分区键是
DATE，子查询不能返回DATETIME字符串，否则隐式转换会禁用裁剪
PostgreSQL 中用 pg_partition_root() + 子查询识别冷热分区表名再 JOIN
PG 没有原生「按时间自动路由分区」语法，冷热分离得靠继承表或 declarative partitioning。想动态过滤「仅查热分区」，不能靠 WHERE 子查询推导分区名，得先查系统表拿到目标分区 OID，再用 ONLY 限定或动态生成 SQL。
实操建议：
- 用
pg_inherits关联pg_class查出所有子分区，结合pg_partition_rule（旧版）或pg_partitioned_table（12+）提取分区边界 - 构造动态 SQL 时，优先用
UNION ALL显式列出热分区（如orders_2024q2,orders_2024q3），比SELECT * FROM ONLY orders更可控 - 别依赖
pg_partition_root('orders_2024q2')反查主表——它只返回父表 OID，不帮你判断冷热；真正要的是pg_get_expr(relpartbound, c.oid)解析出FOR VALUES FROM ('2024-04-01') TO ('2024-07-01')
归档后冷分区表名带时间戳，子查询拼接表名会触发 SQL 注入风险
有些团队把冷数据迁到 orders_archive_202312 这类命名规则的独立表，再用子查询从 information_schema.tables 找出匹配表名，最后 CONCAT('SELECT * FROM ', table_name) 拼 SQL。这在任何语言里都是高危操作。
实操建议：
- 禁止用子查询结果直接拼表名。改用白名单校验：先查出候选表名列表，再用正则
^orders_archive_\d{6}$过滤，最后用format()（PG）或CONCAT()+ 参数占位安全拼接 - MySQL 用户可用
sys.schema_table_statistics替代手工查information_schema，响应更快且权限更细 - 如果冷数据已转对象存储（如 S3 + Athena），就别硬在 SQL 层搞动态表名，改用外部表 +
WHERE $partition_date >= '2024-01-01'下推过滤
真正难的不是写出能跑的子查询，而是让数据库执行计划里出现 rows_examined 明显下降——这意味着分区裁剪生效了。每次加完子查询逻辑，务必用 EXPLAIN PARTITIONS（MySQL）或 EXPLAIN (ANALYZE, VERBOSE)（PG）盯一眼实际访问了哪些分区。
