用存储过程封装多表join逻辑并参数化输入，可避免应用层重复拼sql、提升复用性与一致性，适用于报表及后台管理等固定查询场景。
直接说结论：用存储过程封装多表 JOIN 逻辑 + 参数化输入，能避免每次在应用层拼 SQL、重复写相同关联结构，尤其适合报表、后台管理页这类固定查询模式的场景。
为什么不能直接在应用里拼接 JOIN 查询？
常见错误现象是：不同接口反复写几乎一样的 SELECT ... FROM student s JOIN score sc ON s.id = sc.student_id JOIN class c ON s.class = c.class_name，字段微调就复制粘贴改几处，漏加索引提示、错用 LEFT/INNER、忘记加 WHERE s.status = 1 这类业务过滤条件——结果就是慢查频发、数据不一致、排查时分不清哪段逻辑在哪个服务里。
根本原因在于：关联结构本身是「稳定契约」，而参数（如班级名、时间范围、状态）才是变量。把契约和变量混在一起写，就失去了复用基础。
使用场景包括：
• 后台导出学生+成绩+班级信息的 Excel
• 教务系统按学期统计各班平均分
• 审计模块需要跨三张表拉取带审核标记的完整记录
CREATE PROCEDURE 必须带 DELIMITER 吗？
必须。MySQL 默认用分号 ; 结束语句，但存储过程体内部有多个 ;（比如 SET @x = 1;、SELECT ...;），不改分隔符会导致语法错误。
实操建议：
• 固定用 DELIMITER $$ 开头，END $$ 结尾，最后再 DELIMITER ; 恢复
• 别用 // 或 @@，部分客户端（如 DBeaver 旧版）对非标准分隔符解析不稳定
• 创建失败时先检查是不是漏写了 DELIMITER $$ 或结尾没切回来
怎么传参才能让关联查询真正“活”起来？
关键不是只传 ID，而是把可变维度抽象成参数：比如班级名称、成绩区间、是否包含已删除学生。这样同一段 JOIN 逻辑，换参数就能查不同业务切片。
示例中常用组合：
• IN class_name VARCHAR(50)：指定班级，用于 WHERE c.class_name = class_name
• IN min_score DECIMAL(5,2)：成绩下限，用于 AND sc.score >= min_score
• IN include_deleted TINYINT DEFAULT 0：控制是否加 AND s.deleted_at IS NULL
注意点：
• 所有 WHERE 条件都要显式判断参数是否为空或默认值，避免写成 WHERE c.class_name = class_name 导致 class_name 为 NULL 时查不到数据
• 不要用字符串拼接动态列名或表名（如 CONCAT('score_', year)），那会绕过预编译，失去性能优势，也容易被注入
调用时怎么拿到结果集又不卡住后续操作？
存储过程可以返回多个结果集，但应用层 SDK（如 MySQL Connector/J、PyMySQL）默认只读第一个。如果过程里写了两个 SELECT，第二个会被忽略——这是最常被忽略的坑。
正确做法：
• 一个过程只返回一个结果集，用明确字段命名，比如 SELECT s.name, sc.score, c.teacher AS class_teacher
• 需要统计值（如总人数、平均分）时，用 OUT 参数返回，而不是额外 SELECT
• 真要多结果集，得在应用代码里显式调用 nextset()（Python）或 getMoreResults()（Java），但维护成本高，不推荐
性能影响：多个 SELECT 会让 MySQL 无法复用执行计划，每个结果集都重新走优化器，反而比单次查询慢。
复杂点在于：关联字段类型不一致（比如 student.class 是 VARCHAR 而 class.class_name 也是 VARCHAR，但字符集不同）会导致隐式转换，索引失效；这个细节在创建过程时不报错，但一跑数据就慢，必须用 EXPLAIN 对着过程里的 SELECT 单独验证。
