一问一实验 头图.png

问题

我们都知道 MySQL 的 Table Cache 是表定义的缓存,江湖上流传着各种对这个参数的调优方法。
本期我们通过实验来验证 Table Cache 的作用。

实验

我们先创建一个测试数据库:

1.png

建一张空表:

2.png

建立一个连接,检查一下会话的初始状态:

3.png

在另一个窗口,开启 strace 追踪 MySQL 服务器的文件操作:

4.png

在 MySQL 中 select 新创建的表:

5.png

检查状态:

6.png

看到该操作没命中 table cache。查看 strace,确实发现 mysqld 进程打开了表结构文件(test_tbl.frm),如果我们在 strace 中也抓获 read 事件(参数改为 "-e file,read"),那可以看到 mysqld 确实读取了表结构文件。

7.png

我们再次在该会话中进行 select:

8.png

可以看到开始命中 table cache 了。在 strace 的输出中,也没有抓到新的文件操作。

可以看出 table cache 的作用,就是节约读取表结构文件的开销。

那不命中 table cache,一定会有读取表结构文件的开销么?

我们开一个新的会话,这里增加了一个标识来区分会话:

9.png

在新会话中进行 select,查看状态:

10.png

看起来确实 table cache 没有命中,也就是说 table cache 是针对于线程的,每个线程有自己的缓存,只缓存本线程的表结构定义。不过我们发现,strace 中没有关于表结构文件的 open 操作(只有 stat 操作,定位表结构文件是否存在),也就是说 table cache 不命中,不一定需要读取表结构文件。这种感觉好像是:在不命中 table cache 时,命中了另外一个表结构缓存。这个缓存就是之后我们会介绍的 table_definition_cache。

?运维建议:
我们读一下 MySQL 的文档,关于 table_open_cache 的建议值公式:
建议值 = 最大并发数 * join 语句涉及的表的最大个数。

通过实验我们容易理解:table_cache 是针对于线程的,所以需要最大并发数个缓存。另外,一个语句 join 涉及的表,需要同时在缓存中存在。所以最小的缓存大小,等于语句 join 涉及的表的最大个数。将这两个数相乘,就得到了 MySQL 的建议值公式。


关于 MySQL 的技术内容,你们还有什么想知道的吗?赶紧留言告诉小编吧!

黄炎自媒体.png


爱可生开源社区
426 声望207 粉丝

成立于 2017 年,以开源高质量的运维工具、日常分享技术干货内容、持续的全国性的社区活动为社区己任;目前开源的产品有:SQL审核工具 SQLE,分布式中间件 DBLE、数据传输组件DTLE。