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控制程式所在的目錄，比...