一、優化方式php
硬件優化=》系統優化=》mysql配置優化=》SCHEMA優化=》sql優化=》其餘解決方案（redis or MongoDB or Cassandra or HBase）html
二、mysql配置分析mysql
1）常見瓶頸linux
90%系統瓶頸都在IO上，因此提升IOPS尤其總要，iowait太高，加內存，減少數據讀取量redis
若是CPU很高，或者查詢時間很長，90%索引不當算法
若是系統發生swap，一定是內存分配不當sql
因此優化，老是會圍繞着提升對內存的使用率+減小IO，好比內存緩存+索引，還有其餘方式嗎，NO數據庫
2）確認方式緩存
slow log + global status + engine status + processlist + pt工具安全
3）環境
mysql Ver 14.14 Distrib 5.6.25, for Linux (x86_64) using EditLine wrapper && CentOS release 6.7 (Final)
三、mysql配置優化
1）慢查詢日誌
在mysql服務器中，數據表都是保存在磁盤上的（innodb、myisam組織表的形式不一樣，因此文件結構也就不一樣）。索引爲服務器提供了一種在表中查找特定數據行的方法，而不用搜索整個表。當必需要搜索整個表時，就稱爲表掃描。一般來講，您可能只但願得到表中數據的一個子集，所以全表掃描會浪費大量的磁盤 I/O，所以也就會浪費大量時間。當必須對數據進行鏈接時，這個問題就更加複雜了，由於必需要對鏈接兩端的多行數據進行比較。
固然，表掃描並不老是會帶來問題；有時讀取整個表反而會比從中挑選出一部分數據更加有效（服務器進程中查詢優化器用來做出這些決定）。若是索引的使用效率很低，或者根本就不能使用索引，則會減慢查詢速度，並且隨着服務器上的負載和表大小的增長，這個問題會變得更加顯著。執行時間超過給定時間範圍的查詢就稱爲慢速查詢。
在my.cnf中開啓慢日誌
|
1
2
3
4
|
long_query_time = 2
slow-query-log =
on
slow-query-log-file = /data/mysql/slow-query.log
log-queries-not-
using
-indexes
|
查看是否開啓
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
mysql> show variables like
'%slow_query%'
;
+---------------------+----------------------------+
| Variable_name | Value |
+---------------------+----------------------------+
| slow_query_log | ON |
| slow_query_log_file | /data/mysql/slow-query.log |
+---------------------+----------------------------+
mysql> show global status like
'%slow%'
;
+---------------------+-------+
| Variable_name | Value |
+---------------------+-------+
| Slow_launch_threads | 0 |
| Slow_queries | 4148 |
+---------------------+-------+
|
打開慢查詢日誌可能會對系統性能有一點點影響，若是你的MySQL是主－從結構，能夠考慮打開其中一臺從服務器的慢查詢日誌，這樣既能夠監控慢查詢，對系統性能影響又小，另mysql有自帶的命令mysqldumpslow可進行查詢，也可使用pt工具進行分析（pt-query-digest）
例下列命令能夠查出訪問次數最多的20個sql語句
|
1
|
mysqldumpslow -s c -t 20 slow-query.log
|
2）鏈接數
常常會碰見」MySQL: ERROR 1040: Too manyconnections」的狀況，一種是訪問量確實很高，MySQL服務器抗不住，這個時候就要考慮增長從服務器分散讀壓力，另一種狀況是MySQL配置文件中max_connections值太小
|
1
2
3
4
5
6
|
mysql> show variables like
'max_connections'
;
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| max_connections | 256 |
+-----------------+-------+
|
這臺MySQL服務器最大鏈接數是256，而後查詢一下服務器響應的最大鏈接數
|
1
2
3
4
5
6
|
mysql> show global status like
'Max_used_connections'
;
+----------------------+-------+
| Variable_name | Value |
+----------------------+-------+
| Max_used_connections | 245 |
+----------------------+-------+
|
MySQL服務器過去的最大鏈接數是245，沒有達到服務器鏈接數上限256，不會出現1040錯誤，最大鏈接數占上限鏈接數的85％左右，若是發現比例在10%如下，MySQL服務器鏈接數上限設置的太高了
比較理想的設置是：Max_used_connections / max_connections * 100% ≈ 85%
還有兩個比較重要參數
|
1
2
|
wait_timeout=10
max_connect_errors = 100
|
wait_timeout指的是mysqld 終止全部空閒時間超過 10 秒的鏈接。在 LAMP 應用程序中，鏈接數據庫的時間一般就是 Web 服務器處理請求所花費的時間。有時候，若是負載太重，鏈接會掛起，而且會佔用鏈接表空間。若是有多個交互用戶或使用了到數據庫的持久鏈接，那麼將這個值設低一點並不可取
max_connect_errors 是一個安全的方法。若是一個主機在鏈接到服務器時有問題，並重試不少次後放棄，那麼這個主機就會被鎖定，直到 FLUSH HOSTS 以後才能運行。默認狀況下，10 次失敗就足以致使鎖定了。將這個值修改成 100 會給服務器足夠的時間來從問題中恢復。若是重試 100 次都沒法創建鏈接，那麼使用再高的值也不會有太多幫助，可能它根本就沒法鏈接。
3）Key_buffer_size
key_buffer_size是對MyISAM表性能影響最大的一個參數，下面一臺以MyISAM爲主要存儲引擎服務器的配置
|
1
2
3
4
5
6
|
mysql> show variables like
'key_buffer_size'
;
+-----------------+------------+
| Variable_name | Value |
+-----------------+------------+
| key_buffer_size | 536870912 |
+-----------------+------------+
|
分配了512MB內存給key_buffer_size，咱們再看一下key_buffer_size的使用狀況
|
1
2
3
4
5
6
7
|
mysql> show global status like
'key_read%'
;
+------------------------+-------------+
| Variable_name | Value |
+------------------------+-------------+
| Key_read_requests | 27813678764 |
| Key_reads | 6798830 |
+------------------------+-------------+
|
Key_reads 表明命中磁盤的請求個數， Key_read_requests 是總數
一共有27813678764個索引讀取請求，有6798830個請求在內存中沒有找到直接從硬盤讀取索引
計算索引未命中緩存的機率：key_cache_miss_rate ＝ Key_reads / Key_read_requests * 100%
好比上面的數據，key_cache_miss_rate爲0.0244%，4000個索引讀取請求才有一個直接讀硬盤，已經很BT 了，key_cache_miss_rate在0.1%如下都很好（每1000個請求有一個直接讀硬盤），若是key_cache_miss_rate在 0.01%如下的話，key_buffer_size分配的過多，能夠適當減小，若是每 1,000 個請求中命中磁盤的數目超過 1 個，就應該考慮增大關鍵字緩衝區了。例如，key_buffer = 384M 會將緩衝區設置爲 384MB。
MySQL服務器還提供了key_blocks_*參數
|
1
2
3
4
5
6
7
|
mysql> show global status like
'key_blocks_u%'
;
+------------------------+-------------+
| Variable_name | Value |
+------------------------+-------------+
| Key_blocks_unused | 0 |
| Key_blocks_used | 413543 |
+------------------------+-------------+
|
Key_blocks_unused 表示未使用的緩存簇(blocks)數，Key_blocks_used表示曾經用到的最大的blocks數，好比這臺服務器，全部的緩存都用到了，要麼增長key_buffer_size，要麼就是過渡索引了，把緩存佔滿了
比較理想的設置：Key_blocks_used / (Key_blocks_unused + Key_blocks_used) * 100% ≈ 80%
4）臨時表
臨時表能夠在更高級的查詢中使用，其中數據在進一步進行處理（例如 GROUP BY 字句）以前，都必須先保存到臨時表中；理想狀況下，在內存中建立臨時表。可是若是臨時表變得太大，就須要寫入磁盤中
|
1
2
3
4
5
6
7
8
|
mysql> show global status like
'created_tmp%'
;
+-------------------------+---------+
| Variable_name | Value |
+-------------------------+---------+
| Created_tmp_disk_tables | 21197 |
| Created_tmp_files | 58 |
| Created_tmp_tables | 1771587 |
+-------------------------+---------+
|
每次建立臨時表，Created_tmp_tables增長，若是是在磁盤上建立臨時表，Created_tmp_disk_tables也增長,Created_tmp_files表示MySQL服務建立的臨時文件文件數
比較理想的配置是：Created_tmp_disk_tables / Created_tmp_tables * 100% <= 25%
好比上面的服務器Created_tmp_disk_tables / Created_tmp_tables * 100% ＝ 1.20%，應該至關好了
咱們再看一下MySQL服務器對臨時表的配置
|
1
2
3
4
5
6
7
|
mysql> show variables
where
Variable_name
in
(
'tmp_table_size'
,
'max_heap_table_size'
);
+---------------------+-----------+
| Variable_name | Value |
+---------------------+-----------+
| max_heap_table_size | 268435456 |
| tmp_table_size | 536870912 |
+---------------------+-----------+
|
只有256MB如下的臨時表才能所有放內存，超過的就會用到硬盤臨時表
每次使用臨時表都會增大 Created_tmp_tables；基於磁盤的表也會增大 Created_tmp_disk_tables。對於這個比率，並無什麼嚴格的規則，由於這依賴於所涉及的查詢。長時間觀察 Created_tmp_disk_tables 會顯示所建立的磁盤表的比率，您能夠肯定設置的效率。tmp_table_size 和 max_heap_table_size 均可以控制臨時表的最大大小，所以請確保在 my.cnf 中對這兩個值都進行了設置
5）Open Table狀況
|
1
2
3
4
5
6
|
mysql> show global status like
'open%tables%'
;
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Open_tables | 919 |
| Opened_tables | 1951 |
|
Open_tables 表示打開表的數量，Opened_tables表示打開過的表數量，若是Opened_tables數量過大，說明配置中 table_cache(5.1.3以後這個值叫作table_open_cache)值可能過小，咱們查詢一下服務器table_cache值
|
1
2
3
4
5
6
|
mysql> show variables like
'table_cache'
;
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| table_cache | 2048 |
+---------------+-------+
|
比較合適的值爲：Open_tables / Opened_tables * 100% >= 85% Open_tables / table_cache * 100% <= 95%
6）線程使用狀況
與表的緩存相似，對於線程來講也有一個緩存。 mysqld 在接收鏈接時會根據須要生成線程。在一個鏈接變化很快的繁忙服務器上，對線程進行緩存便於之後使用能夠加快最初的鏈接
|
1
2
3
4
5
6
7
8
9
|
mysql> show global status like
'Thread%'
;
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| Threads_cached | 46 |
| Threads_connected | 2 |
| Threads_created | 570 |
| Threads_running | 1 |
+-------------------+-------+
|
若是咱們在MySQL服務器配置文件中設置了thread_cache_size，當客戶端斷開以後，服務器處理此客戶的線程將會緩存起來以響應下一個客戶 而不是銷燬（前提是緩存數未達上限）。Threads_created表示建立過的線程數，若是發現Threads_created值過大的話，代表 MySQL服務器一直在建立線程，這也是比較耗資源，能夠適當增長配置文件中thread_cache_size值，查詢服務器 thread_cache_size配置
|
1
2
3
4
5
6
|
mysql> show variables like
'thread_cache_size'
;
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| thread_cache_size | 64 |
+-------------------+-------+
|
7）查詢緩存(query cache)
不少 LAMP 應用程序都嚴重依賴於數據庫，但卻會反覆執行相同的查詢。每次執行查詢時，數據庫都必需要執行相同的工做 —— 對查詢進行分析，肯定如何執行查詢，從磁盤中加載信息，而後將結果返回給客戶機。MySQL 有一個特性稱爲查詢緩存，它將（後面會用到的）查詢結果保存在內存中。在不少狀況下，這會極大地提升性能。不過，問題是查詢緩存在默認狀況下是禁用的
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
mysql> show global status like
'qcache%'
;
+-------------------------+-----------+
| Variable_name | Value |
+-------------------------+-----------+
| Qcache_free_blocks | 22756 |
| Qcache_free_memory | 76764704 |
| Qcache_hits | 213028692 |
| Qcache_inserts | 208894227 |
| Qcache_lowmem_prunes | 4010916 |
| Qcache_not_cached | 13385031 |
| Qcache_queries_in_cache | 43560 |
| Qcache_total_blocks | 111212 |
+-------------------------+-----------+
|
MySQL查詢緩存變量解釋：
Qcache_free_blocks：緩存中相鄰內存塊的個數，數目大說明可能有碎片。FLUSH QUERY CACHE會對緩存中的碎片進行整理。
Qcache_free_memory：緩存中的空閒內存。
Qcache_hits：每次查詢在緩存中命中時就增大
Qcache_inserts：每次插入一個查詢時就增大。命中次數除以插入次數就是不中比率。
Qcache_lowmem_prunes： 緩存出現內存不足而且必需要進行清理以便爲更多查詢提供空間的次數。這個數字最好長時間來看；若是這個數字在不斷增加，就表示可能碎片很是嚴重，或者內存不多。（上面的 free_blocks和free_memory能夠告訴您屬於哪一種狀況）
Qcache_not_cached：不適合進行緩存的查詢的數量，一般是因爲這些查詢不是 SELECT 語句或者用了now()之類的函數。
Qcache_queries_in_cache：當前緩存的查詢（和響應）的數量。
Qcache_total_blocks：緩存中塊的數量。
咱們再查詢一下服務器關於query_cache的配置
|
1
2
3
4
5
6
7
8
9
10
|
mysql> show variables like
'query_cache%'
;
+------------------------------+-----------+
| Variable_name | Value |
+------------------------------+-----------+
| query_cache_limit | 2097152 |
| query_cache_min_res_unit | 4096 |
| query_cache_size | 203423744 |
| query_cache_type | ON |
| query_cache_wlock_invalidate | OFF |
+------------------------------+-----------+
|
各字段的解釋：
query_cache_limit：超過此大小的查詢將不緩存
query_cache_min_res_unit：緩存塊的最小大小
query_cache_size：查詢緩存大小
query_cache_type：緩存類型，決定緩存什麼樣的查詢，示例中表示不緩存 select sql_no_cache 查詢
query_cache_wlock_invalidate：當有其餘客戶端正在對MyISAM表進行寫操做時，若是查詢在query cache中，是否返回cache結果仍是等寫操做完成再讀表獲取結果。
query_cache_min_res_unit的配置是一柄」雙刃劍」，默認是4KB，設置值大對大數據查詢有好處，但若是你的查詢都是小數據查詢，就容易形成內存碎片和浪費。
查詢緩存碎片率 = Qcache_free_blocks / Qcache_total_blocks * 100%
若是查詢緩存碎片率超過20%，能夠用FLUSH QUERY CACHE整理緩存碎片，或者試試減少query_cache_min_res_unit，若是你的查詢都是小數據量的話。
查詢緩存利用率 = (query_cache_size - Qcache_free_memory) / query_cache_size * 100%
查詢緩存利用率在25%如下的話說明query_cache_size設置的過大，可適當減少；查詢緩存利用率在80％以上並且Qcache_lowmem_prunes > 50的話說明
query_cache_size可能有點小，要不就是碎片太多。
查詢緩存命中率 = (Qcache_hits - Qcache_inserts) / Qcache_hits * 100%
示例服務器 查詢緩存碎片率 ＝ 20.46％，查詢緩存利用率 ＝ 62.26％，查詢緩存命中率 ＝ 1.94％，命中率不好，可能寫操做比較頻繁吧，並且可能有些碎片。
做爲一條規則，若是 FLUSH QUERY CACHE 佔用了很長時間，那就說明緩存太大了
8）排序使用狀況
|
1
2
3
4
5
6
7
8
9
|
mysql> show global status like
'sort%'
;
+-------------------+------------+
| Variable_name | Value |
+-------------------+------------+
| Sort_merge_passes | 29 |
| Sort_range | 37432840 |
| Sort_rows | 9178691532 |
| Sort_scan | 1860569 |
+-------------------+------------+
|
Sort_merge_passes 包括兩步。MySQL 首先會嘗試在內存中作排序，使用的內存大小由系統變量Sort_buffer_size 決定，若是它的大小不夠把全部的記錄都讀到內存中，MySQL 就會把每次在內存中排序的結果存到臨時文件中，等MySQL 找到全部記錄以後，再把臨時文件中的記錄作一次排序。這再次排序就會增長 Sort_merge_passes。實際上，MySQL會用另外一個臨時文件來存再次排序的結果，因此一般會看到 Sort_merge_passes增長的數值是建臨時文件數的兩倍。由於用到了臨時文件，因此速度可能會比較慢，增長 Sort_buffer_size 會減小Sort_merge_passes 和 建立臨時文件的次數，但盲目的增長Sort_buffer_size 並不必定能提升速度
9）文件打開數(open_files)
|
1
2
3
4
5
6
7
8
9
10
11
12
|
mysql> show global status like
'open_files'
;
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Open_files | 1410 |
+---------------+-------+
mysql> show variables like
'open_files_limit'
;
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| open_files_limit | 4590 |
+------------------+-------+
|
比較合適的設置：Open_files / open_files_limit * 100% <= 75％
|
1
2
3
4
5
6
7
|
mysql> show global status like
'table_locks%'
;
+-----------------------+-----------+
| Variable_name | Value |
+-----------------------+-----------+
| Table_locks_immediate | 490206328 |
| Table_locks_waited | 2084912 |
+-----------------------+-----------+
|
Table_locks_immediate 表示當即釋放表鎖數，Table_locks_waited表示須要等待的表鎖數
若是Table_locks_immediate / Table_locks_waited >5000，最好採用InnoDB引擎，由於InnoDB是行鎖而MyISAM是表鎖，對於高併發寫入的應用InnoDB效果會好些。示例中的服務 器Table_locks_immediate / Table_locks_waited ＝ 235，MyISAM就足夠了
10）表鎖狀況
|
1
2
3
4
5
6
7
|
mysql> show global status like
'table_locks%'
;
+-----------------------+-----------+
| Variable_name | Value |
+-----------------------+-----------+
| Table_locks_immediate | 490206328 |
| Table_locks_waited | 2084912 |
+-----------------------+-----------+
|
Table_locks_immediate 表示當即釋放表鎖數，Table_locks_waited表示須要等待的表鎖數
若是Table_locks_immediate / Table_locks_waited >5000，最好採用InnoDB引擎，由於InnoDB是行鎖而MyISAM是表鎖，對於高併發寫入的應用InnoDB效果會好些。示例中的服務 器Table_locks_immediate / Table_locks_waited ＝ 235，MyISAM就足夠了
11）表掃描狀況
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
mysql> show global status like
'handler_read%'
;
+-----------------------+-------------+
| Variable_name | Value |
+-----------------------+-------------+
| Handler_read_first | 5803750 |
| Handler_read_key | 6049319850 |
| Handler_read_next | 94440908210 |
| Handler_read_prev | 34822001724 |
| Handler_read_rnd | 405482605 |
| Handler_read_rnd_next | 18912877839 |
+-----------------------+-------------+
mysql> show global status like
'com_select'
;
+---------------+-----------+
| Variable_name | Value |
+---------------+-----------+
| Com_select | 222693559 |
+---------------+-----------+
|
計算表掃描率：
表掃描率 ＝ Handler_read_rnd_next / Com_select
若是表掃描率超過4000，說明進行了太多表掃描，頗有可能索引沒有建好，增長read_buffer_size值會有一些好處，但最好不要超過8MB
12）table_definition_cache
表定義信息緩存是從MySQL5.1.3 版本纔開始引入的一個新的緩存區，用來存放表定義信息。當咱們的MySQL 中使用了較多的表的時候，此緩存無疑會提升對錶定義信息的訪問效率。MySQL 提供了table_definition_cache 參數給咱們設置能夠緩存的表的數量。在MySQL5.1.25 以前的版本中，默認值爲128，從MySQL5.1.25 版本開始，則將默認值調整爲256 了，最大設置值爲524288，當前版本默認值爲528。注意，這裏設置的是能夠緩存的表定義信息的數目，而不是內存空間的大小
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
mysql> show global variables like
'%definition%'
;
+------------------------+-------+
| Variable_name | Value |
+------------------------+-------+
| table_definition_cache | 528 |
+------------------------+-------+
1 row
in
set
(0.00 sec)
mysql> show status like
'%definition%'
;
+--------------------------+-------+
| Variable_name | Value |
+--------------------------+-------+
| Open_table_definitions | 70 |
| Opened_table_definitions | 0 |
+--------------------------+-------+
2 rows
in
set
(0.02 sec)
|
四、內存的組成
innodb存儲引擎能夠分爲三部分：內存、進程、數據文件
innodb的內存的做用大體以下
- 緩存磁盤上的數據，方便快速的讀取；
- 對磁盤文件的數據進行修改以前在這裏緩存；
- 應用所做的日誌的緩存；
- 內存結構自身的管理結構
1）Innodb buffer pool
緩衝池是最大塊的內存部分，主要用來各類數據的緩衝。innodb將數據文件按頁（16K）讀取到緩衝池，而後按最少使用（LRU)算法來保留緩存數據；數據文件修改時，先修改緩存池中的頁（即髒頁），而後按必定平率將髒頁刷新到文件
|
1
2
3
4
5
6
7
8
9
10
|
mysql> show variables like
'innodb_%_size'
;
+---------------------------------+------------+
| Variable_name | Value |
+---------------------------------+------------+
| innodb_additional_mem_pool_size | 2097152 |
| innodb_buffer_pool_size | 2013265920 |
| innodb_log_buffer_size | 8388608 |
| innodb_log_file_size | 1048576000 |
+---------------------------------+------------+
4 rows
in
set
(0.00 sec)
|
按照數據頁的類型
一、有索引頁
二、數據頁
四、undo頁
五、插入緩衝
六、自適應哈希索引
七、InnoDB存儲的鎖信息、數據字典信息等
經過show engine innodb status能夠查看緩衝池的具體信息
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 2058485760;
in
additional pool allocated 0
Dictionary memory allocated 819282
Buffer pool size 122879
Free buffers 97899
Database pages 24014
Old database pages 8844
Modified db pages 8
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 6, not young 0
0.00 youngs/s, 0.00 non-youngs/s
Pages read 1049, created 41540, written 30276412
0.00 reads/s, 0.00 creates/s, 1.55 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 24014, unzip_LRU len: 0
|
這邊的單位是buffer frame，每一個buffer frame爲16K，經過計算能夠查看buffer pool的使用狀況
一、Buffer pool size 122879×16×1024 = 2013249536
二、Free buffers表示當前空閒的緩衝頁
三、Database pages表示已經使用的緩衝頁
四、Modified db pages 表示髒頁的數量
五、Old database pages表示LRU列表中old sublist中的數據塊數量
對上面的innodb buffer pool細看會發現，buffer pool的數據類型又能夠分爲：page cache、hash index、undo、insert buffer、explicit locks
2）Log Buffer
日誌緩衝池（功能跟oracle redo log buffer基本類似），將重作日誌信息放入這個緩衝區，而後按必定頻率將其刷新到重作日誌文件。該值通常不須要設置很大，由於通常狀況下每一秒鐘就會將重作日誌緩衝刷新到日誌文件，只須要保證每秒產生的事物量在這個緩衝大小以內便可
3）additional buffer pool
在innodb存儲引擎中，對內存的管理是經過一種稱爲內存堆的方式進行的。在對一些數據結構自己分配內存時，須要從額外得到內存池中申請，當該區 域的內存不夠時，Innodb會從緩衝池中申請。可是每一個緩衝池中的frame buffer還有對應的緩衝控制對象，這些對象記錄了諸如LRU、鎖、等待等方面的信息，而這個對象的內存須要從額外內存中申請。所以，當你申請了很大的 Innodb緩衝池時，這個值也應該相應增長；
簡單理解爲：額外緩衝池用於管理緩衝池的內容的，因此緩衝池越大額外換池也須要越大
4）內存計算
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
used_Mem =
+ key_buffer_size
+ query_cache_size
+ innodb_buffer_pool_size
+ innodb_additional_mem_pool_size
+ innodb_log_buffer_size
+ max_connections *(
+ read_buffer_size
+ read_rnd_buffer_size
+ sort_buffer_size
+ join_buffer_size
+ binlog_cache_size
+ thread_stack
+ tmp_table_size
+ bulk_insert_buffer_size
)
|
sql
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
SELECT (
@@key_buffer_size +
@@query_cache_size +
@@tmp_table_size +
@@innodb_buffer_pool_size +
@@innodb_additional_mem_pool_size +
@@innodb_log_buffer_size +
@@max_connections * (
@@read_buffer_size +
@@read_rnd_buffer_size +
@@sort_buffer_size +
@@join_buffer_size +
@@binlog_cache_size +
@@thread_stack +
@@bulk_insert_buffer_size ) ) /
@giga_bytes AS MAX_MEMORY_GB;
|
參考文章
http://www.ibm.com/developerworks/cn/linux/l-tune-lamp-3.html#resources
http://database.51cto.com/art/201010/229956.htm
http://news.oneapm.com/php-xhprof-xhgui/
http://mp.weixin.qq.com/s?__biz=MjM5NDE0MjI4MA==&mid=208777870&idx=1&sn=6efddd6283e4deb3fe55a141b0db965c&scene=1&srcid=0910kYIbazQSBqZEivwahGHB&key=dffc561732c2265104613d6540d35b8ad5c92c340ed903cbbd8218ac9ba70f5b9d36aaa09033e2f9cf0e7983792311d4&ascene=1&uin=MjM2NjkwNQ%3D%3D&devicetype=Windows+7&version=61020020&pass_ticket=JuXI39h6lA0f0sHQ0AFMc7g2Z4NJXU5U71301BBDAuw%3D
http://pingzhao1990.blog.163.com/blog/static/113566342201531583628765/