升级MySQL时需注意临时表仅限会话生命周期，重启后自动消失；应检查长事务、避免复杂操作、合理配置内存参数，并确保升级前完成DDL任务，防止因会话中断导致查询失败，应用重连后可重建临时表，不会造成数据丢失。
MySQL升级时，临时表的处理需要特别注意，因为它们的行为和生命周期与普通表不同。临时表只在当前会话中存在，关闭连接后自动销毁，但升级过程中的服务重启或工具操作可能影响正在运行的会话，进而引发问题。
理解临时表的特性
MySQL中的临时表通过 CREATE TEMPORARY TABLE 创建，仅对当前连接可见，同名的临时表会遮蔽非临时表。它们不会写入数据字典，也不会被复制到从库（除非语句执行时启用了binlog且设置了相关参数）。升级前需了解以下几点：
- 临时表数据保存在内存或磁盘（根据大小和配置），不持久化。
- 服务重启后所有临时表自动消失，不会残留。
- 若使用的是旧版本（如5.7及之前），某些存储引擎（如MyISAM）用于内部临时表时可能产生磁盘文件。
升级前的检查与准备
为避免升级过程中因临时表导致连接中断或查询失败，建议采取以下措施：
- 检查是否有长时间运行的会话使用了临时表，可通过 SHOW PROCESSLIST 查看活跃连接。
- 通知应用方在升级窗口期间避免执行涉及大量临时表的操作，如复杂联接、排序或GROUP BY。
- 确认是否启用了 tmp_table_size 和 max_heap_table_size 的合理值，防止临时表频繁落盘影响性能。
升级过程中的注意事项
执行MySQL原地升级（in-place upgrade）或逻辑升级时，临时表本身无需迁移，但要注意：
- 停机升级会导致所有会话断开，临时表随之丢失，应用重连后需自行重建（如果业务逻辑支持）。
- 使用 mysql_upgrade 工具（8.0以前）不会处理临时表，它主要更新系统表和权限结构。
- 若采用逻辑导出导入方式（如mysqldump），临时表不会被导出，也不应包含在备份中。
特殊情况：内部临时表与在线DDL
某些SQL操作（如ALTER TABLE、UNION、子查询等）会生成内部临时表。升级期间尽量避免执行这类语句，尤其是在主库负载较高时。对于使用 ALgoRITHM=COPY 的DDL操作，可能会创建大量临时结构，增加升级风险。
建议在升级前完成所有正在进行的DDL任务，并确保没有大事务持有临时资源。
基本上就这些。只要保证升级时没有关键业务依赖长期存在的临时表，服务重启后由应用层重新生成即可，不会造成数据丢失或结构异常。