MyISAM性能瓶颈根源是表级锁，临时表优化完全无效；调大临时表参数反而加剧锁争用、挤占key_buffer_size；唯一可持续解法是迁移到InnoDB，并注意索引、事务、全文索引等适配。
不能靠临时表调优解决 MyISAM 性能瓶颈——临时表只是症状，MyISAM 表锁才是病根。
为什么临时表优化对 MyISAM 锁问题完全无效
MyISAM 的写操作（INSERT/UPDATE/DELETE）会触发整张表级锁，而临时表（无论显式 CREATE TEMPORARY TABLE 还是优化器隐式创建）只是查询执行过程中的中间结构，它不改变 MyISAM 本身的锁行为。即使你把 tmp_table_size 调到 2G，把所有排序都压进内存，只要主表还是 MyISAM，写请求依然排队等锁。
- 临时表本身不参与 MyISAM 的表锁竞争，它用的是独立的引擎（MEMORY/InnoDB），和业务表无关
- 你看到的“慢”，90% 来自
Locked状态在SHOW PROCESSLIST里长期存在，这不是临时表造成的 - 试图用临时表绕过 MyISAM 锁，就像给自行车装涡轮增压——引擎没换，再怎么改装也跑不快
临时表参数调大反而可能加剧 MyISAM 压力
盲目调高 tmp_table_size 和 max_heap_table_size，会让更多复杂查询在内存中完成，但这些查询往往还带着对 MyISAM 主表的读写。结果就是：单个查询更快了，但它占着 MyISAM 表锁的时间更长（因为处理逻辑变重），其他并发请求堵得更死。
-
tmp_table_size和max_heap_table_size必须设为相同值，否则取较小者生效；设得过大，可能挤占key_buffer_size内存，反而让 MyISAM 索引缓存变小 - MyISAM 不支持行缓存，
key_buffer_size是它唯一的内存加速手段；临时表吃太多内存，key_buffer_size就容易被系统 OOM Killer 干掉 -
concurrent_insert=2在真实业务中基本不生效——只要表里有 DELETE 过的空洞，它就退化为普通表锁，而线上表几乎不可能没有空洞
真正该做的：停用 MyISAM，迁移到 InnoDB
MySQL 官方早在 5.5 就将 InnoDB 设为默认引擎，8.0+ 中 MyISAM 已彻底边缘化。迁移不是“可选项”，而是唯一可持续解法。
- 迁移前必须检查：所有
UPDATE/DELETE是否命中索引，否则 InnoDB 会升级为间隙锁甚至全表锁，比 MyISAM 更卡 - 业务代码若依赖 MyISAM 的“自动提交语义”，切换后未加
COMMIT，会导致事务堆积、连接池耗尽 - 含
FULLTEXT的表要重新测试分词效果，InnoDB 全文索引的停用词和分词逻辑与 MyISAM 不同 - 上线后盯紧两个指标：
innodb_row_lock_time_avg（应 Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests（比值应
如果暂时无法迁移，至少别碰临时表参数
临时表优化对 MyISAM 锁无感，但错误配置会放大副作用。与其折腾 tmp_table_size，不如做这几件实事：
- 用
SHOW OPEN TABLES WHERE In_use > 0找出长期被锁的 MyISAM 表，优先迁移它们 - 把日志类只读表（如
access_log）设为READ ONLY，避免写锁干扰 - 批量写入改用
LOAD DATA INFILE，它对 MyISAM 是最小锁粒度（仅在最后 flush 阶段锁表） - 确认
table_open_cache足够大，避免频繁打开关闭 MyISAM .MYI 文件引发额外开销
临时表参数是给 InnoDB 查询加速用的，不是给 MyISAM 续命的止痛片。真正在意性能，就别在 MyISAM 上修修补补。
