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%。
PHP程式和mysql資料庫不在同伺服器上怎麼連線資料庫，詳細教程，新手
如果是本地，連線配置如下 conn mysql connect localhost root root or die 資料庫伺服器連線錯誤 mysql error mysql select db test conn or die 資料庫訪問錯誤 mysql error mysql query set...
資料庫的伺服器是不是就是伺服器的IP地址呀
護衛神 簡單理解 在伺服器上安裝一套資料庫軟體。 資料庫伺服器遠端連線一般填ip地址，在本地，一般用local 或者 localhost 有些為一個點. 這個得分成兩種情況來說，如果您用的是空間的話，您的空間服務商會給您提供資料庫的ip地址，如果是自已伺服器上面的話，只需要填成localhost就行...
sql資料庫伺服器怎麼取別名，sql server中給列取別名可以省略as嗎？
如何建立供客戶端使用的伺服器別名 sql server 配置管理器 使用 sql server 配置管理器建立的別名可以與任何客戶端應用程式一起使用。sql server 配置管理器幫助中描述的連線字串對於建立自己的連線字串的程式設計師十分有用。訪問 sql server 配置管理器幫助中的別名資訊...