人生不過就是一場旅行,你就是一輛列車,有人隨時上車,有人隨時下車,任什麼時候刻別忘記,誰纔是這趟車的司機, 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源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。