问题
我们都知道 MySQL 的 Table Cache 是表定义的缓存,江湖上流传着各种对这个参数的调优方法。
本期我们通过实验来验证 Table Cache 的作用。
实验
我们先创建一个测试数据库:
建一张空表:
建立一个连接,检查一下会话的初始状态:
在另一个窗口,开启 strace 追踪 MySQL 服务器的文件操作:
在 MySQL 中 select 新创建的表:
检查状态:
看到该操作没命中 table cache。查看 strace,确实发现 mysqld 进程打开了表结构文件(test_tbl.frm),如果我们在 strace 中也抓获 read 事件(参数改为 "-e file,read"),那可以看到 mysqld 确实读取了表结构文件。
我们再次在该会话中进行 select:
可以看到开始命中 table cache 了。在 strace 的输出中,也没有抓到新的文件操作。
可以看出 table cache 的作用,就是节约读取表结构文件的开销。
那不命中 table cache,一定会有读取表结构文件的开销么?
我们开一个新的会话,这里增加了一个标识来区分会话:
在新会话中进行 select,查看状态:
看起来确实 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 的技术内容,你们还有什么想知道的吗?赶紧留言告诉小编吧!
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。