mysql 如何分配內(nèi)存

我們?nèi)匀皇褂脙蓚€(gè)會(huì)話，一個(gè)會(huì)話 run，用于運(yùn)行主 SQL；另一個(gè)會(huì)話 ps，用于進(jìn)行 performance_schema 的觀察：

創(chuàng)新互聯(lián)建站是網(wǎng)站建設(shè)專家,致力于互聯(lián)網(wǎng)品牌建設(shè)與網(wǎng)絡(luò)營銷，專業(yè)領(lǐng)域包括成都網(wǎng)站建設(shè)、網(wǎng)站建設(shè)、電商網(wǎng)站制作開發(fā)、小程序設(shè)計(jì)、微信營銷、系統(tǒng)平臺(tái)開發(fā)，與其他網(wǎng)站設(shè)計(jì)及系統(tǒng)開發(fā)公司不同，我們的整合解決方案結(jié)合了恒基網(wǎng)絡(luò)品牌建設(shè)經(jīng)驗(yàn)和互聯(lián)網(wǎng)整合營銷的理念，并將策略和執(zhí)行緊密結(jié)合，且不斷評(píng)估并優(yōu)化我們的方案，為客戶提供全方位的互聯(lián)網(wǎng)品牌整合方案！

主會(huì)話線程號(hào)為 29，

將 performance_schema 中的統(tǒng)計(jì)量重置，

臨時(shí)表的表大小限制取決于參數(shù)? tmp_table_size 和 max_heap_table_size 中較小者，我們實(shí)驗(yàn)中以設(shè)置 max_heap_table_size 為例。

我們將會(huì)話級(jí)別的臨時(shí)表大小設(shè)置為 2M（小于上次實(shí)驗(yàn)中臨時(shí)表使用的空間），執(zhí)行使用臨時(shí)表的 SQL：

查看內(nèi)存的分配記錄：

會(huì)發(fā)現(xiàn)內(nèi)存分配略大于 2M，我們猜測臨時(shí)表會(huì)比配置略多一點(diǎn)消耗，可以忽略。

查看語句的特征值：

可以看到語句使用了一次需要落磁盤的臨時(shí)表。

那么這張臨時(shí)表用了多少的磁盤呢？

我們開啟 performance_schema 中 waits 相關(guān)的統(tǒng)計(jì)項(xiàng)：

重做實(shí)驗(yàn)，略過。

再查看 performance_schema 的統(tǒng)計(jì)值：

可以看到幾個(gè)現(xiàn)象：

1. 臨時(shí)表空間被寫入了 7.92MiB 的數(shù)據(jù)。

2. 這些數(shù)據(jù)是語句寫入后，慢慢逐漸寫入的。

來看看這些寫入操作的特征，該方法我們?cè)?實(shí)驗(yàn) 03?使用過：

可以看到寫入的線程是 page_clean_thread，是一個(gè)刷臟操作，這樣就能理解數(shù)據(jù)為什么是慢慢寫入的。

也可以看到每個(gè) IO 操作的大小是 16K，也就是刷數(shù)據(jù)頁的操作。

結(jié)論：

我們可以看到，

1. MySQL 會(huì)基本遵守 max_heap_table_size 的設(shè)定，在內(nèi)存不夠用時(shí)，直接將表轉(zhuǎn)到磁盤上存儲(chǔ)。

2. 由于引擎不同（內(nèi)存中表引擎為 heap，磁盤中表引擎則跟隨 internal_tmp_disk_storage_engine 的配置），本次實(shí)驗(yàn)寫磁盤的數(shù)據(jù)量和?實(shí)驗(yàn) 05?中使用內(nèi)存的數(shù)據(jù)量不同。

3. 如果臨時(shí)表要使用磁盤，表引擎配置為 InnoDB，那么即使臨時(shí)表在一個(gè)時(shí)間很短的 SQL 中使用，且使用后即釋放，釋放后也會(huì)刷臟頁到磁盤中，消耗部分 IO。

MySQL 內(nèi)存占用總是太高，你需要立即進(jìn)行這些操作……

生產(chǎn)環(huán)境中，MySQL 不經(jīng)意間吃掉全部的內(nèi)容，然后開始吃掉 SWAP，性能一降再降，怎么辦？

可以從下面三點(diǎn)查看原因：

MySQL 使用內(nèi)存，有兩個(gè)途徑。

永久占用的內(nèi)容

比如全局緩沖區(qū)（Global Buffer）類別，是在服務(wù)器啟動(dòng)期間從操作系統(tǒng)獲得的，不會(huì)釋放到任何一個(gè)別的進(jìn)程。

動(dòng)態(tài)請(qǐng)求的內(nèi)存

線程緩沖區(qū)由MySQL使用，它是在處理新查詢時(shí)從操作系統(tǒng)請(qǐng)求的內(nèi)存。在執(zhí)行查詢之后，該內(nèi)存被釋放回操作系統(tǒng)。

這意味著 MySQL 的內(nèi)存使用，是 全局緩沖區(qū) 加上 線程緩沖區(qū) 以及 允許的最大連接數(shù) 。

對(duì)于專用數(shù)據(jù)庫服務(wù)器，該值需要保持在服務(wù)器內(nèi)存的90%以下。在共享服務(wù)器的情況下，它應(yīng)該保持在服務(wù)器內(nèi)存的50%以下。

檢查一下 MySQL 設(shè)置，有助于確定內(nèi)存使用情況，從而為 MySQL 分配合適的值。

一個(gè)近似的公式：

當(dāng)網(wǎng)站受到攻擊時(shí)，有可能在短時(shí)間內(nèi)建立異常高的連接數(shù)量。MySQL 中的 PROCESSLIST 可用于檢測頂級(jí)用戶并阻止對(duì)濫用連接的訪問。

找出查詢需要很長時(shí)間才能執(zhí)行的語句，因?yàn)檫@些查詢需要進(jìn)一步優(yōu)化服務(wù)器才能更好地執(zhí)行，可以通過服務(wù)器查詢?nèi)罩具M(jìn)行識(shí)別。由于查詢速度慢，導(dǎo)致磁盤讀取較多，導(dǎo)致內(nèi)存和CPU使用率較高，影響服務(wù)器性能。

最后，到了加內(nèi)存條的時(shí)候了。雖然在優(yōu)化數(shù)據(jù)庫設(shè)置之后，服務(wù)器會(huì)不斷地路由到使用交換內(nèi)存，但也必須增加內(nèi)存。俗話說：“巧婦難為無米之炊”，就是這個(gè)意思。

上面說的這些方向，大家可以在實(shí)際操作中驗(yàn)證體會(huì)，希望大家在數(shù)據(jù)庫優(yōu)化的路上，麻溜順暢，砥礪前行。

linux 下怎么優(yōu)化mysql占用內(nèi)存？

修改mysql配置文件，優(yōu)化緩存大小和連接數(shù)連接方式，優(yōu)化sql語句 ,記得mysql好像是有工具可以查看最占用資源的sql語句，找到他，優(yōu)化他。

安裝好mysql后，配制文件應(yīng)該在/usr/local/mysql/share/mysql目錄中，配制文件有幾個(gè)，有my-huge.cnf my-medium.cnf my-large.cnf my-small.cnf,不同的流量的網(wǎng)站和不同配制的服務(wù)器環(huán)境，當(dāng)然需要有不同的配制文件了。

一般的情況下，my-medium.cnf這個(gè)配制文件就能滿足我們的大多需要；一般我們會(huì)把配置文件拷貝到/etc/my.cnf 只需要修改這個(gè)配置文件就可以了，使用mysqladmin variables extended-status _u root _p 可以看到目前的參數(shù)，有3個(gè)配置參數(shù)是最重要的，即key_buffer_size,query_cache_size,table_cache。

key_buffer_size只對(duì)MyISAM表起作用，

key_buffer_size指定索引緩沖區(qū)的大小，它決定索引處理的速度，尤其是索引讀的速度。一般我們?cè)O(shè)為16M,實(shí)際上稍微大一點(diǎn)的站點(diǎn)　這個(gè)數(shù)字是遠(yuǎn)遠(yuǎn)不夠的，通過檢查狀態(tài)值Key_read_requests和Key_reads,可以知道key_buffer_size設(shè)置是否合理。比例 key_reads / key_read_requests應(yīng)該盡可能的低，至少是1:100，1:1000更好（上述狀態(tài)值可以使用SHOW STATUS LIKE ‘key_read%’獲得）。 或者如果你裝了phpmyadmin 可以通過服務(wù)器運(yùn)行狀態(tài)看到,筆者推薦用phpmyadmin管理mysql，以下的狀態(tài)值都是本人通過phpmyadmin獲得的實(shí)例分析:

這個(gè)服務(wù)器已經(jīng)運(yùn)行了20天

key_buffer_size _ 128M

key_read_requests _ 650759289

key_reads - 79112

比例接近1:8000 健康狀況非常好