溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本文主要給大家介紹Percona Server、MariaDB、MYSQL應該如何選擇，文章內容都是筆者用心摘選和編輯的，Percona Server、MariaDB、MYSQL應該如何選擇具有一定的針對性，對大家的參考意義還是比較大的，下面跟筆者一起了解下主題內容吧。
1、Mysql三種存儲引擎
MySQL提供了兩種存儲引擎：MyISAM和 InnoDB，MySQL4和5使用默認的MyISAM存儲引擎。從MYSQL5.5開始，MySQL已將默認存儲引擎從MyISAM更改為InnoDB。
MyISAM沒有提供事務支持，而InnoDB提供了事務支持。
XtraDB是InnoDB存儲引擎的增強版本，被設計用來更好的使用更新計算機硬件系統的性能，同時還包含有一些在高性能環境下的新特性。
2、Percona Server分支
Percona Server由領先的MySQL咨詢公司Percona發布。
Percona Server是一款獨立的數據庫產品，其可以完全與MySQL兼容，可以在不更改代碼的情況了下將存儲引擎更換成XtraDB。是最接近官方MySQL Enterprise發行版的版本。
Percona提供了高性能XtraDB引擎，還提供PXC高可用解決方案，并且附帶了percona-toolkit等DBA管理工具箱，
3、MariaDB
MariaDB由MySQL的創始人開發，MariaDB的目的是完全兼容MySQL，包括API和命令行，使之能輕松成為MySQL的代替品。
MariaDB提供了MySQL提供的標準存儲引擎，即MyISAM和InnoDB，10.0.9版起使用XtraDB（名稱代號為Aria）來代替MySQL的InnoDB。
4、如何選擇
綜合多年使用經驗和性能對比，首選Percona分支，其次是MariaDB，如果你不想冒一點風險，那就選擇MYSQL官方版本。
二、常用的MYSQL調優策略
1、硬件層相關優化
修改云服務器BIOS設置
選擇Performance Per Watt Optimized(DAPC)模式，發揮CPU最大性能。
Memory Frequency（內存頻率）選擇Maximum Performance（最佳性能）
內存設置菜單中，啟用Node Interleaving，避免NUMA問題
2、磁盤I/O相關
使用SSD硬盤
如果是磁盤陣列存儲，建議陣列卡同時配備CACHE及BBU模塊，可明顯提升IOPS。
raid級別盡量選擇raid10，而不是raid5.
3、文件系統層優化
使用deadline/noop這兩種I/O調度器，千萬別用cfq
使用xfs文件系統，千萬別用ext3；ext4勉強可用，但業務量很大的話，則一定要用xfs；
文件系統mount參數中增加：noatime, nodiratime, nobarrier幾個選項（nobarrier是xfs文件系統特有的）；
4、內核參數優化
修改vm.swappiness參數，降低swap使用率。RHEL7/centos7以上則慎重設置為0，可能發生OOM
調整vm.dirty_background_ratio、vm.dirty_ratio內核參數，以確保能持續將臟數據刷新到磁盤，避免瞬間I/O寫。產生等待。
調整net.ipv4.tcp_tw_recycle、net.ipv4.tcp_tw_reuse都設置為1，減少TIME_WAIT，提高TCP效率。
5、Mysql參數優化建議
建議設置default-storage-engine=InnoDB，強烈建議不要再使用MyISAM引擎。
調整innodb_buffer_pool_size的大小，如果是單實例且絕大多數是InnoDB引擎表的話，可考慮設置為物理內存的50% -70%左右。
設置innodb_file_per_table = 1，使用獨立表空間。
調整innodb_data_file_path = ibdata1:1G:autoextend，不要用默認的10M,在高并發場景下，性能會有很大提升。
設置innodb_log_file_size=256M，設置innodb_log_files_in_group=2，基本可以滿足大多數應用場景。
調整max_connection（最大連接數）、max_connection_error（最大錯誤數）設置，根據業務量大小進行設置。
另外，open_files_limit、innodb_open_files、table_open_cache、table_definition_cache可以設置大約為max_connection的10倍左右大小。
key_buffer_size建議調小，32M左右即可，另外建議關閉query cache。
mp_table_size和max_heap_table_size設置不要過大，另外sort_buffer_size、join_buffer_size、read_buffer_size、read_rnd_buffer_size等設置也不要過大。
這是MySQL自身提供的一種高可用解決方案，數據同步方法采用的是MySQL replication技術。MySQL replication就是從云服務器到主云服務器拉取二進制日志文件，然后再將日志文件解析成相應的SQL在從云服務器上重新執行一遍主云服務器的操作，通過這種方式保證數據的一致性。
為了達到更高的可用性，在實際的應用環境中，一般都是采用MySQL replication技術配合高可用集群軟件keepalived來實現自動failover，這種方式可以實現95.000%的SLA。
MMM提供了MySQL主主復制配置的監控、故障轉移和管理的一套可伸縮的腳本套件。在MMM高可用方案中，典型的應用是雙主多從架構，通過MySQL replication技術可以實現兩個云服務器互為主從，且在任何時候只有一個節點可以被寫入，避免了多點寫入的數據沖突。同時，當可寫的主節點故障時，MMM套件可以立刻監控到，然后將服務自動切換到另一個主節點，繼續提供服務，從而實現MySQL的高可用。
3，在這個方案中，處理failover的方式是高可用集群軟件Heartbeat，它監控和管理各個節點間連接的網絡，并監控集群服務，當節點出現故障或者服務不可用時，自動在其他節點啟動集群服務。在數據共享方面，通過SAN（Storage Area Network）存儲來共享數據，這種方案可以實現99.990%的SLA。
此方案處理failover的方式上依舊采用Heartbeat，不同的是，在數據共享方面，采用了基于塊級別的數據同步軟件DRBD來實現。
DRBD是一個用軟件實現的、無共享的、云服務器之間鏡像塊設備內容的存儲復制解決方案。和SAN網絡不同，它并不共享存儲，而是通過云服務器之間的網絡復制數據。
其中：
Dbm157是mysql主，dbm158是mysql主的備機，dbs159/160/161是mysql從。
MySQL寫操作一般采用基于heartbeat+DRBD+MySQL搭建高可用集群的方案。通過heartbeat實現對mysql主進行狀態監測，而DRBD實現dbm157數據同步到dbm158。
讀操作普遍采用基于LVS+Keepalived搭建高可用高擴展集群的方案。前端AS應用通過提高的讀VIP連接LVS，LVS有keepliaved做成高可用模式，實現互備。
最后，mysql主的從節點dbs159/160/161通過mysql主從復制功能同步mysql主的數據，通過lvs功能提供給前端AS應用進行讀操作，并實現負載均衡。
(二）mysql常用配置的解釋。
skip-external-locking
在某些系統中，lockd鎖管理器可能不能正常工作，可以使用skip-external-locking告訴mysqld不使用外部鎖定。（這意味著你不能在同一個數據目錄運行兩個mysqld云服務器，而且如果你使用相同內存配置，也需要特別注意）
在Mysql4.0版本之后，外部鎖定默認是禁用的，而啟用外部鎖定（系統鎖定），如果系統上的lockd不能完全工作（比如Linux系統），很容易造成mysqld死鎖。
明確的禁用外部鎖定，可以通過配置skip-external-locking。 外部鎖定只影響存儲引擎為MyISAM表的訪問。
key_buffer_size = 16M
這個參數的含義是：MyISAM表用于索引塊的緩沖區大小，可以被所有線程所共享，默認值是8388608（即8M），它是對MyISAM表性能影響最大的一個參數，如果數據庫存儲引擎為InnoDB類型，這個參數是無效的。可以通過增大這個值，以便索引更好的處理所有讀和多寫操作。
這里有兩篇相關的文章值得參閱： mysql優化：Key_buffer_size MySQL的key_buffer_size參數
max_allowed_packet = 1M
表示一個數據包的最大大小，或任何生成的/中間字符串，或任何mysql_stmt_send_long_data() API 函數傳遞的參數。數據包消息的緩沖區被初始化為net_buffer_length的字節（net_buffer_length默認值為16384：16KB，最大可以設置為1048576：1M），但是在需要的時候可以增長到max_allowed_packet字節，這個參數的默認值是4M，在接收一些大的數據包時可能會出現錯誤，最大可以設置為1GB。當你通過修改這個變量的值更改消息緩沖區的大小時，如果客戶端程序允許的話，建議在客戶端也修改緩沖區的大小。在客戶端庫，默認的max_allowed_packet是1GB，但是個人的客戶端可能會重寫這個值，例如，mysql和mysqldump分別是16 MB和24 MB。可以通過在命令行設置或在配置文件中修改max_allowed_packet參數來更改客戶端的值，需要注意的是：在session會話級別中，這個變量是只讀的。
table_open_cache = 64
表示所有線程打開表的數量，增加該值會增加mysqld要求的文件描述符的數量？你可以通過檢查Opened_tables狀態變量來確定是否需要增加表緩存數量（Opened_tables表示已打開的表的數量）。如果這個值很大，你又不經常使用FLUSH TABLES（這個命令會強制關閉并重新打開所有表），可以增加table_open_cache的值。
table_open_cache和max_connections系統變量影響文件云服務器保持打開的最大數量。如果你增加了其中一個或兩個值，可能會超過操作系統上每個進程打開的文件描述符的數量限制。許多的操作系統允許你增加這個限制，但是也需要確定操作系統是否有可能增加打開文件的限制，以及如何去做。
table_open_cache的值與max_connections的值存在關系。例如，對于200個并發運行的連接，指定table_open_cache的值 至少為200 * N，其中 N是 任何參與 執行 查詢的連接中關聯 表的最大 數量。你還必須為臨時表和文件保留一些額外的文件描述符。
請確保你的操作系統能夠處理由table_open_cache設置的隱含打開的文件描述符的數量。如果table_open_cache值設置的太高，MYSQL可能使用完文件描述符而拒絕連接，不能執行查詢，并會變的不可靠。還必須需要考慮的是，MyISAM存儲引擎中，每個唯一打開的表都需要兩個文件描述符。你可以通過在mysqld的啟動選項中配置open-files-limit參數，來增加MySQL可用的文件描述符的數量。
sort_buffer_size = 512K
表示為每一個需要排序的會話分配一個指定的緩存區大小。sort_buffer_size的值不特定于任何存儲引擎，它適用于對優化的一般方式。通過SHOW GLOBAL STATUS命令，如果你發現每秒鐘有許多的Sort_merge_passes輸出（Sort_merge_passes表示不得不做合并排序算法的數量），我們就需要考慮增加sort_buffer_size的值，以加快order by 或 group by 等操作的查詢性能（order by和group by的查詢效率很難通過優化查詢和改善索引提供效率）。
優化器會嘗試找出有多少空間是必要的，但可以分配更多，直到達到極限。值得注意的是：如果全局的設置，大于系統所需要的值，將減緩大部分涉及排序的查詢效率。最好在session會話級別增加它的值，而且值針對那些需要增加sort_buffer_size的session會話。在Linux系統中，有256KB和2MB的閾值，其中較大的值可能顯著減慢內存分配，所以你應該考慮那些較小的值。
net_buffer_length = 8K
每個客戶端線程都與一個connection連接緩沖區和結果緩沖區相關聯，默認值是16K。兩者最初的大小都是net_buffer_length，但是根據需要會動態的擴大到max_allowed_packet設置的大小，結果緩沖區在每一個sql語句執行后都會縮小到設置的net_buffer_length。
這個變量通常不應該改變，但是如果你的系統內存很小，你可以將其設置為客戶端語句的期望長度。如果語句的長度超過這個值，connection連接緩沖區會自動的擴大。net_buffer_length參數的最大值可以設置到1M。需要注意的是：在session會話級別中，這個變量是只讀的。
read_buffer_size = 256K
進行順序掃描的MyISAM表的 每個線程，都為它掃描的每個表分配一個指定大小的緩沖區。如果需要做很多的順序掃描，你可能會增大這個值，默認值為131072（128K）。這個變量的值應該是4KB的倍數。如果它被設置為不是4KB的倍數，它的值將被舍入為4KB的最近倍數。
該參數在以下情況時適用于所有的搜索引擎：
緩存索引在一個臨時文件（而不是臨時表），使用ORDER BY進行行排序時。
進行分區批量插入操作時。
對于嵌套查詢緩存結果。
如果使用 另外一個存儲引擎，需要為MEMORY表確定內存塊大小。 read_buffer_size 最大允許 設置為 2GB 。
read_rnd_buffer_size = 512K
此變量用于多范圍讀取優化，包括MyISAM表以及任何存儲引擎。當從一個有排序操作的MyISAM表的一個關鍵分揀操作中讀取行，該行通過該緩沖區讀取，以避免磁盤尋道。設置這個值為較大的值可以顯著的提高ORDER BY操作的性能， 然而，這是分配給每一個客戶端的緩沖區，所以不應該在全局級別將其設置為一個較大的值。相反，只有在需要進行大量查詢操作的客戶端才建議在session會話級別增大這個變量值。read_rnd_buffer_size最大允許設置為2GB。
myisam_sort_buffer_size = 8M
表示在REPAIR TABLE上進行MyISAM索引排序時，或通過CREATE INDEX、ALTER TABLE創建索引時，分配的緩沖區大小。相應的，對于InnoDB引擎，有InnoDB_sort_buffer_size的設置。
query_cache_size= 8M
表示分配給高速緩存查詢結果的內存量。默認情況下，查詢緩存是禁用的。這是通過使用默認的query_cache_size為 1M，query_cache_type為0（為0表示不啟用查詢緩存）使用的，這樣做會顯著降低開銷，因為如果你設置了query_cache_size為0，你也需要在啟動時設置query_cache_type為0。
允許設置的值為1024的倍數，其他設置的值會四舍五入到最近的那個值。 需要 注意的是，即使query_cache_type設置為0，query_cache_size字節的內存也會被默認的分配。
查詢緩存需要一個最小大小約40 kb的分配結構（具體的值取決于系統結構）。如果設置的query_cache_size太小，還可能會產生一些問題。
query_cache_type的值有0、1、2三種，0表示不進行任何查詢緩存；1表示 緩存所有可緩存的查詢結果除了那些以SELECT SQL_NO_CACHE開頭的查詢；2表示只緩存以SELECT SQL_CACHE開頭的查詢結果。mysql官方doc建議設置為2。
thread_cache_size = 20
表示云服務器將會緩存重用的線程數量，當一個客戶端斷開連接，如果緩存中線程的數量小于設置的thread_cache_size，那么這個客戶端的線程會變放入到緩存中。請求的線程如果可能的話，會從高速緩存中去的線程，當緩存為空時，才會創建新的線程。如果系統中存在許多新的連接的話，增加這個變量值可以提高性能。通常情況下，如果你的代碼中很好的做了線程實現，這種性能改進并不顯著。然而，如果你的云服務器每秒有數百個連接，你通常應該設置thread_cache_size足夠高，大多數新連接都會使用緩存的線程。通過比較這個變量與Connections（表示嘗試連接到Mysql云服務器的數量（無論是否連接成功））和Threads_created（表示處理connection連接所創建的線程的數量）狀態變量之間的區別，你可以看到線程緩存的高效。
這個變量的默認值是根據以下公式計算的，封頂為100：8 + (max_connections / 100)，但是在嵌入式云服務器（libmysqld）這個變量是沒有效果的，在MySQL 5.7.2版本之后，這個參數也不再可見。
log-bin=mysql-bin
表示啟用二進制日志記錄，云服務器記錄了所有改變數據語句的二進制日志，用于備份和復制。
binlog_format=mixed 之前 MySQL中事務隔離級別與binlog_format的一點理解中學習，這里不再贅述。
innodb_flush_log_at_trx_commit = 2
這個變量的官方定義是：Controls the balance between strict ACID compliance for commit operations，and higher performance that is possible when commit-related I/O operations are rearranged and done in batches。我自己的理解是用于控制兩種關系之間的平衡，這兩種關系：提交操作嚴格的ACID特性，提交相關的IO操作被分批的重新排列和完成時可能帶來的高性能。你可以通過修改這個變量的默認值達到更好的性能，但是你可能會在意外崩潰時丟失一秒的事務。
默認值為 1 完全符合數據庫ACID特性，這個值表示，在每次事務提交的時候，InnoDB日志緩沖區的內容都會被寫入到日志文件，并且日志文件會被刷新到磁盤。
如果變量值為0，則表示InnoDB日志緩沖區的內容大約每秒被寫入日志文件一次，并且日志文件會被刷新到磁盤。那些日志緩沖區中沒有寫入的內容會在事務提交的時候被寫入日志文件。由于進程調度的問題，每秒的刷新并不能100%保證每一秒都發生。由于刷新磁盤的操作只有大約每秒才發生一次，所以在任何mysqld進程崩潰的時候，你都會喪失一秒的事務。
如果變量值為2，則表示InnoDB日志緩沖區的內容會在事務提交的時候寫入到日志文件，并且日志文件會大約每秒刷新一次磁盤。同樣的，由于進程調度的問題，每秒的刷新并不能100%保證每一秒都發生。由于刷新磁盤的操作只有大約每秒才發生一次，所以在操作系統崩潰或突然斷電的時候，你都會喪失一秒的事務數據。
在MySQL 5.6.6版本中，InnoDB日志刷新頻率由變量innodb_flush_log_at_timeout,控制，它允許你將日志刷新頻率設置為N秒（默認值是1，可以設置1到2700之間的整數值），但是任何mysqld進程的崩潰都會清除高達N秒的事務數據。
DDL變化和其他內部InnoDB的活動，則是獨立的innodb_flush_log_at_trx_commit設置進行InnoDB日志刷新。
InnoDB的崩潰恢復機制是不管變量innodb_flush_log_at_trx_commit的設置的，事務要么全部應用，要么全部刪除。
根據數據庫應用設置的持久性和一致性，建議參考如下方式進行InnoDB事務設置：
如果啟用了二進制日志，設置sync_binlog=1。
總是設置innodb_flush_log_at_trx_commit=1。
這么建議的原因是：許多操作系統和一些磁盤硬件愚弄刷新到磁盤的操作，他們可能會告訴mysqld：刷新操作已經發生，但是事實上并沒有發生。然后事務的持久性即使設置為1，也不能得到保證。在最糟糕的情況突然斷電甚至會造成InnoDB數據的損壞。在SCSI磁盤控制器或本身加速文件刷新的磁盤上使用電池支持的磁盤緩存，會使操作更安全。你也可以嘗試使用Unix命令hdparm禁用磁盤寫入緩存的硬件高速緩存，或使用特定的硬件供應商提供的其他一些命令。
sync_binlog
如果這個變量的值大于0，MySQL云服務器會在sync_binlog提交組被寫入到二進制日志之后，使用fdatasync()命令同步二進制日志到磁盤。默認的sync_binlog變量值為0，表示不同步到磁盤。mysql云服務器依賴于操作系統不時的刷新二進制文件的內容，用于任何其他文件。值為1是最安全的選擇，因為在崩潰的情況下你最多從二進制日志丟失一個提交組。然而，它也是最慢的選擇（除非你你的磁盤具有電池備份緩存，這會使得同步非常快）。
innodb_lock_wait_timeout = 20
表示InnoDB事務從等待獲取行鎖到放棄的時間長度，默認的值為50秒。一個事務試圖獲取被另一個InnoDB事務鎖定的行所等待的最大時間，超時時會發出以下錯誤信息：
ERROR 1205 (HY000)： Lock wait timeout exceeded； try restarting transaction（鎖等待超時，試圖重啟事務）
當鎖等待超時后，當前的語句會回滾（并不是整個事務回滾）。如果需要整個事務都回滾，需要在云服務器啟動時通過innodb_rollback_on_timeout參數設置。
在高度交互的應用程序或OTLP系統中，為了更好的用戶反饋或將更新放入一個隊列等待后續處理，你可能會減小該變量值。對于長期運行的后端操作，比如在一個數據倉庫中存在大批量的插入或更新操作等待完成時，你可能會增加該值。
innodb_lock_wait_timeout僅適用于InnoDB的行級鎖。一個MySQL表鎖不會發生在InnoDB，這個參數并不適用于等待表鎖。
鎖等待超時值不適用于死鎖，因為在事務死鎖時，InnoDB會立即檢測到它們并事務回滾。
innodb_lock_wait_timeout可以在運行時，通過SET GLOBAL或SET SESSION聲明進行設置。修改全局的設置需要SUPER權限，并會影響接下來所有連接客戶端的操作。任何客戶端都可以在SESSION會話級別設置innodb_lock_wait_timeout，它只會影響到該客戶端。
至此，線上mysql云服務器上的配置文件參數已經全部做了整理，對于這些參數也有了一定的認識和了解，接下來，對于經常使用到的connections變量做一下整理，為接下來與同事討論mysql的優化及設置做些準備，主要是以下幾個connections變量：
max_connections
系統變量，它表示最大允許的并發客戶端連接數，會影響在云服務器上運行的線程數量，默認值是151，增加該值會增加mysqld請求的文件描述符的數量。如果所請求的描述符的數量不可用，云服務器會減少max_connections的值。連接拒絕是因為，max_connections的最大值，達到了Connection_errors_max_connections狀態變量的增量。
thread_cache_size 變量的默認值就與max_connections有關。
max_user_connections
表示允許任何給定的MySQL用戶帳戶同時連接的最大數目。默認值為0表示不限制。此變量可以在云服務器啟動時或運行時設置一個全局值。它也有一個只讀會話值，表示與當前會話相關聯的帳戶的有效同時連接的限制值。會話級別的max_user_connections初始化如下：
如果用戶帳戶具有非零的MAX_USER_CONNECTIONS資源限制（帳戶的資源限制通過GRANT語句指定），會話級別的MAX_USER_CONNECTIONS值就設為該限制。
否則的話，會話級別的MAX_USER_CONNECTIONS的值會被設置為全局值。
Connection_errors_max_connections
表示當云服務器中連接數達到max_connections的限制后，連接數被拒絕的數量。
Connections
表示嘗試連接到mysql云服務器的數量，無論成功或失敗。
Max_used_connections
從云服務器啟動開始，已同時被使用的最大連接數。
skip-external-locking作用
在Mysql Linux 的發行版中，默認存在一行skip-external-locking，它表示跳過外部鎖定，與之相對，External-locking變量表示啟用外 部鎖定，用于多線程條件下對MyISAM數據表進行鎖定，默認情況下mysql是禁用外部鎖定的，在現實生產中，我們的業務環境是單云服務器環境，不需要外 部鎖定，所以將其禁用。
key_buffer_size 在InnoDB引擎時無效
在 現實的生產環境中，我們曾對業務庫進行過升級，雖然我們的業務庫使用的是InnoDB引擎，但是其中仍然存在幾張遺留的使用MyISAM存儲引擎的表，設 置這個參數也是為了提供對于這幾張表的訪問性能，用于這幾張表的索引更好的處理讀和多寫操作。另外，在之前windows上安裝mysql 5.5時，會默認產生幾個不同生產環境的my.ini文件，這個參數的配置也參閱了其中的一些配置。
table_open_cache=64 設置是否過小
這個參數的設置最好根據現實生產環境進行設置，在mysql命令行通過show global status like 'open%_tables%'，可以查到兩個重要的參數，如下：
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Open_tables | 81 |
| Opened_tables | 88 |
+---------------+-------+
對與大多數的云服務器設置，建議參考一下公式：Open_tables / Opened_tables >= 0.85；Open_tables / table_open_cache <= 0.95
但是并不是設置table_open_cache越大越好，因為table_cache加大后，使得mysql對 SQL響應的速度更快了，不可避免的會產生更多的死鎖（dead lock），這樣反而使得數據庫整個一套操作慢了下來，嚴重影響性能。所以平時維護中還是要根據庫的實際情況去作出判斷，找到最適合你維護的庫的 table_open_cache值。
詳請參閱：參數table_open_cache。
myisam_sort_buffer_size參數只對MyISAM引擎有效
在現實的生產環境中，雖然我們的業務庫使用的是InnoDB引擎，但有多張業務表使用的是MyIsam引擎，需要這個參數，用于進行表恢復時使用的緩沖區的大小，也是參考了mysql 5.5的配置。
net_buffer_length默認為16K,設置為8K？
這個參數根據客戶端connection 語句的長度有關，現實的業務并不繁雜，語句也比較簡單，參考mysql 5.5的配置，設置net_buffer_length=8k，不過經過與同事討論，決定使用默認值16K。
thread_cache_size設置為20的依據
這個參數的設置與max_connections有關，max_connections表示最大允許的并發客戶端連接數，會影響在云服務器上運行的線程數量，默認值是151，thread_cache_size 的設置，官方doc建議公式：8+（max_connections / 100）,這與現實的業務也存在關系，當云服務器并發很大時，需要修改max_connections的值以滿足業務需要，在我們的現實業務 中，thread_cache_size設置為20較為合適。
innodb_flush_log_at_trx_commit 官方doc建設不要修改默認值
雖然mysql官方doc建議將innodb_flush_log_at_trx_commit設置為1，但在現實的業務中，客戶對于業務性能的速度很高，默認為1表示，在每次事務提交的時候，InnoDB日志緩沖區的內容都會被寫入到日志文件，并且日志文件會被刷新到磁盤。設置為2減少了刷新磁盤的操作，雖然在突然斷點或系統崩潰時可能丟失事務數據，但是在業務允許范圍內，相反修改此參數對于業務速度有很大的提升。
read_rnd_buffer_size增加order by查詢效率
在What exactly is read_rnd_buffer_size中有了一點理解，其中提到了read_buffer_size，在三個方法優化MySQL數據庫查詢中大概的了解了這個參數的作用，當一個查詢不斷地掃描某一個表，MySQL會為它分配一段內存緩沖區。read_buffer_size變 量控制這一緩沖區的大小。如果你認為連續掃描進行得太慢，可以通過增加該變量值以及內存緩沖區大小提高其性能。不過貌似這兩個參數都是值針對于 MyIsam表的，在mysql安裝目錄my.ini中看到這樣一句注釋：Size of the buffer used for doing full table scans of MyISAM tables。對于這個參數的配置還需要再討論。
1.MySQL數據庫主從同步延遲原理。
談到MySQL數據庫主從同步延遲原理，得從mysql的數據庫主從復制原理說起，mysql的主從復制都是單線程的操作(mysql5.6版本之前)，主庫對所有DDL和DML產生binlog，binlog是順序寫，所以效率很高；slave的Slave_IO_Running線程會到主庫取日志，效率會比較高，slave的Slave_SQL_Running線程將主庫的DDL和DML操作都在slave實施。DML和DDL的IO操作是隨機的，不是順序的，因此成本會很高，還可能是slave上的其他查詢產生lock爭用，由于Slave_SQL_Running也是單線程的，所以一個DDL卡主了，需要執行10分鐘，那么所有之后的DDL會等待這個DDL執行完才會繼續執行，這就導致了延時。有朋友會問：“主庫上那個相同的DDL也需要執行10分，為什么slave會延時？”，答案是master可以并發，Slave_SQL_Running線程卻不可以。
2.MySQL數據庫主從同步延遲是怎么產生的。
當主庫的TPS并發較高時，產生的DDL數量超過slave一個sql線程所能承受的范圍，那么延時就產生了，當然還有就是可能與slave的大型query語句產生了鎖等待。
3.MySQL數據庫主從同步延遲解決方案
最簡單的減少slave同步延時的方案就是在架構上做優化，盡量讓主庫的DDL快速執行。還有就是主庫是寫，對數據安全性較高，比如sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之類的設置，而slave則不需要這么高的數據安全，完全可以講sync_binlog設置為0或者關閉binlog，innodb_flushlog也可以設置為0來提高sql的執行效率。另外就是使用比主庫更好的硬件設備作為slave。
4.MySQL數據庫主從同步延遲產生的因素。
1. 網絡延遲
2. master負載
3. slave負載
一般的做法是，使用多臺slave來分攤讀請求，再從這些slave中取一臺專用的云服務器，只作為備份用，不進行其他任何操作，就能相對最大限度地達到’實時’的要求了
另外，再介紹2個可以減少延遲的參數
–slave-net-timeout=seconds
參數含義：當slave從主數據庫讀取log數據失敗后，等待多久重新建立連接并獲取數據
slave_net_timeout單位為秒 默認設置為 3600秒
| slave_net_timeout | 3600
–master-connect-retry=seconds
參數含義：當重新建立主從連接時，如果連接建立失敗，間隔多久后重試。
master-connect-retry單位為秒 默認設置為 60秒
通常配置以上2個參數可以減少網絡問題導致的主從數據同步延遲
看完以上關于Percona Server、MariaDB、MYSQL應該如何選擇，很多讀者朋友肯定多少有一定的了解，如需獲取更多的行業知識信息 ，可以持續關注我們的行業資訊欄目的。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
