分区表prune未生效即查询全分区扫描，主因是WHERE条件未直接、确定地约束分区键，如函数包裹、含计算、非确定性函数或参数化变量，导致优化器无法静态推导目标分区。

分区表 prune 未生效，通常意味着查询没有按预期只扫描目标分区，而是全分区扫描，导致性能下降。核心原因在于 SQL 条件无法被优化器识别为可下推到分区裁剪（partition pruning）的谓词。

WHERE 条件未使用分区键或表达式不可下推

分区裁剪依赖优化器能静态推断出哪些分区可能匹配。如果 WHERE 中的条件不直接、明确地约束分区键，prune 就会失效。

• 分区键是 date_col（类型 DATE），但写成 WHERE date_col >= '2024-01-01' AND date_col < '2024-02-01' ✅ 可裁剪
• 写成 WHERE YEAR(date_col) = 2024 AND MONTH(date_col) = 1 ❌ 函数包裹后无法下推（MySQL/Oracle/StarRocks 等多数引擎均不支持）
• 写成 WHERE date_col + INTERVAL 1 DAY > '2024-01-01' ❌ 表达式含计算，失去确定性
• 分区键是 user_id % 100 这类虚拟列？确保 WHERE 中直接等值匹配该表达式结果，而非原始 user_id

使用了非确定性函数或参数化变量

优化器需在计划生成阶段就确定分区范围。若条件中含 NOW()、RAND()、USER() 或 PREPARE 中的 ? 占位符且未绑定具体值，裁剪常失效。

AI舌诊面诊问诊医疗系统+诊疗商城系统源码

AI 舌诊面诊问诊医疗系统 + 诊疗商城系统源码是一套结合 AI 辅助诊断与商品转化的健康类程序，基于浩创云、ThinkPHP（PHP）开发，支持微信服务号与 H5 端，适合做中医舌诊面诊问答、健康建议推送以及配套诊疗商品的运营。

下载

• WHERE dt = CURDATE()：CURDATE() 是非确定性函数，多数引擎（如 MySQL 8.0.23+ 除外）不支持动态裁剪
• WHERE dt = ?：预编译时 ? 无值，优化器无法判断分区 → 执行时才知，但计划已定
• 解决办法：应用层拼接具体日期字符串；或使用存储过程传入确定值后再查

JOIN 或子查询破坏了分区过滤上下文

当分区表参与 JOIN，且驱动表返回结果不确定、或 ON 条件未覆盖分区键时，优化器可能放弃裁剪。

• LEFT JOIN 分区表，但 ON 中分区键条件写在 WHERE（变成隐式 INNER），或条件来自右表字段 → 裁剪失效
• 子查询返回多行/NULL，外层用 IN (SELECT ...) 关联分区键 → 多数引擎无法静态推导分区范围
• 建议：把分区过滤条件尽量放在最外层 WHERE；JOIN 时确保 ON 包含等值分区键，并控制驱动表小且有索引

EXPLAIN 中关键检查项

运行 EXPLAIN FORMAT=TREE（MySQL 8.0+）或 EXPLAIN PARTITIONS（旧版），重点看：

• partitions 列是否只列出几个分区（如 p202401,p202402），而非 NULL 或全部分区名
• 执行计划中是否出现 "Using where; Using filesort" 但没提分区裁剪 → 很可能没生效
• MySQL 8.0+ 的 TREE 输出里找 "partitions: [p202401,p202402]"，同时确认该行对应的是你的分区表，不是物化临时表
• 注意 filtered 值极低（如 <10%）且 rows 高 → 可能全分区扫描后靠 WHERE 过滤，而非裁剪