mysql設置緩存時間設置

❶ 如何設置合理的mysql的參數

[client]
port = 3306
socket = /tmp/mysql.sock
[mysqld]
port = 3306
socket = /tmp/mysql.sock

basedir = /usr/local/mysql
datadir = /data/mysql
pid-file = /data/mysql/mysql.pid
user = mysql
bind-address = 0.0.0.0
server-id = 1 #表示是本機的序號為1,一般來講就是master的意思

skip-name-resolve
# 禁止MySQL對外部連接進行DNS解析，使用這一選項可以消除MySQL進行DNS解析的時間。但需要注意，如果開啟該選項，
# 則所有遠程主機連接授權都要使用IP地址方式，否則MySQL將無法正常處理連接請求

#skip-networking

back_log = 600
# MySQL能有的連接數量。當主要MySQL線程在一個很短時間內得到非常多的連接請求，這就起作用，
# 然後主線程花些時間(盡管很短)檢查連接並且啟動一個新線程。back_log值指出在MySQL暫時停止回答新請求之前的短時間內多少個請求可以被存在堆棧中。
# 如果期望在一個短時間內有很多連接，你需要增加它。也就是說，如果MySQL的連接數據達到max_connections時，新來的請求將會被存在堆棧中，
# 以等待某一連接釋放資源，該堆棧的數量即back_log，如果等待連接的數量超過back_log，將不被授予連接資源。
# 另外，這值（back_log）限於您的操作系統對到來的TCP/IP連接的偵聽隊列的大小。
# 你的操作系統在這個隊列大小上有它自己的限制（可以檢查你的OS文檔找出這個變數的最大值），試圖設定back_log高於你的操作系統的限制將是無效的。

max_connections = 1000
#
MySQL的最大連接數，如果伺服器的並發連接請求量比較大，建議調高此值，以增加並行連接數量，當然這建立在機器能支撐的情況下，因為如果連接數越多，
介於MySQL會為每個連接提供連接緩沖區，就會開銷越多的內存，所以要適當調整該值，不能盲目提高設值。可以過'conn%'通配符查看當前狀態的連接
數量，以定奪該值的大小。

max_connect_errors = 6000
# 對於同一主機，如果有超出該參數值個數的中斷錯誤連接，則該主機將被禁止連接。如需對該主機進行解禁，執行：FLUSH HOST。

open_files_limit = 65535
# MySQL打開的文件描述符限制，默認最小1024;當open_files_limit沒有被配置的時候，比較max_connections*5和ulimit -n的值，哪個大用哪個，
# 當open_file_limit被配置的時候，比較open_files_limit和max_connections*5的值，哪個大用哪個。

table_open_cache = 128
# MySQL每打開一個表，都會讀入一些數據到table_open_cache緩存中，當MySQL在這個緩存中找不到相應信息時，才會去磁碟上讀取。默認值64
# 假定系統有200個並發連接，則需將此參數設置為200*N(N為每個連接所需的文件描述符數目)；
# 當把table_open_cache設置為很大時，如果系統處理不了那麼多文件描述符，那麼就會出現客戶端失效，連接不上

max_allowed_packet = 4M
# 接受的數據包大小；增加該變數的值十分安全，這是因為僅當需要時才會分配額外內存。例如，僅當你發出長查詢或MySQLd必須返回大的結果行時MySQLd才會分配更多內存。
# 該變數之所以取較小默認值是一種預防措施，以捕獲客戶端和伺服器之間的錯誤信息包，並確保不會因偶然使用大的信息包而導致內存溢出。

binlog_cache_size = 1M
# 一個事務，在沒有提交的時候，產生的日誌，記錄到Cache中；等到事務提交需要提交的時候，則把日誌持久化到磁碟。默認binlog_cache_size大小32K

max_heap_table_size = 8M
# 定義了用戶可以創建的內存表(memory table)的大小。這個值用來計算內存表的最大行數值。這個變數支持動態改變

tmp_table_size = 16M
# MySQL的heap（堆積）表緩沖大小。所有聯合在一個DML指令內完成，並且大多數聯合甚至可以不用臨時表即可以完成。
# 大多數臨時表是基於內存的(HEAP)表。具有大的記錄長度的臨時表 (所有列的長度的和)或包含BLOB列的表存儲在硬碟上。
#

如果某個內部heap（堆積）表大小超過tmp_table_size，MySQL可以根據需要自動將內存中的heap表改為基於硬碟的MyISAM表。
還可以通過設置tmp_table_size選項來增加臨時表的大小。也就是說，如果調高該值，MySQL同時將增加heap表的大小，可達到提高聯接查
詢速度的效果

read_buffer_size = 2M
# MySQL讀入緩沖區大小。對表進行順序掃描的請求將分配一個讀入緩沖區，MySQL會為它分配一段內存緩沖區。read_buffer_size變數控制這一緩沖區的大小。
# 如果對表的順序掃描請求非常頻繁，並且你認為頻繁掃描進行得太慢，可以通過增加該變數值以及內存緩沖區大小提高其性能

read_rnd_buffer_size = 8M
# MySQL的隨機讀緩沖區大小。當按任意順序讀取行時(例如，按照排序順序)，將分配一個隨機讀緩存區。進行排序查詢時，
# MySQL會首先掃描一遍該緩沖，以避免磁碟搜索，提高查詢速度，如果需要排序大量數據，可適當調高該值。但MySQL會為每個客戶連接發放該緩沖空間，所以應盡量適當設置該值，以避免內存開銷過大

sort_buffer_size = 8M
# MySQL執行排序使用的緩沖大小。如果想要增加ORDER BY的速度，首先看是否可以讓MySQL使用索引而不是額外的排序階段。
# 如果不能，可以嘗試增加sort_buffer_size變數的大小

join_buffer_size = 8M
# 聯合查詢操作所能使用的緩沖區大小，和sort_buffer_size一樣，該參數對應的分配內存也是每連接獨享

thread_cache_size = 8
# 這個值（默認8）表示可以重新利用保存在緩存中線程的數量，當斷開連接時如果緩存中還有空間，那麼客戶端的線程將被放到緩存中，
# 如果線程重新被請求，那麼請求將從緩存中讀取,如果緩存中是空的或者是新的請求，那麼這個線程將被重新創建,如果有很多新的線程，
# 增加這個值可以改善系統性能.通過比較Connections和Threads_created狀態的變數，可以看到這個變數的作用。(–>表示要調整的值)
# 根據物理內存設置規則如下：
# 1G —> 8
# 2G —> 16
# 3G —> 32
# 大於3G —> 64

query_cache_size = 8M
#MySQL的查詢緩沖大小（從4.0.1開始，MySQL提供了查詢緩沖機制）使用查詢緩沖，MySQL將SELECT語句和查詢結果存放在緩沖區中，
# 今後對於同樣的SELECT語句（區分大小寫），將直接從緩沖區中讀取結果。根據MySQL用戶手冊，使用查詢緩沖最多可以達到238%的效率。
# 通過檢查狀態值'Qcache_%'，可以知道query_cache_size設置是否合理：如果Qcache_lowmem_prunes的值非常大，則表明經常出現緩沖不夠的情況，
# 如果Qcache_hits的值也非常大，則表明查詢緩沖使用非常頻繁，此時需要增加緩沖大小；如果Qcache_hits的值不大，則表明你的查詢重復率很低，
# 這種情況下使用查詢緩沖反而會影響效率，那麼可以考慮不用查詢緩沖。此外，在SELECT語句中加入SQL_NO_CACHE可以明確表示不使用查詢緩沖

query_cache_limit = 2M
#指定單個查詢能夠使用的緩沖區大小，默認1M

key_buffer_size = 4M
#指定用於索引的緩沖區大小，增加它可得到更好處理的索引(對所有讀和多重寫)，到你能負擔得起那樣多。如果你使它太大，
# 系統將開始換頁並且真的變慢了。對於內存在4GB左右的伺服器該參數可設置為384M或512M。通過檢查狀態值Key_read_requests和Key_reads，
# 可以知道key_buffer_size設置是否合理。比例key_reads/key_read_requests應該盡可能的低，
# 至少是1:100，1:1000更好(上述狀態值可以使用SHOW STATUS LIKE 'key_read%'獲得)。注意：該參數值設置的過大反而會是伺服器整體效率降低

ft_min_word_len = 4
# 分詞詞彙最小長度，默認4

transaction_isolation = REPEATABLE-READ
# MySQL支持4種事務隔離級別，他們分別是：
# READ-UNCOMMITTED, READ-COMMITTED, REPEATABLE-READ, SERIALIZABLE.
# 如沒有指定，MySQL默認採用的是REPEATABLE-READ，ORACLE默認的是READ-COMMITTED

log_bin = mysql-bin
binlog_format = mixed
expire_logs_days = 30 #超過30天的binlog刪除

log_error = /data/mysql/mysql-error.log #錯誤日誌路徑
slow_query_log = 1
long_query_time = 1 #慢查詢時間 超過1秒則為慢查詢
slow_query_log_file = /data/mysql/mysql-slow.log

performance_schema = 0
explicit_defaults_for_timestamp

#lower_case_table_names = 1 #不區分大小寫

skip-external-locking #MySQL選項以避免外部鎖定。該選項默認開啟

default-storage-engine = InnoDB #默認存儲引擎

innodb_file_per_table = 1
# InnoDB為獨立表空間模式，每個資料庫的每個表都會生成一個數據空間
# 獨立表空間優點：
# 1．每個表都有自已獨立的表空間。
# 2．每個表的數據和索引都會存在自已的表空間中。
# 3．可以實現單表在不同的資料庫中移動。
# 4．空間可以回收（除drop table操作處，表空不能自已回收）
# 缺點：
# 單表增加過大，如超過100G
# 結論：
# 共享表空間在Insert操作上少有優勢。其它都沒獨立表空間表現好。當啟用獨立表空間時，請合理調整：innodb_open_files

innodb_open_files = 500
# 限制Innodb能打開的表的數據，如果庫里的表特別多的情況，請增加這個。這個值默認是300

innodb_buffer_pool_size = 64M
# InnoDB使用一個緩沖池來保存索引和原始數據, 不像MyISAM.
# 這里你設置越大,你在存取表裡面數據時所需要的磁碟I/O越少.
# 在一個獨立使用的資料庫伺服器上,你可以設置這個變數到伺服器物理內存大小的80%
# 不要設置過大,否則,由於物理內存的競爭可能導致操作系統的換頁顛簸.
# 注意在32位系統上你每個進程可能被限制在 2-3.5G 用戶層面內存限制,
# 所以不要設置的太高.

innodb_write_io_threads = 4
innodb_read_io_threads = 4
# innodb使用後台線程處理數據頁上的讀寫 I/O(輸入輸出)請求,根據你的 CPU 核數來更改,默認是4
# 注:這兩個參數不支持動態改變,需要把該參數加入到my.cnf里，修改完後重啟MySQL服務,允許值的范圍從 1-64

innodb_thread_concurrency = 0
# 默認設置為 0,表示不限制並發數，這里推薦設置為0，更好去發揮CPU多核處理能力，提高並發量

innodb_purge_threads = 1
# InnoDB中的清除操作是一類定期回收無用數據的操作。在之前的幾個版本中，清除操作是主線程的一部分，這意味著運行時它可能會堵塞其它的資料庫操作。
# 從MySQL5.5.X版本開始，該操作運行於獨立的線程中,並支持更多的並發數。用戶可通過設置innodb_purge_threads配置參數來選擇清除操作是否使用單
# 獨線程,默認情況下參數設置為0(不使用單獨線程),設置為 1 時表示使用單獨的清除線程。建議為1

innodb_flush_log_at_trx_commit = 2
# 0：如果innodb_flush_log_at_trx_commit的值為0,log buffer每秒就會被刷寫日誌文件到磁碟，提交事務的時候不做任何操作（執行是由mysql的master thread線程來執行的。
# 主線程中每秒會將重做日誌緩沖寫入磁碟的重做日誌文件(REDO LOG)中。不論事務是否已經提交）默認的日誌文件是ib_logfile0,ib_logfile1
# 1：當設為默認值1的時候，每次提交事務的時候，都會將log buffer刷寫到日誌。
# 2：如果設為2,每次提交事務都會寫日誌，但並不會執行刷的操作。每秒定時會刷到日誌文件。要注意的是，並不能保證100%每秒一定都會刷到磁碟，這要取決於進程的調度。
# 每次事務提交的時候將數據寫入事務日誌，而這里的寫入僅是調用了文件系統的寫入操作，而文件系統是有 緩存的，所以這個寫入並不能保證數據已經寫入到物理磁碟
# 默認值1是為了保證完整的ACID。當然，你可以將這個配置項設為1以外的值來換取更高的性能，但是在系統崩潰的時候，你將會丟失1秒的數據。
# 設為0的話，mysqld進程崩潰的時候，就會丟失最後1秒的事務。設為2,只有在操作系統崩潰或者斷電的時候才會丟失最後1秒的數據。InnoDB在做恢復的時候會忽略這個值。
# 總結
# 設為1當然是最安全的，但性能頁是最差的（相對其他兩個參數而言，但不是不能接受）。如果對數據一致性和完整性要求不高，完全可以設為2，如果只最求性能，例如高並發寫的日誌伺服器，設為0來獲得更高性能

innodb_log_buffer_size = 2M
# 此參數確定些日誌文件所用的內存大小，以M為單位。緩沖區更大能提高性能，但意外的故障將會丟失數據。MySQL開發人員建議設置為1－8M之間

innodb_log_file_size = 32M
# 此參數確定數據日誌文件的大小，更大的設置可以提高性能，但也會增加恢復故障資料庫所需的時間

innodb_log_files_in_group = 3
# 為提高性能，MySQL可以以循環方式將日誌文件寫到多個文件。推薦設置為3

innodb_max_dirty_pages_pct = 90
# innodb主線程刷新緩存池中的數據，使臟數據比例小於90%

innodb_lock_wait_timeout = 120
# InnoDB事務在被回滾之前可以等待一個鎖定的超時秒數。InnoDB在它自己的鎖定表中自動檢測事務死鎖並且回滾事務。InnoDB用LOCK TABLES語句注意到鎖定設置。默認值是50秒

bulk_insert_buffer_size = 8M
# 批量插入緩存大小， 這個參數是針對MyISAM存儲引擎來說的。適用於在一次性插入100-1000+條記錄時， 提高效率。默認值是8M。可以針對數據量的大小，翻倍增加。

myisam_sort_buffer_size = 8M
# MyISAM設置恢復表之時使用的緩沖區的尺寸，當在REPAIR TABLE或用CREATE INDEX創建索引或ALTER TABLE過程中排序 MyISAM索引分配的緩沖區

myisam_max_sort_file_size = 10G
# 如果臨時文件會變得超過索引，不要使用快速排序索引方法來創建一個索引。注釋：這個參數以位元組的形式給出

myisam_repair_threads = 1
# 如果該值大於1，在Repair by sorting過程中並行創建MyISAM表索引(每個索引在自己的線程內)

interactive_timeout = 28800
# 伺服器關閉互動式連接前等待活動的秒數。互動式客戶端定義為在mysql_real_connect()中使用CLIENT_INTERACTIVE選項的客戶端。默認值：28800秒（8小時）

wait_timeout = 28800
# 伺服器關閉非交互連接之前等待活動的秒數。在線程啟動時，根據全局wait_timeout值或全局interactive_timeout值初始化會話wait_timeout值，
# 取決於客戶端類型(由mysql_real_connect()的連接選項CLIENT_INTERACTIVE定義)。參數默認值：28800秒（8小時）
# MySQL伺服器所支持的最大連接數是有上限的，因為每個連接的建立都會消耗內存，因此我們希望客戶端在連接到MySQL Server處理完相應的操作後，
# 應該斷開連接並釋放佔用的內存。如果你的MySQL Server有大量的閑置連接，他們不僅會白白消耗內存，而且如果連接一直在累加而不斷開，
# 最終肯定會達到MySQL Server的連接上限數，這會報'too many connections'的錯誤。對於wait_timeout的值設定，應該根據系統的運行情況來判斷。
# 在系統運行一段時間後，可以通過show processlist命令查看當前系統的連接狀態，如果發現有大量的sleep狀態的連接進程，則說明該參數設置的過大，
# 可以進行適當的調整小些。要同時設置interactive_timeout和wait_timeout才會生效。

[mysqlmp]
quick
max_allowed_packet = 16M #伺服器發送和接受的最大包長度
[myisamchk]
key_buffer_size = 8M
sort_buffer_size = 8M
read_buffer = 4M
write_buffer = 4M

❷ mysql 設置緩存有什麼用

我們都知道 MySQL 的 Table Cache 是表定義的緩存，江湖上流傳著各種對這個參數的調優方法。
table cache 的作用，就是節約讀取表結構文件的開銷。對於table cache 是否命中，其實table cache 是針對於線程的，每個線程有自己的緩存，只緩存本線程的表結構定義。不過我們發現，strace 中沒有關於表結構文件的 open 操作（只有 stat 操作，定位表結構文件是否存在），也就是說 table cache 不命中，不一定需要讀取表結構文件。這種感覺好像是：在不命中 table cache 時，命中了另外一個表結構緩存。
運維建議：
我們讀一下 MySQL 的文檔，關於 table_open_cache 的建議值公式：建議值 = 最大並發數 * join 語句涉及的表的最大個數。
通過實驗我們容易理解：table_cache 是針對於線程的，所以需要最大並發數個緩存。另外，一個語句 join 涉及的表，需要同時在緩存中存在。所以最小的緩存大小，等於語句 join 涉及的表的最大個數。將這兩個數相乘，就得到了 MySQL 的建議值公式。

❸ mysql里的ini文件如何設置需要編輯嗎

這個mysql的運行配置參數文件。
如果你不是很了解mysql的話，先用默認的mysql.ini就可以，亂設置的話可能得不償失。
如果你想深入了解學習mysql的話，可以先找相關的資料，查查各個參數的含義，有助於你優化資料庫性能。

例如：
[mysqld]
port=3306 # mysql服務端默認監聽(listen on)的TCP/IP埠
basedir="C:/Program Files/MySQL/MySQL Server 5.5/" # 基準路徑，其他路徑都相對於這個路徑
datadir="C:/Program Files/MySQL/MySQL Server 5.5/Data" # mysql資料庫文件所在目錄
character-set-server=latin1 # 服務端使用的字元集默認為8比特編碼的latin1字元集
default-storage-engine=INNODB # 創建新表時將使用的默認存儲引擎
sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION" # SQL模式為strict模式
max_connections=100 # mysql伺服器支持的最大並發連接數（用戶數）。但總會預留其中的一個連接給管理員使用超級許可權登錄，即使連接數目達到最大限制。如果設置得過小而用戶比較多，會經常出現「Too many connections」錯誤。
query_cache_size=0 # 查詢緩存大小，用於緩存SELECT查詢結果。如果有許多返回相同查詢結果的SELECT查詢，並且很少改變表，可以設置query_cache_size大於0，可以極大改善查詢效率。而如果表數據頻繁變化，就不要使用這個，會適得其反
table_cache=256 # 這個參數在5.1.3之後的版本中叫做table_open_cache，用於設置table高速緩存的數量。由於每個客戶端連接都會至少訪問一個表，因此此參數的值與 max_connections有關。當某一連接訪問一個表時，MySQL會檢查當前已緩存表的數量。如果該表已經在緩存中打開，則會直接訪問緩存中的表已加快查詢速度；如果該表未被緩存，則會將當前的表添加進緩存並進行查詢。在執行緩存操作之前，table_cache用於限制緩存表的最大數目：如果當前已經緩存的表未達到table_cache，則會將新表添加進來；若已經達到此值，MySQL將根據緩存表的最後查詢時間、查詢率等規則釋放之前的緩存。
tmp_table_size=34M # 內存中的每個臨時表允許的最大大小。如果臨時表大小超過該值，臨時表將自動轉為基於磁碟的表（Disk Based Table）。
thread_cache_size=8 # 緩存的最大線程數。當客戶端連接斷開時，如果客戶端總連接數小於該值，則處理客戶端任務的線程放回緩存。在高並發情況下，如果該值設置得太小，就會有很多線程頻繁創建，線程創建的開銷會變大，查詢效率也會下降。一般來說如果在應用端有良好的多線程處理，這個參數對性能不會有太大的提高。
# MyISAM相關參數
myisam_max_sort_file_size=100G # mysql重建索引時允許使用的臨時文件最大大小
myisam_sort_buffer_size=68M
key_buffer_size=54M # Key Buffer大小，用於緩存MyISAM表的索引塊。決定資料庫索引處理的速度（尤其是索引讀）
read_buffer_size=64K # 用於對MyISAM表全表掃描時使用的緩沖區大小。針對每個線程進行分配（前提是進行了全表掃描）。進行排序查詢時，MySql會首先掃描一遍該緩沖，以避免磁碟搜索，提高查詢速度，如果需要排序大量數據，可適當調高該值。但MySql會為每個客戶連接發放該緩沖空間，所以應盡量適當設置該值，以避免內存開銷過大。
read_rnd_buffer_size=256K
sort_buffer_size=256K # connection級參數（為每個線程配置），500個線程將消耗500*256K的sort_buffer_size。
# InnoDB相關參數
innodb_additional_mem_pool_size=3M # InnoDB用於存儲元數據信息的內存池大小，一般不需修改
innodb_flush_log_at_trx_commit =1 # 事務相關參數，如果值為1，則InnoDB在每次commit都會將事務日誌寫入磁碟（磁碟IO消耗較大），這樣保證了完全的ACID特性。而如果設置為0，則表示事務日誌寫入內存log和內存log寫入磁碟的頻率都為1次/秒。如果設為2則表示事務日誌在每次commit都寫入內存log，但內存log寫入磁碟的頻率為1次/秒。
innodb_log_buffer_size=2M # InnoDB日誌數據緩沖大小，如果緩沖滿了，就會將緩沖中的日誌數據寫入磁碟（flush）。由於一般至少都1秒鍾會寫一次磁碟，所以沒必要設置過大，即使是長事務。
innodb_buffer_pool_size=105M # InnoDB使用緩沖池來緩存索引和行數據。該值設置的越大，則磁碟IO越少。一般將該值設為物理內存的80%。
innodb_log_file_size=53M # 每一個InnoDB事務日誌的大小。一般設為innodb_buffer_pool_size的25%到100%

innodb_thread_concurrency=9 # InnoDB內核最大並發線程數

❹ mysql連接數，緩存區大小，連接超時時間如何設置呢

mysql目錄下的 my.ini 可以修改 配置

max_connections=100 表示的是最大連接數
query_cache_size=0 表示查詢緩存的大小
table_cache=256 表示表格的緩存
tmp_table_size=18M 表示臨時表的緩存
thread_cache_size=8 表示線程的緩存

超時時間可以在連接字元串中寫好 下面給出了一個實例
Server=myServerAddress;Database=myDataBase;Uid=myUsername;Pwd=myPassword;default command timeout=20;
其他 連接字元串的實例給你一個連接
http://www.cnblogs.com/hcbin/archive/2010/05/04/1727071.html

❺ 如何使用redis做mysql的緩存

1，redis是一種內存性的數據存儲服務，所以它的速度要比mysql快。
2，redis只支持String,hashmap,set,sortedset等基本數據類型，但是不支持聯合查詢，所以它適合做緩存。
3，有時候緩存的數據量非常大，如果這個時候服務宕機了，且開啟了redis的持久化功能，重新啟動服務，數據基本上不會丟。
4，redis可以做內存共享，因為它可以被多個不同的客戶端連接。
5，做為mysql等資料庫的緩存，是把部分熱點數據先存儲到redis中，或第一次用的時候載入到redis中，下次再用的時候，直接從redis中取。
6，redis中的數據可以設置過期時間expire，如果這個數據在一定時間內沒有被延長這個時間，那個一定時間之後這個數據就會從redis清除。

所以，redis只是用來緩存資料庫中經常被訪問的數據，可以增加訪問速度和並發量。而mysql只是提供一種數據備份和數據源的作用。

❻ MYSQL會把查詢的結果緩存多久

設置好查詢緩存的大小就行了。比如設置個20MB. SET GLOBAL QUERY_CACHE_SIZE=20000000; mysql會將查詢SQL和結果集存到緩存中，等下次遇到相同的SQL語句時，結果集從緩存中讀齲 不設置就不用緩存了

❼ MySQL性能調優 – 你必須了解的15個重要變數

前言:

MYSQL 應該是最流行了 WEB 後端資料庫。雖然 NOSQL 最近越來越多的被提到，但是相信大部分架構師還是會選擇 MYSQL 來做數據存儲。本文作者總結梳理MySQL性能調優的15個重要變數，又不足需要補充的還望大佬指出。

1.DEFAULT_STORAGE_ENGINE

如果你已經在用MySQL 5.6或者5.7，並且你的數據表都是InnoDB，那麼表示你已經設置好了。如果沒有，確保把你的表轉換為InnoDB並且設置default_storage_engine為InnoDB。

為什麼？簡而言之，因為InnoDB是MySQL(包括Percona Server和MariaDB)最好的存儲引擎 – 它支持事務，高並發，有著非常好的性能表現(當配置正確時)。這里有詳細的版本介紹為什麼

2.INNODB_BUFFER_POOL_SIZE

這個是InnoDB最重要變數。實際上，如果你的主要存儲引擎是InnoDB，那麼對於你，這個變數對於MySQL是最重要的。

基本上，innodb_buffer_pool_size指定了MySQL應該分配給InnoDB緩沖池多少內存，InnoDB緩沖池用來存儲緩存的數據，二級索引，臟數據(已經被更改但沒有刷新到硬碟的數據)以及各種內部結構如自適應哈希索引。

根據經驗，在一個獨立的MySQL伺服器應該分配給MySQL整個機器總內存的80%。如果你的MySQL運行在一個共享伺服器，或者你想知道InnoDB緩沖池大小是否正確設置，詳細請看這里。

3.INNODB_LOG_FILE_SIZE

InnoDB重做日誌文件的設置在MySQL社區也叫做事務日誌。直到MySQL 5.6.8事務日誌默認值innodb_log_file_size=5M是唯一最大的InnoDB性能殺手。從MySQL 5.6.8開始，默認值提升到48M,但對於許多稍繁忙的系統，還遠遠要低。

根據經驗，你應該設置的日誌大小能在你伺服器繁忙時能存儲1-2小時的寫入量。如果不想這么麻煩，那麼設置1-2G的大小會讓你的性能有一個不錯的表現。這個變數也相當重要，更詳細的介紹請看這里。

當然，如果你有大量的大事務更改，那麼，更改比默認innodb日誌緩沖大小更大的值會對你的性能有一定的提高，但是你使用的是autocommit，或者你的事務更改小於幾k，那還是保持默認的值吧。

4.INNODB_FLUSH_LOG_AT_TRX_COMMIT

默認下，innodb_flush_log_at_trx_commit設置為1表示InnoDB在每次事務提交後立即刷新同步數據到硬碟。如果你使用autocommit，那麼你的每一個INSERT, UPDATE或DELETE語句都是一個事務提交。

同步是一個昂貴的操作(特別是當你沒有寫回緩存時)，因為它涉及對硬碟的實際同步物理寫入。所以如果可能，並不建議使用默認值。

兩個可選的值是0和2:

* 0表示刷新到硬碟，但不同步(提交事務時沒有實際的IO操作)

* 2表示不刷新和不同步(也沒有實際的IO操作)

所以你如果設置它為0或2，則同步操作每秒執行一次。所以明顯的缺點是你可能會丟失上一秒的提交數據。具體來說，你的事務已經提交了，但伺服器馬上斷電了，那麼你的提交相當於沒有發生過。

顯示的，對於金融機構，如銀行，這是無法忍受的。不過對於大多數網站，可以設置為innodb_flush_log_at_trx_commit=0|2，即使伺服器最終崩潰也沒有什麼大問題。畢竟，僅僅在幾年前有許多網站還是用MyISAM，當崩潰時會丟失30s的數據(更不要提那令人抓狂的慢修復進程)。

那麼，0和2之間的實際區別是什麼？性能明顯的差異是可以忽略不計，因為刷新到操作系統緩存的操作是非常快的。所以很明顯應該設置為0，萬一MySQL崩潰(不是整個機器)，你不會丟失任何數據，因為數據已經在OS緩存，最終還是會同步到硬碟的。

5.SYNC_BINLOG

已經有大量的文檔寫到sync_binlog，以及它和innodb_flush_log_at_trx_commit的關系，下面我們來簡單的介紹下：

a) 如果你的伺服器沒有設置從伺服器，而且你不做備份，那麼設置sync_binlog=0將對性能有好處。

b) 如果你有從伺服器並且做備份，但你不介意當主伺服器崩潰時在二進制日誌丟失一些事件，那麼為了更好的性能還是設置為sync_binlog=0.

c) 如果你有從伺服器並且備份，你非常在意從伺服器的一致性，以及能及時恢復到一個時間點(通過使用最新的一致性備份和二進制日誌將資料庫恢復到特定時間點的能力)，那麼你應該設置innodb_flush_log_at_trx_commit=1，並且需要認真考慮使用sync_binlog=1。

問題是sync_binlog=1代價比較高 – 現在每個事務也要同步一次到硬碟。你可能會想為什麼不把兩次同步合並成一次，想法正確 – 新版本的MySQL(5.6和5.7，MariaDB和Percona Server)已經能合並提交，那麼在這種情況下sync_binlog=1的操作也不是這么昂貴了，但在舊的mysql版本中仍然會對性能有很大影響。

6.INNODB_FLUSH_METHOD

將innodb_flush_method設置為O_DIRECT以避免雙重緩沖.唯一一種情況你不應該使用O_DIRECT是當你操作系統不支持時。但如果你運行的是Linux，使用O_DIRECT來激活直接IO。

不用直接IO，雙重緩沖將會發生，因為所有的資料庫更改首先會寫入到OS緩存然後才同步到硬碟 – 所以InnoDB緩沖池和OS緩存會同時持有一份相同的數據。特別是如果你的緩沖池限制為總內存的50%，那意味著在寫密集的環境中你可能會浪費高達50%的內存。如果沒有限制為50%，伺服器可能由於OS緩存的高壓力會使用到swap。

簡單地說，設置為innodb_flush_method=O_DIRECT。

7.INNODB_BUFFER_POOL_INSTANCES

MySQL 5.5引入了緩沖實例作為減小內部鎖爭用來提高MySQL吞吐量的手段。

在5.5版本這個對提升吞吐量幫助很小，然後在MySQL 5.6版本這個提升就非常大了，所以在MySQL5.5中你可能會保守地設置innodb_buffer_pool_instances=4，在MySQL 5.6和5.7中你可以設置為8-16個緩沖池實例。

你設置後觀察會覺得性能提高不大，但在大多數高負載情況下，它應該會有不錯的表現。

對了，不要指望這個設置能減少你單個查詢的響應時間。這個是在高並發負載的伺服器上才看得出區別。比如多個線程同時做許多事情。

8.INNODB_THREAD_CONCURRENCY

InnoDB有一種方法來控制並行執行的線程數 – 我們稱為並發控制機制。大部分是由innodb_thread_concurrency值來控制的。如果設置為0，並發控制就關閉了，因此InnoDB會立即處理所有進來的請求(盡可能多的)。

在你有32CPU核心且只有4個請求時會沒什麼問題。不過想像下你只有4CPU核心和32個請求時 – 如果你讓32個請求同時處理，你這個自找麻煩。因為這些32個請求只有4 CPU核心，顯然地會比平常慢至少8倍(實際上是大於8倍)，而然這些請求每個都有自己的外部和內部鎖，這有很大可能堆積請求。

下面介紹如何更改這個變數，在mysql命令行提示符執行：

對於大多數工作負載和伺服器，設置為8是一個好開端，然後你可以根據伺服器達到了這個限制而資源使用率利用不足時逐漸增加。可以通過show engine innodb statusG來查看目前查詢處理情況，查找類似如下行：

9.SKIP_NAME_RESOLVE

這一項不得不提及，因為仍然有很多人沒有添加這一項。你應該添加skip_name_resolve來避免連接時DNS解析。

大多數情況下你更改這個會沒有什麼感覺，因為大多數情況下DNS伺服器解析會非常快。不過當DNS伺服器失敗時，它會出現在你伺服器上出現「unauthenticated connections」 ，而就是為什麼所有的請求都突然開始慢下來了。

所以不要等到這種事情發生才更改。現在添加這個變數並且避免基於主機名的授權。

10.INNODB_IO_CAPACITY, INNODB_IO_CAPACITY_MAX

* innodb_io_capacity：用來當刷新臟數據時，控制MySQL每秒執行的寫IO量。

* innodb_io_capacity_max: 在壓力下，控制當刷新臟數據時MySQL每秒執行的寫IO量

首先，這與讀取無關 – SELECT查詢執行的操作。對於讀操作，MySQL會盡最大可能處理並返回結果。至於寫操作，MySQL在後台會循環刷新，在每一個循環會檢查有多少數據需要刷新，並且不會用超過innodb_io_capacity指定的數來做刷新操作。這也包括更改緩沖區合並（在它們刷新到磁碟之前，更改緩沖區是輔助臟頁存儲的關鍵）。

第二，我需要解釋一下什麼叫「在壓力下」，MySQL中稱為」緊急情況」，是當MySQL在後台刷新時，它需要刷新一些數據為了讓新的寫操作進來。然後，MySQL會用到innodb_io_capacity_max。

那麼，應該設置innodb_io_capacity和innodb_io_capacity_max為什麼呢？

最好的方法是測量你的存儲設置的隨機寫吞吐量，然後給innodb_io_capacity_max設置為你的設備能達到的最大IOPS。innodb_io_capacity就設置為它的50-75%，特別是你的系統主要是寫操作時。

通常你可以預測你的系統的IOPS是多少。例如由8 15k硬碟組成的RAID10能做大約每秒1000隨機寫操作，所以你可以設置innodb_io_capacity=600和innodb_io_capacity_max=1000。許多廉價企業SSD可以做4,000-10,000 IOPS等。

這個值設置得不完美問題不大。但是，要注意默認的200和400會限制你的寫吞吐量，因此你可能偶爾會捕捉到刷新進程。如果出現這種情況，可能是已經達到你硬碟的寫IO吞吐量，或者這個值設置得太小限制了吞吐量。

11.INNODB_STATS_ON_METADATA

如果你跑的是MySQL 5.6或5.7，你不需要更改innodb_stats_on_metadata的默認值，因為它已經設置正確了。

不過在MySQL 5.5或5.1，強烈建議關閉這個變數 – 如果是開啟，像命令show table status會立即查詢INFORMATION_SCHEMA而不是等幾秒再執行，這會使用到額外的IO操作。

從5.1.32版本開始，這個是動態變數，意味著你不需要重啟MySQL伺服器來關閉它。

12.INNODB_BUFFER_POOL_DUMP_AT_SHUTDOWN & INNODB_BUFFER_POOL_LOAD_AT_STARTUP

innodb_buffer_pool_mp_at_shutdown和innodb_buffer_pool_load_at_startup這兩個變數與性能無關，不過如果你偶爾重啟mysql伺服器(如生效配置)，那麼就有關。當兩個都激活時，MySQL緩沖池的內容(更具體地說，是緩存頁)在停止MySQL時存儲到一個文件。當你下次啟動MySQL時，它會在後台啟動一個線程來載入緩沖池的內容以提高預熱速度到3-5倍。

兩件事：

第一，它實際上沒有在關閉時復制緩沖池內容到文件，僅僅是復製表空間ID和頁面ID – 足夠的信息來定位硬碟上的頁面了。然後它就能以大量的順序讀非常快速的載入那些頁面，而不是需要成千上萬的小隨機讀。

第二，啟動時是在後台載入內容，因為MySQL不需要等到緩沖池內容載入完成再開始接受請求(所以看起來不會有什麼影響)。

從MySQL 5.7.7開始，默認只有25%的緩沖池頁面在mysql關閉時存儲到文件，但是你可以控制這個值 – 使用innodb_buffer_pool_mp_pct，建議75-100。

這個特性從MySQL 5.6才開始支持。

13.INNODB_ADAPTIVE_HASH_INDEX_PARTS

如果你運行著一個大量SELECT查詢的MySQL伺服器(並且已經盡可能優化)，那麼自適應哈希索引將下你的下一個瓶頸。自適應哈希索引是InnoDB內部維護的動態索引，可以提高最常用的查詢模式的性能。這個特性可以重啟伺服器關閉，不過默認下在mysql的所有版本開啟。

這個技術非常復雜，在大多數情況下它會對大多數類型的查詢直到加速的作用。不過，當你有太多的查詢往資料庫，在某一個點上它會花過多的時間等待AHI鎖和閂鎖。

如果你的是MySQL 5.7，沒有這個問題 – innodb_adaptive_hash_index_parts默認設置為8，所以自適應哈希索引被切割為8個分區，因為不存在全局互斥。

不過在mysql 5.7前的版本，沒有AHI分區數量的控制。換句話說，有一個全局互斥鎖來保護AHI，可能導致你的select查詢經常撞牆。

所以如果你運行的是5.1或5.6，並且有大量的select查詢，最簡單的方案就是切換成同一版本的Percona Server來激活AHI分區。

14.QUERY_CACHE_TYPE

如果人認為查詢緩存效果很好，肯定應該使用它。好吧，有時候是有用的。不過這個只在你在低負載時有用，特別是在低負載下大多數是讀取，小量寫或者沒有。

如果是那樣的情況，設置query_cache_type=ON和query_cache_size=256M就好了。不過記住不能把256M設置更高的值了，否則會由於查詢緩存失效時，導致引起嚴重的伺服器停頓。

如果你的MySQL伺服器高負載動作，建議設置query_cache_size=0和query_cache_type=OFF，並重啟伺服器生效。那樣Mysql就會停止在所有的查詢使用查詢緩存互斥鎖。

15.TABLE_OPEN_CACHE_INSTANCES

從MySQL 5.6.6開始，表緩存能分割到多個分區。

表緩存用來存放目前已打開表的列表，當每一個表打開或關閉互斥體就被鎖定 – 即使這是一個隱式臨時表。使用多個分區絕對減少了潛在的爭用。

從MySQL 5.7.8開始，table_open_cache_instances=16是默認的配置。

歡迎做Java的工程師朋友們私信我資料免費獲取免費的Java架構學習資料（裡面有高可用、高並發、高性能及分布式、Jvm性能調優、Spring源碼，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料）

其中覆蓋了互聯網的方方面面，期間碰到各種產品各種場景下的各種問題，很值得大家借鑒和學習，擴展自己的技術廣度和知識面。

❽ mysql緩存如何使用

設置好查詢緩存的大小就行了。比如設置個20MB.
SET GLOBAL QUERY_CACHE_SIZE=20000000;
mysql會將查詢SQL和結果集存到緩存中，等下次遇到相同的SQL語句時，結果集從緩存中讀取。

❾ MySQL怎麼禁止使用緩存以及復雜多表查詢的索引優化問題

1、query_cache_size=0 已經禁用了查詢緩存，但表數據可能緩存了，flush tables試試，不過操作系統還有一個硬碟緩存，想跟第一次查詢之前的狀態一致恐怕只能每次重啟
2、group by與order by不會用索引的，索引最大的用處就是減小磁碟IO，也就是where時盡量少磁碟IO並讀出所有滿足條件的記錄