人生不过就是一场旅行,你就是一辆列车,有人随时上车,有人随时下车,任什么时候刻别忘记,谁才是这趟车的司机, YOU ONLY YOU. 最近比较忙，文字更新的速度的确是慢了，但这期间一个月的供应商的寻找，也是蛮有意思的，能够写一篇关于数据库供应商的文字，看看目前的供应商的水平都是在哪一个位置，提供的服务是否是个性化，此次寻找供应商基本上也把业界的大公司找了一个遍。另外也逐渐有了本身的DB 团队，从技术往技术管理上必然也是要耗费精力，不过我是不会放弃，本身写东西的爱好。
mysql
正文：
sql
提及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 都在运行了什么, 以及每次提取的数据量的大体以前,你不会有一个特别好的的调整方式.url
这也是大公司的数据库为何成千上万台,也好管理,由于成为规模化,标准化,而小公司的数据库,这个应用这样,那个应用那样,你想统一设置,可能吗spa
2 在系统运行了一段时间,(前提是很差不坏的状况下),就能够开始一个二次优化内存的过程了.
.net
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 数据库服务器.
本文分享自微信公众号 - AustinDatabases（AustinDatabases）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。