人生不过就是一场旅行,你就是一辆列车,有人随时上车,有人随时下车,任何时刻别忘记,谁才是这趟车的司机, YOU  ONLY YOU.  最近比较忙，文字更新的速度的确是慢了，但这期间一个月的供应商的寻找，也是蛮有意思的，可以写一篇关于数据库供应商的文字，看看目前的供应商的水平都是在哪个位置，提供的服务是不是个性化，这次寻找供应商基本上也把业界的大公司找了一个遍。另外也逐渐有了自己的DB 团队，从技术往技术管理上必然也是要耗费精力，不过我是不会放弃，自己写东西的爱好。

正文：

说起MYSQL 本身,大部分人的思维观念还是,一个MYSQL 一个小应用,给个 16G 都算大的, 呵呵, 那你是真没见过什么世面, 一个MYSQL 在5.7的时候管理128G 内存也是OK 的,更不要提 MYSQL 8 ,所以还是收起"无知". 那问题就来了,一个大型应用的MYSQL 的内存到底给多少合算,合适,有据可依.

(首先不建议一个MYSQL的内存超级大,有些数据库服务器的内存上 T, 那是不是咱们的解耦了, 天天抱着炸药包一样,好难过)

那我们就的假设你拿到一个内存超级大的服务器,MYSQL 的内存的规划就变成一个问题了.

MYSQL 的内存其实和其他数据库一样, 分为GLOBAL 和 SESSION ,按照ORACLE 的叫法 SGA  VS PGA.

那怎么才能计算适合当下的内存配置方式

1  默认配置, 通常INNODB_BUFFER_SIZE 给到内存的65% - 75% 是一些云厂商的通常的做法,不是因为好,是因为稳定,所以初始的时候,除非你已经了解你的数据库要承接的 SESSION 数字,以及SESSION 都在运行了什么, 以及每次提取的数据量的大致之前,你不会有一个特别好的的调整方式.

这也是大公司的数据库为什么成千上万台,也好管理,因为成为规模化,标准化,而小公司的数据库,这个应用这样,那个应用那样,你想统一设置,可能吗

2  在系统运行了一段时间,(前提是不好不坏的情况下),就可以开始一个二次优化内存的过程了.

1   统计这段时间的系统最大的MAX_used_connections 

2 计算目前我们的系统应该采用多少内存

SELECT ( @@key_buffer_size + @@innodb_buffer_pool_size + 67 * (@@read_buffer_size + @@read_rnd_buffer_size + @@sort_buffer_size + @@join_buffer_size + @@tmp_table_size )) / (1024*1024*1024) AS MAX_MEMORY_GB;

为什么要这样计算

1  系统运行一段时间并没有爆出大的问题,说明innodb_buffer_pool_size 设置的并没有特别大的 所以这里使用了 innodb_buffer_pool_size 的当前值.

2  read_buffer_size   read_rnd_buffer_size   sort_buffer_size  join_buffer_size  join_buffer_size  tmp_table_size  需要和当前的connections 进行一个累加,一个连接使用的内存的可能,我们按照最大化来计算实际上不可能每个连接使用的 read_bufer_size  read_rnd_buffer_size  sort_buffer_size  join_buffer_size  join_buffer_size  timp_table_size 都是最大化的设置, 所以这里给出的后面的东西, max_memory_GB 也是符合这个意思的.

在计算完毕后,我们其实可以通过 pt-summary 的第三方工具对系统进行一个检查

mysqladmin -r -i 1 -c 60 extended-status | egrep "Innodb_buffer_pool_read_requests|Innodb_buffer_pool_reads"

通过对比

innodb_buffer_pool_read_requests  和  Innodb_buffer_pool_reads

两者的比较,做出曲线,你就可以知道你的MYSQL 的INNODB BUFFER POOL 设置的如何了,是不是需要"动动"

最后MYSQL 8 已经支持了 innodb_dedicated_server  ,通过打开这个设置自动开始对MYSQL的内存进行分配和计算, 但需要注意的是,MYSQL 的 8.0 中的 innodb_dedicated_server 并不适用于复杂环境方面的MYSQL 数据库服务器.