mysql設置成內存資料庫,mysql設置成內存資料庫的方法

本文目錄一覽：

• 1、MySQL 內存佔用總是太高，你需要立即進行這些操作……
• 2、mysql 如何分配內存
• 3、如何實現mysql 內存資料庫

MySQL 內存佔用總是太高，你需要立即進行這些操作……

生產環境中，MySQL 不經意間吃掉全部的內容，然後開始吃掉 SWAP，性能一降再降，怎麼辦？

可以從下面三點查看原因：

MySQL 使用內存，有兩個途徑。

永久佔用的內容

比如全局緩衝區（Global Buffer）類別，是在伺服器啟動期間從操作系統獲得的，不會釋放到任何一個別的進程。

動態請求的內存

線程緩衝區由MySQL使用，它是在處理新查詢時從操作系統請求的內存。在執行查詢之後，該內存被釋放回操作系統。

這意味著 MySQL 的內存使用，是 全局緩衝區 加上 線程緩衝區 以及 允許的最大連接數 。

對於專用資料庫伺服器，該值需要保持在伺服器內存的90%以下。在共享伺服器的情況下，它應該保持在伺服器內存的50%以下。

檢查一下 MySQL 設置，有助於確定內存使用情況，從而為 MySQL 分配合適的值。

一個近似的公式：

當網站受到攻擊時，有可能在短時間內建立異常高的連接數量。MySQL 中的 PROCESSLIST 可用於檢測頂級用戶並阻止對濫用連接的訪問。

找出查詢需要很長時間才能執行的語句，因為這些查詢需要進一步優化伺服器才能更好地執行，可以通過伺服器查詢日誌進行識別。由於查詢速度慢，導致磁碟讀取較多，導致內存和CPU使用率較高，影響伺服器性能。

最後，到了加內存條的時候了。雖然在優化資料庫設置之後，伺服器會不斷地路由到使用交換內存，但也必須增加內存。俗話說：「巧婦難為無米之炊」，就是這個意思。

上面說的這些方向，大家可以在實際操作中驗證體會，希望大家在資料庫優化的路上，麻溜順暢，砥礪前行。

mysql 如何分配內存

我們仍然使用兩個會話，一個會話 run，用於運行主 SQL；另一個會話 ps，用於進行 performance_schema 的觀察：

主會話線程號為 29，

將 performance_schema 中的統計量重置，

臨時表的表大小限制取決於參數  tmp_table_size 和 max_heap_table_size 中較小者，我們實驗中以設置 max_heap_table_size 為例。

我們將會話級別的臨時表大小設置為 2M（小於上次實驗中臨時表使用的空間），執行使用臨時表的 SQL：

查看內存的分配記錄：

會發現內存分配略大於 2M，我們猜測臨時表會比配置略多一點消耗，可以忽略。

查看語句的特徵值：

可以看到語句使用了一次需要落磁碟的臨時表。

那麼這張臨時表用了多少的磁碟呢？

我們開啟 performance_schema 中 waits 相關的統計項：

重做實驗，略過。

再查看 performance_schema 的統計值：

可以看到幾個現象：

1. 臨時表空間被寫入了 7.92MiB 的數據。

2. 這些數據是語句寫入後，慢慢逐漸寫入的。

來看看這些寫入操作的特徵，該方法我們在 實驗 03 使用過：

可以看到寫入的線程是 page_clean_thread，是一個刷臟操作，這樣就能理解數據為什麼是慢慢寫入的。

也可以看到每個 IO 操作的大小是 16K，也就是刷數據頁的操作。

結論：

我們可以看到，

1. MySQL 會基本遵守 max_heap_table_size 的設定，在內存不夠用時，直接將錶轉到磁碟上存儲。

2. 由於引擎不同（內存中表引擎為 heap，磁碟中表引擎則跟隨 internal_tmp_disk_storage_engine 的配置），本次實驗寫磁碟的數據量和 實驗 05 中使用內存的數據量不同。

3. 如果臨時表要使用磁碟，表引擎配置為 InnoDB，那麼即使臨時表在一個時間很短的 SQL 中使用，且使用後即釋放，釋放後也會刷臟頁到磁碟中，消耗部分 IO。

如何實現mysql 內存資料庫

有一個表引擎叫內存表，你在新建時可以選擇，或已有的表可以修改過去