数据库内核月报 － 2015 / 08-MySQL · 答疑解惑 · open file limits

最近在Aliyun RDS的环境上，有些用户碰到了打开文件句柄数过多的错误，查看用户实例的打开句柄个数，确实超过了系统设置的值，一旦出现了这种错误，将会带来连锁的各种错误(取决于当时正在操作什么类型的文件，以及什么操作)。下面，我们就一起来看一下MySQL在操作过程中，牵涉到文件打开和关闭的关键点，以及你一直以来可能存在的认识误区。

参数和名词

关联参数

我们先列一下几个关键的参数，不了解的可以先参考官方文档，我们假设在MySQL 5.6版本上，主要针对InnoDB表。

open_file_limits

table_open_cache

table_definition_cache

innodb_file_per_table

innodb_open_files

open_file_limits的设置的值，mysqld会通过setrlimit系统调用来初始化本进程可以使用的最大文件句柄数。

而另外的四个参数的设置，对打开的文件数产生什么影响？我们稍后分析。

关联名词

下面列出的名称，是在MySQL源代码中出现的，能帮助我们更好的理解参数的设置：

table：MySQL操作一张表时建的对象，table_open_cache参数控制缓存的对象就是table； table_share：MySQL对一张表的定义建的对象， table_definition_cache参数控制缓存的对象就是table_share； handler：引擎句柄，和table是一对一的关系，每一种引擎都实现自己的handler，这也是MySQL支持多引擎的关键； innobase_share：InnoDB引擎层对应的表定义对象； dict_table：InnoDB引擎对应的表结构定义； fil_tablespace：InnoDB引擎层对应的表空间，当设置innodb_file_per_table=ON的时候，每一个InnoDB表对应一个表空间； fil_node：表空间对应的节点，如果一个表空间对应多个文件，比如logfile，那么就tablespace和node就是一对多的关系。

对照着上面提到的参数和名称，下面来看几个场景。

3. 场景

我们把一个简单的select语句在MySQL中的操作分为三个过程，open/read/close。

open过程

当操作某张表的时候，比如select * from test;

首先初始化一个table_share对象: 如果对象在table_definition_cache中存在，就直接引用； 如果不存在，就打开test.frm，读取表结构的定义，创建table_share对象，然后就关闭了test.frm。所以，这一步只在table_definition_cache未命中的时候，才open/close frm文件，并不占用太久的句柄。
如果在table_open_cache中存在unused_table， 就直接使用； 如果不存在，就会创建table对象，这里并不牵涉到文件操作。

首先创建InnoDB handler 和Innobase_share 对象，这一步仅仅是内存对象，不牵涉文件操作。

然后load dict_table对象: 如果在dictionary cache中存在dict_table，就直接引用； 如果不存在，InnoDB会读取系统表空间(ibdata)的SYS_TABLES表，读取InnoDB记录的表结构定义，同时还会读取SYS_INDEXES, SYS_COLUMN, SYS_FOREIGN 等和表关联的定义。
注：这里会牵涉到数据字典的读取操作，但因为ibdata文件从系统启动的时候，就一直处在打开状态，并且不能关闭，所以这里也没有打开新的文件操作。
最后load test表空间，在fil_system的缓存中查找: 如果存在，就直接使用，如果不存在，会读取SYS_DATAFILES系统字典表，并打开第一个文件，这里只有一个文件test.ibd，读取segment header验证space id，验证成功，就创建了file_tablespace和fil_node对象。
注：这里会打开test.ibd文件，验证完tablespace id就会关闭。

结论

这里我们发现，在读取一张表的之前的open过程，虽然有open file的动作，但都是用于初始化定义、结构等信息。所以table_open_cache， table_definition_cache并不会对open_file_limits有什么影响。而innodb_file_per_table的设置，只是增加了open file超过limit的几率，并不会有直接的影响。

read 过程

open完成后，当select需要扫描BTree结构上的某一个leaf page，而buffer pool未命中的时候，会发起IO操作:

InnoDB会通过fil_node对象里的file handler进行IO操作，但这里每次open file的时候，会进行innodb_open_files判断。如果当前InnoDB打开的文件数超过了innodb_open_files，就会强制关闭一些文件，在fil_system全局结构中有一个LRU链表，这里保存了所有打开的用户表空间文件句柄，并且当前没有任何IO操作。系统可以安全的关闭一些文件句柄，以满足innodb_open_files的需要。

结论
对于InnoDB来说，innodb_open_files设置了一个安全的file limit，除非InnoDB发起的并发IO请求数过多，并且分散在不同的表空间上。

close过程

当语句完成后，会进行close动作：

如果当前table cache大小没有超过table_open_cache，就把table缓存到cache中； 如果table_share的ref_count，就是table引用次数减到0，说明没有table引用，并且超过了table_definition_cache，就从cache中删除； 同样，innobase_share也根据ref_count来判断是否要缓存。InnoDB层的dict_table也缓存在dictionary cache中。

结论
close的过程，并没有文件的关闭动作，而仅仅是内存对象的缓存或者销毁的动作。

总体来看这三个过程：InnoDB所有和文件相关的对象、fil_tablespace、fil_node和语句、事务等一些生命周期并没有什么关系。所以语句的并发，事务的大小等等因素都不会引起文件打开数过多。

recovery过程

recovery的过程中，因为无法判断要应用的redo，所以会load fil_space一遍，会打开所有的ibd文件一遍，进行一次读取。但同样受限innodb_open_files的控制，同时打开文件数不能超过这个值。

不过5.7已经添加了一种新的redo类型MLOG_FILE_NAME ，来优化recovery的过程。

系统启动
在系统启动的过程中，会初始化ibdata和logfile文件，这两类文件，是永久打开的，不受innodb_open_files限制，但数量有限。

从上面来看，InnoDB并不会引起这么明显的open files过多的问题，那问题究竟出现在哪里？

在MySQL实例中还存在其他文件，比如用户连接创建的socket、binlog 文件、relay log文件、slow log等log文件。socket由max_connections来控制，log文件的打开数量有限。所以问题回到了MyISAM表上面，对于用户创建的MyISAM分区表，open的过程中，会把MYD文件全部打开，当分区过多的时候，open files数量就急剧上升，导致超过limit值。

flush table会关闭打开的文件吗？

flush table操作，会把table cache中未使用的table close掉，前面我们看到close的操作，并不会产生文件关闭操作。不过MyISAM实现的handler的close函数，会把打开的文件句柄给关闭掉，所以flush table能够缓解open files过多的问题，但仅限于MyISAM，而InnoDB的文件打开/关闭逻辑并不受影响。

所以，对于用户实例的open file limit的设置问题，需要计算好连接数、系统文件、表文件等文件，另外建议使用InnoDB表来避免open files 暴涨的问题。

【七天深入MySQL实战营】答疑汇总Day7 MySQL分支 - AliSQL 的性能优化实战 【最后一课】【MySQL分支 - AliSQL 的性能优化实战】 讲师：黄忠，阿里云资深技术专家。 课程内容：深入介绍AliSQL的几个核心通用性能优化技术；抽丝剥茧，带你整体学习从问题提出到解决方案落地全过程。 答疑汇总：特别感谢班委@陈亮 同学
【七天深入MySQL实战营】答疑汇总Day6 MySQL表和索引优化实战 【开营第六课】【MySQL表和索引优化实战】 讲师：田杰，阿里云高级运维专家。 课程内容：InnoDB表和索引设计最佳实践；索引设计的分析与优化。 答疑汇总：特别感谢班委@李敏 同学
【七天深入MySQL实战营】答疑汇总Day5 MySQL 开发规约实战 【开营第五课】【MySQL 开发规约实战】 讲师：芦火，阿里云运维专家。 课程内容：SQL语句编写规范；事务的使用与优化；开发中的常见问题与最佳实践。 答疑汇总：特别感谢班委@陈亮 同学
【七天深入MySQL实战营】答疑汇总Day4 MySQL查询优化实战 【开营第四课】【 MySQL查询优化实战】 讲师：苏坡，袋鼠云高级数据库工程师。 课程内容：核心概念及原理；优化流程思路；常见场景下的优化。 答疑汇总：特别感谢班委@李敏 同学
【七天深入MySQL实战营】答疑汇总Day3 MySQL Java 开发实战 【开营第三课，MySQL Java 开发实战】 讲师：义泊，阿里云技术专家。 课程内容：深入浅出ORM框架MyBatis；连接池框架HikariCP和druid的剖析和最佳实践；Java应用性能问题诊断技巧。 答疑汇总：特别感谢班委@陈亮 同学
【七天深入MySQL实战营】答疑汇总Day2 MySQL 高并发场景实战 【开营第二课，MySQL 高并发场景实战】 讲师： 凌洛，阿里云数据库解决方案专家。 课程内容：高并发场景下MySQL数据库的技术挑战；如何用RDS MySQL支撑高并发业务；高并发场景数据库运维最佳实践。 答疑汇总：特别感谢班委@李敏 同学
【七天深入MySQL实战营】答疑汇总Day1 MySQL MGR 8.0 高可用实战 【开营第一课，MySQL MGR 8.0 高可用实战】 讲师：沃趣科技 MySQL DBA张彦东老师。 课程内容：掌握集群架构和数据同步原理；掌握集群性能分析和流量控制；掌握MGR使用场景和常见高可用方案。 答疑汇总：特感谢班委@李敏 同学
MySQL · 答疑解惑 · MySQL 的那些网络超时错误 我们在使用/运维 MySQL 过程中，经常会遇到一些网络相关的错误，比如： Aborted connection 134328328 to db: test user: root host: 127.0.0.1 (Got timeout reading communication packets)
MySQL · 答疑解惑 · MySQL 锁问题最佳实践 最近一段时间处理了较多锁的问题，包括锁等待导致业务连接堆积或超时，死锁导致业务失败等，这类问题对业务可能会造成严重的影响，没有处理经验的用户往往无从下手。下面将从整个数据库设计，开发，运维阶段介绍如何避免锁问题的发生，提供一些最佳实践供RDS的用户参考。 在数据库设计阶段，引擎
db匠 rds内核团队秘密研发的全自动卖萌机. 追加特效: 发数据库内核月报. 月报传送: http://mysql.taobao.org/monthly/