共计 1191 个字符，预计需要花费 3 分钟才能阅读完成。
问
在 MySQL 8.0 中, 应用长期表时, 会发现有 1G 的磁盘空间 ” 隐没 ” 了
试验
咱们先宽油做一个 MySQL 8.0.25 的实例. 此处咱们疏忽创立的步骤, 大家可参考以前的试验.
还是用咱们相熟的翻倍法, 造一张表:
不停执行最初一句 SQL , 让表中含有足够多的记录:
这里咱们设置两个长期表的配置参数, 稍后再解释其作用:
咱们还须要设置好 performance_schema , 用来察看整个过程:
还须要记录一下目前的磁盘容量:
当初咱们下一个应用长期表的 SQL , 参考试验 6:
在 SQL 执行的过程中, 察看一下磁盘空间:
数据库的磁盘总量全程并没有变动, 而磁盘总量会逐步增长, 增长 1G 左右, 而后又会降下来
这段时间到底产生了什么呢?
咱们来梳理一下 MySQL 8.0.25 中长期表的应用过程:
- 在 8.0.25 中, 长期表默认的引擎为 TempTable , 会先在内存里创立内存长期表
- 当所有内存长期表的总大小达到 temptable_max_ram 限度后, MySQL 会应用 mmap 机制, 将一部分磁盘映射作为内存应用, 这个过程中磁盘使用量会回升。(咱们在试验中将 temptable_max_ram 设置为最小值, 是为了让 MySQL 尽早应用 mmap 机制, 试验会不便一点)
- 当所有内存长期表通过 mmap 调配的内存量 (理论是磁盘) 达到 temptable_max_mmap 限度后, MySQL 会将 内存长期表 转换成 磁盘长期表 (引擎为 InnoDB 或 MyISAM). (咱们在试验中将 temptable_max_ram 设置为 1G)
- SQL 完结后, 长期表会被清理, 这个过程中, 磁盘使用量会降落
咱们从新做一次这个试验, 钻研一下怎么察看这个过程:
当然还是通过 performance_schema , 能够看到通过 mmap 分得的内存大小 (理论是磁盘大小)
除了应用 performance_schema , 还有其余伎俩察看么?
咱们还能够通过 procfs 的 smaps 察看到这片空间
能够看到: 通过 mmap 调配的空间的两个特点:
- 其调配的区域大小会逐渐翻倍
- 其对应了一个曾经删除的文件
当达到 temptable_max_mmap 限度后, 内存长期表会转换为磁盘长期表 (InnoDB/MyISAM 表) , 也能够通过 performance_schema 察看到这个步骤:
这就是 “ 隐没的磁盘 ” 的假相: MySQL 应用了 mmap , 将磁盘空间映射到了内存中, 作为内存应用.
小贴士
当 SQL 执行实现后, 咱们再仔细观察一下 performance_schema :
当 SQL 执行完后, 能够察看到长期表曾经回收 (磁盘空间曾经降落), 但 CURRENT_NUMBER_OF_BYTES_USED 并不会归零.
这个起因是 MySQL 并没有 将这片空间的回收计在 SQL 的线程上, 而是计入了全局统计:
所以会导致线程级别的统计值看上去 “ 只增不减 ”, 应用该值做统计时需小心
对于 MySQL 的技术内容，你们还有什么想晓得的吗？连忙留言通知小编吧！
