临时表拖慢执行的主因是每次调用重建、缺少索引及隐式类型转换；优化需显式指定engine=memory、及时建索引、避免隐式转换，并用profiling定位瓶颈。
存储过程里建临时表为什么拖慢执行
临时表本身不慢，慢在每次调用都重建 + 缺少索引 + 隐式类型转换。MySQL 的 CREATE TEMPORARY TABLE 是会话级的，但如果你在循环或嵌套逻辑里反复 DROP 再 CREATE，I/O 和解析开销就上来了。
- 临时表默认引擎是
MEMORY，但一旦数据超tmp_table_size或含TEXT/BLOB字段，自动降级为MyISAM（磁盘表），性能断崖下跌 - 没显式加索引？
INSERT快，后面JOIN或WHERE查时全表扫描，尤其数据量过万后特别明显 - 字段类型和关联表不一致，比如临时表用
VARCHAR(50)，主表是CHAR(50)，MySQL 会隐式转换，索引失效
怎么快速定位过程内哪一步卡住
别猜，直接开 profiling——它比慢日志更贴近过程内部真实耗时。
- 先执行
SET profiling = 1，再调用你的存储过程CALL your_proc() - 查耗时分布：
SHOW PROFILES看总耗时，SHOW PROFILE FOR QUERY N（N 是上一步查到的 Query_ID）看每个语句的Duration、Creating tmp table、Copying to tmp table等阶段 - 重点关注 “
Copying to tmp table” 和 “Sorting result” 时间占比高的那几行，大概率就是临时表操作或没走索引的ORDER BY
临时表优化的三个实操动作
不是不能用临时表，而是得控制它的“体重”和“跑法”。
- 建表时加
ENGINE=MEMORY显式声明，并确保字段不含TEXT/BLOB；如果必须存大字段，改用CREATE TEMPORARY TABLE ... SELECT一次性填充，避免后续INSERT多次触发扩容 -
INSERT完立刻建索引：ALTER TABLE temp_tbl ADD INDEX idx_col (col_name)，别等SELECT时才发现没索引 - 能用派生表（subquery）替代就不用临时表，例如
SELECT * FROM (SELECT ... ) AS t WHERE ...，MySQL 8.0+ 对这类场景做了不少物化优化
存储过程参数传入导致执行计划失效
这是最隐蔽的坑：同一个过程，传不同值，执行计划可能完全不同，而你只测了“小数据”场景。
- 过程内用
IN参数拼WHERE col = p_id没问题，但换成WHERE col IN (p_id_list)（且p_id_list是拼接字符串），就会退化成全表扫描 - 参数值分布不均时，MySQL 优化器可能基于统计信息选错索引，尤其当临时表数据量随参数变化剧烈，
EXPLAIN在过程外跑不出来真实执行路径 - 验证方法：把过程里关键查询单独拎出来，用实际参数值硬编码重跑
EXPLAIN FORMAT=TREE，对比和过程内是否一致
临时表生命周期短，但它的性能代价藏得深——建表语句看着简单，字段定义、索引时机、数据写入方式，三者差一点，响应时间就差一个数量级。
