只有同时满足多表JOIN+多维GROUP BY+条件聚合、需事务保障、高频固定调用、中间结果复用四个条件的报表逻辑，才适合用CREATE PROCEDURE；否则易增维护成本与性能风险。
CREATE PROCEDURE 是封装报表统计逻辑的起点，但直接套用会踩坑。真正能落地的方案，得从场景、结构和性能三处下手——不是所有“复杂查询”都该塞进存储过程。
什么报表逻辑才值得放进存储过程？
只有满足以下全部条件时，CREATE PROCEDURE 才比应用层拼 SQL 更合理：
- 涉及多表
JOIN+ 多维度GROUP BY+ 条件聚合（如“各区域 TOP5 客户的月均复购率”） - 需要事务保障一致性（如报表生成同时更新
report_status表状态） - 被多个服务或定时任务高频调用（日均 ≥ 10 次），且参数模式固定（如固定按
start_date/end_date切片） - 中间结果需复用（例如先算出客户分层标签，再基于该标签做二次聚合）
单纯“带 WHERE 的 SELECT”或只查单表聚合，硬包成存储过程反而增加维护成本和锁等待风险。
IN 参数类型不匹配导致计算偏差
报表里金额、百分比、时间范围这些参数，类型声明错一丁点就会静默出错：
-
IN start_date DATE是对的；但若写成IN start_date VARCHAR(10)，MySQL 会隐式转换，可能跳过索引，或在BETWEEN中触发全表扫描 - 佣金类报表常用
DECIMAL(15,2)，但中间变量若声明为INT或FLOAT，小数部分直接截断——比如SET @avg = 99.99 / 3;在INT变量里存成33 - 传入订单号等主键字段时，务必和源表字段类型一致：
CHAR(32)表不能用VARCHAR(50)接收，否则比较时隐式转换，索引失效
聚合慢、CPU 高、锁超时？先看执行计划再动游标
报表慢，90% 不是存储过程语法问题，而是执行计划没绕过临时表和文件排序：
- 在存储过程里加
EXPLAIN FORMAT=TRADITIONAL查每条查询（注意：需在SELECT前临时开启SET profiling = 1;，或从慢日志定位） -
GROUP BY字段必须是联合索引最左前缀，且索引要覆盖所有被引用列——例如SELECT dept_id, COUNT(*), AVG(salary) FROM emp GROUP BY dept_id，索引至少是(dept_id, salary) - 避免
GROUP BY DATE(create_time)这种写法，改用生成列 + 索引，或预处理时间维度表 - 中间聚合结果超 100 行，别用
DECLARE my_tmp TABLE（MySQL 8.0.19+ 支持但无索引），改用CREATE TEMPORARY TABLE tmp_agg (...)并手动建主键/索引 - 游标遍历是最后手段——只有滚动累计、状态机跳转这类真依赖前一行结果的逻辑才用，且必须配
DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE;
Java 调用时取不到结果集？顺序和注册方式错了
JDBC 调用存储过程返回报表数据，最容易卡在结果集获取上：
-
CallableStatement.execute()返回boolean：true 表示第一个结果是ResultSet，false 表示是更新行数或输出参数 - 必须按定义顺序处理：先取
getResultSet()（报表明细），再取getBigDecimal(3)（OUT total_sales）——顺序错就拿不到数据 -
registerOutParameter()必须在execute()前完成，且类型要严格对应：金额用Types.DECIMAL，日期用Types.DATE，别混用Types.DOUBLE - 如果存储过程里有多个
SELECT，JDBC 默认只暴露第一个；后续结果需反复调用getMoreResults()切换
真正麻烦的不是写出来，而是当报表字段动态变化、聚合维度嵌套三层、还要兼容历史数据补录时——这时候连 EXPLAIN 都未必能一眼看出瓶颈在哪，得靠临时表 + 分步验证才能稳住。
