MyISAM表打开失败或LOAD DATA报错“Too many open files”的根本原因是每个MyISAM表占用3个文件句柄（.frm/.MYD/.MYI），超出操作系统ulimit -n限制（默认1024）；需同步调高系统limits.conf、MySQL的open_files_limit和table_open_cache参数，并考虑迁移到InnoDB以彻底规避该架构瓶颈。
MyISAM表打开失败或LOAD DATA报错“Too many open files”
根本原因是MySQL为每个MyISAM表分配一个.frm + .MYD + .MYI文件句柄，而操作系统默认限制（如Linux的ulimit -n）通常只有1024。当活跃MyISAM表数超限，就会出现ERROR 23 (HY000): Out of resources when opening file或Can't open file: 'xxx.MYI'。
- 先确认当前限制：
ulimit -n（shell）和SHOW VARIABLES LIKE 'open_files_limit';（MySQL内） - 操作系统级调高：在
/etc/security/limits.conf中加两行：mysql soft nofile 65536、mysql hard nofile 65536，再重启mysqld服务 - MySQL配置中显式设大：
open_files_limit = 65536（写入my.cnf的[mysqld]段），否则MySQL可能按系统默认值截断 - 注意：MyISAM表越多，实际占用句柄越多——即使没被查询，只要被
FLUSH TABLES或自动缓存机制加载过，就计入Opened_tables计数
MyISAM表缓存溢出导致频繁重开文件
MyISAM依赖table_open_cache缓存已打开的表结构和索引文件句柄。若该值太小，每次SQL访问新表都要关闭旧表、重开新表，触发大量文件系统I/O和锁竞争，表现为Opened_tables持续上升、Handler_read_rnd_next飙升。
- 检查命中率：
SHOW STATUS LIKE 'Open%';，计算(Open_tables / Opened_tables)，低于0.9说明缓存严重不足 - 安全设值公式：
table_open_cache = max(活跃MyISAM表数 × 1.5, 4096)；例如有2000个MyISAM表，建议至少设为3000 - 不要盲目设到65536——该值会按
table_open_cache_instances分片，每实例缓存大小=总值/实例数；若实例数太少（如默认1），单实例哈希桶冲突加剧反而降低效率 - 搭配调
table_open_cache_instances = 16（MySQL 5.7+），避免单点瓶颈
为什么InnoDB不受此问题影响？
InnoDB不依赖独立文件句柄管理每个表：它的.ibd文件由存储引擎统一通过fil_system子系统管理，表元数据缓存在内存LRU链表中，打开/关闭开销极低。哪怕有上万个InnoDB表，open_files_limit也极少成为瓶颈。
- 这不是“InnoDB更先进”的抽象结论，而是具体实现差异：MyISAM每个表强制绑定3个OS文件描述符，InnoDB用内存映射+异步I/O池复用底层句柄
- 所以当你看到
ulimit和table_open_cache反复调优仍收效甚微，本质是架构限制——此时迁移至InnoDB比硬扛参数更可靠 - 迁移后记得关掉
skip-external-locking（MyISAM常用），InnoDB不需要它，开着反而干扰事务日志刷盘
别忽略tmpdir和临时表的句柄消耗
MyISAM执行ORDER BY、GROUP BY或大结果集排序时，会在tmpdir下创建临时.MYD/.MYI文件。这些临时表同样吃句柄，且不计入table_open_cache统计，容易漏查。
- 监控
Created_tmp_disk_tables状态变量，持续增长说明频繁落盘，间接推高句柄压力 - 把
tmpdir指向高速SSD路径（如tmpdir = /ssd/tmp），并确保该目录属主为mysql用户 - 调大
sort_buffer_size和read_rnd_buffer_size，减少落盘频率——但注意这两个是**每连接**分配，设太高会挤爆内存 - 终极手段：改写SQL避免隐式排序，或加覆盖索引让
EXPLAIN显示Using index而非Using filesort
