mysql資料庫伺服器一般多少記憶體

時間 2021-09-08 16:32:34

1樓:愛可生雲資料庫

我們仍然使用兩個會話,一個會話 run,用於執行主 sql;另一個會話 ps,用於進行 performance_schema 的觀察:

將 performance_schema 中的統計量重置,

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

我們將會話級別的臨時表大小設定為 2m(小於上次實驗中臨時表使用的空間),執行使用臨時表的 sql:

檢視記憶體的分配記錄:

會發現記憶體分配略大於 2m,我們猜測臨時表會比配置略多一點消耗,可以忽略。

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

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

重做實驗,略過。

再檢視 performance_schema 的統計值:

可以看到幾個現象:

1. 臨時表空間被寫入了 7.92mib 的資料。

2. 這些資料是語句寫入後,慢慢逐漸寫入的。

可以看到寫入的執行緒是 page_clean_thread,是一個刷髒操作,這樣就能理解資料為什麼是慢慢寫入的。

也可以看到每個 io 操作的大小是 16k,也就是刷資料頁的操作。

結論:我們可以看到,

1. mysql 會基本遵守 max_heap_table_size 的設定,在記憶體不夠用時,直接將錶轉到磁碟上儲存。

2. 由於引擎不同(記憶體中表引擎為 heap,磁碟中表引擎則跟隨 internal_tmp_disk_storage_engine 的配置),本次實驗寫磁碟的資料量和 實驗 05 中使用記憶體的資料量不同。

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

2樓:育知同創教育

命令: show processlist;

如果是root帳號,你能看到所有使用者的當前連線。如果是其它普通帳號,只能看到自己佔用的連線。

show processlist;只列出前100條,如果想全列出請使用show full processlist;

mysql> show

processlist;

命令: show status;

命令:show status like '%下面變數%';

aborted_clients 由於客戶沒有正確關閉連線已經死掉,已經放棄的連線數量。

aborted_connects

嘗試已經失敗的mysql伺服器的連線的次數。

connections 試圖連線mysql伺服器的次數。

created_tmp_tables

當執行語句時,已經被創造了的隱含臨時表的數量。

delayed_insert_threads 正在使用的延遲插入處理器執行緒的數量。

delayed_writes 用insert delayed寫入的行數。

delayed_errors 用insert

delayed寫入的發生某些錯誤(可能重複鍵值)的行數。

flush_commands 執行flush命令的次數。

handler_delete

請求從一張表中刪除行的次數。

handler_read_first 請求讀入表中第一行的次數。

handler_read_key

請求數字基於鍵讀行。

handler_read_next 請求讀入基於一個鍵的一行的次數。

handler_read_rnd

請求讀入基於一個固定位置的一行的次數。

handler_update 請求更新表中一行的次數。

handler_write

請求向表中插入一行的次數。

key_blocks_used 用於關鍵字快取的塊的數量。

key_read_requests

請求從快取讀入一個鍵值的次數。

key_reads 從磁碟物理讀入一個鍵值的次數。

key_write_requests

請求將一個關鍵字塊寫入快取次數。

key_writes 將一個鍵值塊物理寫入磁碟的次數。

max_used_connections

同時使用的連線的最大數目。

not_flushed_key_blocks 在鍵快取中已經改變但是還沒被清空到磁碟上的鍵塊。

not_flushed_delayed_rows 在insert delay佇列中等待寫入的行的數量。

open_tables 開啟表的數量。

open_files 開啟檔案的數量。

open_streams 開啟流的數量(主要用於日誌記載)

opened_tables

已經開啟的表的數量。

questions 發往伺服器的查詢的數量。

slow_queries

要花超過long_query_time時間的查詢數量。

threads_connected 當前開啟的連線的數量。

threads_running 不在睡眠的執行緒數量。

uptime 伺服器工作了多少秒

3樓:沙灘上的鯨魚仔

檢查資料庫資料表索引否建立索引否合理使用

sql語句否存select * from 種讀取所資料情況

另外資料庫連線否 或者應用程式連線sql間沒斷

mysql佔多少記憶體

4樓:手機使用者

還暫用了一些虛擬記憶體,mysql的配置檔案(my.ini或者my.cnf或者命令列引數)可以指定用多少緩衝區等引數,用這些引數可以控制mysql佔用多少記憶體。

作業系統有很高的智慧性,對於應用程式分配的記憶體,沒有經常使用的那部分就保留到磁碟裡面,把真實記憶體留給頻繁訪問的記憶體區域,所以你也不用太擔心,遇到效能問題的再考慮優化。

我回答的很辛苦的。可以選擇,2011/9/26 14:55:09

5樓:愛可生雲資料庫

mysql 自身記憶體規劃

說到 mysql 自身的記憶體規劃,最先想到的就是 mysql 中各種 buffer 的大小,innodb buffer pool 就是最鶴立雞群的那個。innodb_buffer_pool_size 引數的大小究竟如何設定,才能保證 mysql 的效能呢?在官網文件中可以找到這個引數的一些描述:

a larger buffer pool requires less disk i/o to access the same table data more than once. on a dedicated database server, you might set the buffer pool size to 80% of the machine's physical memory size.

意思是在專用資料庫伺服器上,可以將 innodb_buffer_pool_size 設定為計算機實體記憶體大小的 80%。在許許多多前輩的的經驗中瞭解到,此引數的值設定為實體記憶體的 50%~80% 頗為合理。

舉個栗子:

innodb buffer pool 分配 76g,每個連線執行緒最大可用 160m,最大有 3000 連線數,最大可能使用記憶體總量 545g,但是這臺例項所在伺服器的實體記憶體僅僅有 97g,遠超實體記憶體總量。結果可想而知,這個例項在執行中經常被 oom-killer 殺死,想必原因之一即是因為一開始 mysql 自身的記憶體規劃欠妥。

innodb buffer pool 快取資料的作用相信大家都懂,比如這個 case 中,可以發現該例項為寫密集,讀請求很少,innodb buffer 對效能改善作用不大,80% 的記憶體沒必要,完全可以降低到實體記憶體的50%。

資料庫伺服器配置,支援大型資料庫的伺服器需要什麼配置

你這個伺服器配置,人多的時候帶70客戶端,肯定卡。如果再遇到有人執行統計報表之類的查詢,卡到你暈。這種連鎖店用伺服器,跑資料庫用,對伺服器的cpu效能 記憶體容量和磁碟讀取速度要求都比較高的。你可以看看國產品牌正睿的這款雙路四核伺服器。標配一顆至強e5620四核八執行緒處理器 2.4ghz 5.86...

怎麼啟動資料庫伺服器,怎樣啟動資料庫服務

是mssql還是mysql或其他的?你可以在服務管理介面看到相應的服務 執行 services.msc 在通電的情況下,按開機鍵啟動。怎樣啟動資料庫服務 以sqlsever為例 一 計算機管理開啟服務 1 在計算機管理框裡找到sql sever配置管理器找到sql sever服務開啟服務。2 開啟啟...

一臺伺服器怎麼設定MYSQL資料庫多使用者和管理

你只要安裝了mysql 你安裝資料庫的時候 只要列表前的名字不要一樣就可以了。n個,只要你用多個不同的表名就行了 你想怎麼分就怎麼分 一個資料庫一個名字 一個資料庫分一個帳號即可。linux 一臺伺服器,訪問另外一臺伺服器上的 mysql 資料庫怎麼設定。bin目錄是mysql控制程式所在的目錄,比...