存储过程性能瓶颈取决于底层表引擎而非过程本身；innodb适合高并发但写入开销大，myisam读快但锁粒度粗；需查information_schema确认引擎，alter table切换时注意锁、索引长度及语法兼容性。
存储过程本身不依赖存储引擎，但底层表引擎决定性能瓶颈
存储过程的执行效率不取决于它自己用什么引擎——它压根没引擎。真正拖慢速度的是过程里读写的那些表用的是 InnoDB 还是 MyISAM。很多人一看到“存储过程慢”，就去调优过程逻辑，结果发现改完没用，问题其实在表结构上。
常见错误现象：SELECT 在存储过程中跑得比单独执行慢几倍；INSERT ... SELECT 类批量操作卡住；并发调用时锁等待严重。
-
InnoDB支持行级锁和事务，适合高并发、频繁更新的场景，但写入开销大、MVCC 带来额外内存和 CPU 消耗 -
MyISAM只有表级锁，读快写慢，崩溃后恢复不可靠，但全表扫描类查询（比如报表汇总）在小数据量下可能更快 - 如果存储过程里大量用
INSERT INTO ... SELECT或临时表，InnoDB的 redo log 和 buffer pool 压力会明显高于MyISAM的简单文件追加
如何快速判断当前表用的是哪个引擎
别猜，直接查 information_schema。尤其当别人交接的库、或 ORM 自动生成的表，引擎可能和预期不一致。
执行这条语句就能看到所有表及其引擎：
SELECT table_name, engine FROM information_schema.tables WHERE table_schema = 'your_db_name';
使用场景：上线前检查、排查慢过程、迁移前评估。
- 注意
table_schema必须填对，否则查不到；可以用DATABASE()替代字面量 -
ENGINE列值是大小写敏感的字符串，常见为InnoDB或MyISAM，不是innodb - 视图（
VIEW）没有引擎，查出来是NULL，别误判
ALTER TABLE 切换引擎时必须注意的三件事
想把 MyISAM 表换成 InnoDB 提升并发？或者反过来降负载？切换动作本身不难，但容易引发线上问题。
典型错误现象：ALTER TABLE t ENGINE=InnoDB 执行十几分钟卡住，业务写入失败；切换后索引长度超限报错 ERROR 1071 (42000): Specified key was too long。
-
InnoDB默认页大小是 16KB，且索引键长度限制比MyISAM更严（尤其是 utf8mb4 + 长 varchar），建表时没显式设ROW_FORMAT=DYNAMIC容易触发报错 - 整个表会被锁死（即使用了
ALGORITHM=INPLACE，某些版本/参数下仍会升级为 copy 算法），务必避开高峰 -
MyISAM切到InnoDB后，原来靠INSERT DELAYED缓冲写入的逻辑会失效——这个语法在InnoDB下被忽略，甚至报错
存储过程中临时表该选哪个引擎
临时表（CREATE TEMPORARY TABLE）默认用 MyISAM，但在 InnoDB 为主的库中，这反而可能成为隐性陷阱。
原因很简单：不同引擎之间做 JOIN 或子查询时，MySQL 无法高效利用索引，优化器容易走错执行计划。
- 显式指定引擎更可控：
CREATE TEMPORARY TABLE tmp_xxx (...) ENGINE=InnoDB; - 如果临时表只读、数据量小、生命周期短，
MEMORY引擎通常比两者都快，但注意max_heap_table_size限制 -
MyISAM临时表不支持事务回滚，而InnoDB临时表在事务内创建的话，会随事务自动清理——这点常被忽略，导致调试时看到“表突然没了”
真正影响性能的，从来不是存储过程那几行 BEGIN...END，而是它背后每一张表的引擎选择、索引设计、以及你有没有在 EXPLAIN 里看见 Using temporary; Using filesort 这种提示。这些地方不动，光改过程逻辑，等于给轮船换方向盘却不修发动机。
