A. mariadb 如何實現伺服器內存使用最大化
查詢最高內存佔用
使用以下命令可以知道mysql的配置使用多少 RAM
SELECT ( @@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
)
) / (1024 * 1024 * 1024) AS MAX_MEMORY_GB;
可以使用mysql計算器來計算內存使用
下面是理論，可以直接到推薦配置
如何調整配置
key_buffer_size（MyISAM索引用）
指定索引緩沖區的大小，它決定索引處理的速度，尤其是索引讀的速度。為了最小化磁碟的 I/O ， MyISAM 存儲引擎的表使用鍵高速緩存來緩存索引，這個鍵高速緩存的大小則通過 key-buffer-size 參數來設置。如果應用系統中使用的表以 MyISAM 存儲引擎為主，則應該適當增加該參數的值，以便盡可能的緩存索引，提高訪問的速度。
怎麼設
show global status like 'key_read%';
+------------------------+-------------+
| Variable_name | Value |
+------------------------+-------------+
| Key_read_requests | 27813678764 |
| Key_reads | 6798830 |
---------------------
key_buffer_size通過檢查狀態值Key_read_requests和Key_reads，可以知道key_buffer_size設置是否合理。
比例key_reads / key_read_requests應該盡可能的低，至少是1:100，1:1000更好。
- show global status like '%created_tmp_disk_tables%';
key_buffer_size只對MyISAM表起作用。即使你不使用MyISAM表，但是內部的臨時磁碟表是MyISAM表，也要使用該值。可以使用檢查狀態值created_tmp_disk_tables得知詳情。
對於1G內存的機器，如果不使用MyISAM表，推薦值是16M（8-64M）
- show global status like 'key_blocks_u%';
- +------------------------+-------------+
- | Variable_name | Value |
- +------------------------+-------------+
- | Key_blocks_unused | 0 |
- | Key_blocks_used | 413543 |
- +------------------------+-------------+
可以根據此工式來動態的調整Key_blocks_used / (Key_blocks_unused + Key_blocks_used) * 100% ≈ 80%
- show engines;
查詢存儲引擎
如果是專用的DB伺服器，且以InnoDB引擎為主的場景，通常可設置物理內存的50%，這個參數不能動態更改，所以分配需多考慮。分配過大，會使Swap佔用過多，致使Mysql的查詢特慢。
如果是非專用DB伺服器，可以先嘗試設置成內存的1/4，如果有問題再調整
注意：如果你查詢的表更新比較頻繁，而且很少有相同的查詢，最好不要使用查詢緩存。因為這樣會消耗很大的系統性能還沒有任何的效果
- query_cache_size=128M
- query_cache_type=1
- mysql> show status like '%Qcache%';
- +-------------------------+-----------+
- | Variable_name | Value |
- +-------------------------+-----------+
- | Qcache_free_blocks | 669 |
- | Qcache_free_memory | 132519160 |
- | Qcache_hits | 1158 |
- | Qcache_inserts | 284824 |
- | Qcache_lowmem_prunes | 2741 |
- | Qcache_not_cached | 1755767 |
- | Qcache_queries_in_cache | 579 |
- | Qcache_total_blocks | 1853 |
- +-------------------------+-----------+8 rows in set (0.00 sec)
我們可以看到現網命中1158，未緩存的有1755767次，說明我們這個系統命中的太少了，表變動比較多，不什麼開啟這個功能涉及參數
query_cache_limit：允許 Cache 的單條 Query 結果集的最大容量，默認是1MB，超過此參數設置的 Query 結果集將不會被 Cache
query_cache_min_res_unit：設置 Query Cache 中每次分配內存的最小空間大小，也就是每個 Query 的 Cache 最小佔用的內存空間大小
query_cache_size：設置 Query Cache 所使用的內存大小，默認值為0，大小必須是1024的整數倍，如果不是整數倍，MySQL 會自動調整降低最小量以達到1024的倍數
query_cache_type：控制 Query Cache 功能的開關，可以設置為0(OFF),1(ON)和2(DEMAND)三種，意義分別如下： 0(OFF)：關閉 Query Cache 功能，任何情況下都不會使用 Query Cache 1(ON)：開啟 Query Cache 功能，但是當 SELECT 語句中使用的 SQL_NO_CACHE 提示後，將不使用Query Cache 2(DEMAND)：開啟 Query Cache 功能，但是只有當 SELECT 語句中使用了 SQL_CACHE 提示後，才使用 Query Cache
query_cache_wlock_invalidate：控制當有寫鎖定發生在表上的時刻是否先失效該表相關的 Query Cache，如果設置為 1(TRUE)，則在寫鎖定的同時將失效該表相關的所有 Query Cache，如果設置為0(FALSE)則在鎖定時刻仍然允許讀取該表相關的 Query Cache。
這個參數實際起作用的最大值（實際最大可連接數）為16384，即該參數最大值不能超過16384，即使超過也以16384為准；
增加max_connections參數的值，不會佔用太多系統資源。系統資源（CPU、內存）的佔用主要取決於查詢的密度、效率等；
該參數設置過小的最明顯特徵是出現」Too many connections」錯誤
- mysql> show variables like '%max_connect%';
- +-----------------------+-------+
- | Variable_name | Value |
- +-----------------------+-------+
- | extra_max_connections | 1 |
- | max_connect_errors | 100 |
- | max_connections | 2048 |
- +-----------------------+-------+3 rows in set (0.00 sec)
- mysql> show status like 'Threads%';
- +-------------------+---------+
- | Variable_name | Value |
- +-------------------+---------+
- | Threads_cached | 0 |
- | Threads_connected | 1 |
- | Threads_created | 9626717 |
- | Threads_running | 1 |
- +-------------------+---------+4 rows in set (0.00 sec)
- mysql> show variables like 'open_files_limit';
- +------------------+-------+
- | Variable_name | Value |
- +------------------+-------+
- | open_files_limit | 65535 |
- +------------------+-------+1 row in set (0.00 sec)
- ulimit -n65535
- mysql> SHOW GLOBAL STATUS like '%sort%';
- +---------------------------+--------+
- | Variable_name | Value |
- +---------------------------+--------+
- | Sort_merge_passes | 0 |
- | Sort_priority_queue_sorts | 1409 |
- | Sort_range | 0 |
- | Sort_rows | 843479 |
- | Sort_scan | 13053 |
- +---------------------------+--------+5 rows in set (0.00 sec)
如果發現Sort_merge_passes的值比較大，你可以考慮增加sort_buffer_size來加速ORDER BY 或者GROUP BY 操作,不能通過查詢或者索引優化的。我們這為0，那就沒必要設置那麼大。
- mysql> show global status like 'binlog_cache%';
- +-----------------------+----------+
- | Variable_name | Value |
- +-----------------------+----------+
- | Binlog_cache_disk_use | 220840 |
- | Binlog_cache_use | 67604667 |
- +-----------------------+----------+2 rows in set (0.00 sec)
Binlog_cache_disk_use表示因為我們binlog_cache_size設計的內存不足導致緩存二進制日誌用到了臨時文件的次數
Binlog_cache_use 表示 用binlog_cache_size緩存的次數
當對應的Binlog_cache_disk_use 值比較大的時候 我們可以考慮適當的調高 binlog_cache_size 對應的值
如上圖，現網是32K，我們加到64K
- mysql> show status like '%threads%';
- +-------------------------+---------+
- | Variable_name | Value |
- +-------------------------+---------+
- | Delayed_insert_threads | 0 |
- | Slow_launch_threads | 0 |
- | Threadpool_idle_threads | 0 |
- | Threadpool_threads | 0 |
- | Threads_cached | 0 |
- | Threads_connected | 1 |
- | Threads_created | 9649301 |
- | Threads_running | 1 |
- +-------------------------+---------+8 rows in set (0.00 sec)
- mysql> show status like 'connections';
- +---------------+---------+
- | Variable_name | Value |
- +---------------+---------+
- | Connections | 9649311 |
- +---------------+---------+1 row in set (0.00 sec)
- Thread_Cache_Hit = (Connections - Threads_created) / Connections * 100%;
- mysql> show status like 'Created_tmp_%';
- +-------------------------+-------+
- | Variable_name | Value |
- +-------------------------+-------+
- | Created_tmp_disk_tables | 0 |
- | Created_tmp_files | 626 |
- | Created_tmp_tables | 3 |
- +-------------------------+-------+3 rows in set (0.00 sec)
如上圖，寫入硬碟的為0，3次中間表，說明我們的默認值足夠用了
注意這里只推薦innodb引擎
內存配置只關注有注釋的行
- [mysqld]
- datadir=/var/lib/mysql
- socket=/var/lib/mysql/mysql.sockdefault-storage-engine=INNODB
- character-set-server=utf8
- collation-server=utf8_general_ci
- user=mysql
- symbolic-links=0# global settings
- table_cache=65535table_definition_cache=65535max_allowed_packet=4M
- net_buffer_length=1M
- bulk_insert_buffer_size=16M
- query_cache_type=0 #是否使用查詢緩沖,0關閉
- query_cache_size=0 #0關閉，因為改表操作多，命中低，開啟消耗cpu
- # shared
- key_buffer_size=8M #保持8M MyISAM索引用
- innodb_buffer_pool_size=4G #DB專用mem*50%，非DB專用mem*15%到25%
- myisam_sort_buffer_size=32M
- max_heap_table_size=16M #最大中間表大小
- tmp_table_size=16M #中間表大小
- # per-thread
- sort_buffer_size=256K #加速排序緩存大小
- read_buffer_size=128k #為需要全表掃描的MYISAM數據表線程指定緩存
- read_rnd_buffer_size=4M #已排序的表讀取時緩存，如果比較大內存就到6M
- join_buffer_size=1M #join語句多時加大，1-2M
- thread_stack=256k #線程空間，256K or 512K
- binlog_cache_size=64K #大事務binlog
- # big-tables
- innodb_file_per_table = 1skip-external-locking
- max_connections=2048 #最大連接數
- skip-name-resolve
- # slow_query_log
- slow_query_log_file = /var/log/mysql-slow.log
- long_query_time = 30group_concat_max_len=65536# according to tuning-primer.sh
- thread_cache_size = 8thread_concurrency = 16# set variables
- concurrent_insert=2
- set global {要改的key} = {值}; （立即生效重啟後失效）
- set @@{要改的key} = {值}; （立即生效重啟後失效）
- set @@global.{要改的key} = {值}; （立即生效重啟後失效）
- mysql> set @@global.innodb_buffer_pool_size=4294967296;
- ERROR 1238 (HY000): Variable 'innodb_buffer_pool_size' is a read only variable
- mysql> set @@global.thread_stack=262144;
- ERROR 1238 (HY000): Variable 'thread_stack' is a read only variable
- mysql> set @@global.binlog_cache_size=65536;
- Query OK, 0 rows affected (0.00 sec)
- mysql> set @@join_buffer_size=1048576;
- Query OK, 0 rows affected (0.00 sec)
- mysql> set @@read_rnd_buffer_size=4194304;
- Query OK, 0 rows affected (0.00 sec)
- mysql> set @@sort_buffer_size=262144;
- Query OK, 0 rows affected (0.00 sec)
- mysql> set @@read_buffer_size=131072;
- Query OK, 0 rows affected (0.00 sec)
- mysql> set global key_buffer_size=8388608;
- Query OK, 0 rows affected (0.39 sec)
我們可以看到innodb_buffer_pool_size和thread_stack報錯了，他們只能改配置文件，在運行時是只讀的。 以下直接復制使用
- set @@global.binlog_cache_size=65536;
- set @@join_buffer_size=1048576;
- set @@read_rnd_buffer_size=4194304;
- set @@sort_buffer_size=262144;
- set @@read_buffer_size=131072;
- set global key_buffer_size=8388608;
另一個參考如下
Key_blocks_unused表示未使用的緩存簇(blocks)數，Key_blocks_used表示曾經用到的最大的blocks數，比如這台伺服器，所有的緩存都用到了，要麼增加key_buffer_size，要麼就是過渡索引了，把緩存占滿了。比較理想的設置：
innodb_buffer_pool_size （innodb索引用）
這個參數和MyISAM的key_buffer_size有相似之處，但也是有差別的。這個參數主要緩存innodb表的索引，數據，插入數據時的緩沖。為Innodb加速優化首要參數。
該參數分配內存的原則：這個參數默認分配只有8M，可以說是非常小的一個值。
query_cache_size（查詢緩存）
緩存機制簡單的說就是緩存sql文本及查詢結果，如果運行相同的sql，伺服器直接從緩存中取到結果，而不需要再去解析和執行sql。如果表更改了，那麼使用這個表的所有緩沖查詢將不再有效，查詢緩存值的相關條目被清空。更改指的是表中任何數據或是結構的改變，包括INSERT、UPDATE、DELETE、TRUNCATE、ALTER TABLE、DROP TABLE或DROP DATABASE等，也包括那些映射到改變了的表的使用MERGE表的查詢。顯然，這對於頻繁更新的表，查詢緩存是不適合的，而對於一些不常改變數據且有大量相同sql查詢的表，查詢緩存會節約很大的性能。
要不要打開？
先設置成這樣跑一段時間
看看命中結果來進行進一步的判斷
Qcache_free_blocks:表示查詢緩存中目前還有多少剩餘的blocks，如果該值顯示較大，則說明查詢緩存中的內存碎片過多了，可能在一定的時間進行整理。
Qcache_free_memory:查詢緩存的內存大小，通過這個參數可以很清晰的知道當前系統的查詢內存是否夠用，是多了，還是不夠用，DBA可以根據實際情況做出調整。
Qcache_hits:表示有多少次命中緩存。我們主要可以通過該值來驗證我們的查詢緩存的效果。數字越大，緩存效果越理想。
Qcache_inserts: 表示多少次未命中然後插入，意思是新來的SQL請求在緩存中未找到，不得不執行查詢處理，執行查詢處理後把結果insert到查詢緩存中。這樣的情況的次數，次數越多，表示查詢緩存應用到的比較少，效果也就不理想。當然系統剛啟動後，查詢緩存是空的，這很正常。
Qcache_lowmem_prunes:該參數記錄有多少條查詢因為內存不足而被移除出查詢緩存。通過這個值，用戶可以適當的調整緩存大小。
Qcache_not_cached: 表示因為query_cache_type的設置而沒有被緩存的查詢數量。
Qcache_queries_in_cache:當前緩存中緩存的查詢數量。
Qcache_total_blocks:當前緩存的block數量。
innodb_additional_mem_pool_size（InnoDB內部目錄大小）
InnoDB 字典信息緩存主要用來存放 InnoDB 存儲引擎的字典信息以及一些 internal 的共享數據結構信息，也就是存放Innodb的內部目錄，所以其大小也與系統中所使用的 InnoDB 存儲引擎表的數量有較大關系。
這個值不用分配太大，通常設置16M夠用了，默認8M，如果設置的內存大小不夠，InnoDB 會自動申請更多的內存，並在 MySQL 的 Error Log 中記錄警告信息。
innodb_log_buffer_size （日誌緩沖）
表示InnoDB寫入到磁碟上的日誌文件時使用的緩沖區的位元組數，默認值為16M。一個大的日誌緩沖區允許大量的事務在提交之前不用寫日誌到磁碟，所以如果有更新，插入或刪除許多行的事務，則使日誌緩沖區更大一些可以節省磁碟IO
通常最大設為64M足夠
max_connections (最大並發連接)
MySQL的max_connections參數用來設置最大連接（用戶）數。每個連接MySQL的用戶均算作一個連接，max_connections的默認值為100。
可以看到此時的並發數也就是Threads_connected=1，還遠遠達不到2048
max_connections 還取決於操作系統對單進程允許打開最大文件數的限制
也就是說如果操作系統限制單個進程最大可以打開100個文件
那麼 max_connections 設置為200也沒什麼用
MySQL 的 open_files_limit 參數值是在MySQL啟動時記錄的操作系統對單進程打開最大文件數限制的值
可以使用 show variables like 'open_files_limit'; 查看 open_files_limit 值
或者直接在 Linux 下通過ulimit -n命令查看操作系統對單進程打開最大文件數限制 ( 默認為1024 )
connection級內存參數(線程獨享)
connection級參數，是在每個connection第一次需要使用這個buffer的時候，一次性分配設置的內存。
排序性能
mysql對於排序,使用了兩個變數來控制sort_buffer_size和 max_length_for_sort_data, 不象oracle使用SGA控制. 這種方式的缺點是要單獨控制,容易出現排序性能問題.
讀取緩存
read_buffer_size = 128K(默認128K)為需要全表掃描的MYISAM數據表線程指定緩存
read_rnd_buffer_size = 4M：(默認256K)首先，該變數可以被任何存儲引擎使用，當從一個已經排序的鍵值表中讀取行時，會先從該緩沖區中獲取而不再從磁碟上獲取。
大事務binlog
join語句內存影響
如果應用中，很少出現join語句，則可以不用太在乎join_buffer_size參數的設置大小。
如果join語句不是很少的話，個人建議可以適當增大join_buffer_size到1MB左右，如果內存充足可以設置為2MB。
線程內存影響
Thread_stack：每個連接線程被創建時，MySQL給它分配的內存大小。當MySQL創建一個新的連接線程時，需要給它分配一定大小的內存堆棧空間，以便存放客戶端的請求的Query及自身的各種狀態和處理信息。
如上：系統啟動到現在共接受到客戶端的連接9649311次，共創建了9649301個連接線程，當前有1個連接線程處於和客戶端連接的狀態。而在Thread Cache池中共緩存了0個連接線程(Threads_cached)。
Thread Cache 命中率：
一般在系統穩定運行一段時間後，Thread Cache命中率應該保持在90%左右才算正常。
內存臨時表
tmp_table_size 控制內存臨時表的最大值,超過限值後就往硬碟寫，寫的位置由變數 tmpdir 決定
max_heap_table_size 用戶可以創建的內存表(memory table)的大小.這個值用來計算內存表的最大行數值。
Order By 或者Group By操作多的話，加大這兩個值，默認16M
mariadb 推薦配置
運行時修改
使用以下命令來修改變數
試驗
B. mariadb是怎麼產生 的 跟mysql有啥區別
MariaDB資料庫管理系統是MySQL的一個分支，主要由開源社區在維護，採用GPL授權許可。開發這個分支的原因之一是：甲骨文公司收購了MySQL後，有將MySQL閉源的潛在風險，因此社區採用分支的方式來避開這個風險。 MariaDB的目的是完全兼容MySQL，包括API和命令行，使之能輕松成為MySQL的代替品。在存儲引擎方面，使用XtraDB（英語：XtraDB）來代替MySQL的InnoDB。 MariaDB由MySQL的創始人Michael Widenius（英語：Michael Widenius）主導開發，他早前曾以10億美元的價格，將自己創建的公司MySQL AB賣給了SUN，此後，隨著SUN被甲骨文收購，MySQL的所有權也落入Oracle的手中。MariaDB名稱來自Michael Widenius的女兒Maria的名字而MySQL[1] 是一個關系型資料庫管理系統，由瑞典MySQL AB公司開發，目前屬於Oracle公司。MySQL是最流行的關系型資料庫管理系統，在WEB應用方面MySQL是最好的RDBMS(Relational Database Management System：關系資料庫管理系統)應用軟體之一。MySQL是一種關聯資料庫管理系統，關聯資料庫將數據保存在不同的表中，而不是將所有數據放在一個大倉庫內，這樣就增加了速度並提高了靈活性。MySQL所使用的SQL語言是用於訪問資料庫的最常用標准化語言。MySQL軟體採用了雙授權政策（本詞條「授權政策」），它分為社區版和商業版，由於其體積小、速度快、總體擁有成本低，尤其是開放源碼這一特點，一般中小型網站的開發都選擇MySQL作為網站資料庫。由於其社區版的性能卓越，搭配PHP和Apache可組成良好的開發環境。
C. 為什麼選擇PostgreSQL而不是MySQL
David
Bolton是一名獨立開發者，他使用PostgreSQL和MySQL都已有超過十年的時間。近日，他撰文闡述了選擇PostgreSQL而不是MySQL的理由。他認為，MySQL之所以仍然如此流行是因為每個Linux
Web託管軟體包中都包含它。但隨著Oracle將其收購，MySQL的開源程度大不如前。而PostgreSQL不僅發展更快，還加入了JSON支持，成為少數幾個支持NoSQL的關系型資料庫之一。
MySQL/MariaDB的當前版本是5.7.6（MariaDB為MySQL創建者Monty
Widenius創建的一個MySQL分支），PostgreSQL的版本是9.4.1。Bolton從以下幾個方面對比了兩者的最新版本：
ANSI標准兼容性：與先前的版本相比，MySQL已經有了長足的進步，但MySQL背後的哲學是，如果客戶喜歡，他們就會支持非標准擴展，而PostgreSQL從開始就將標准構建到平台里。不過，二者殊途同歸，差別不大；
ACID遵從性：PostgreSQL有一個存儲引擎，而MySQL有9個，但只有MyIsam和InnoDB與大部分用戶有關，其中，後者為默認存儲引擎。InnoDB和PostgreSQL都完全遵循ACID，差別不大；
無鎖表修改：MyIsam使用表級鎖來提升速度，這會導致寫互斥。但PostgreSQL和InnoDB均使用行級鎖，差別不大；
子查詢：長期以來，這一直是MySQL的一個弱點，雖然5.6.5作了重大改進，但PostgreSQL對表連接支持得更好，尤其是MySQL不支持全外連接，因此，這方面PostgreSQL勝過MySQL；
JSON支持和NoSQL：PostgreSQL最近增加了JSON支持，與傳統的關系型資料庫相比，它提供了更大的數據存儲靈活性，因此，這方面PostgreSQL勝過MySQL。
此外，Bolton指出，選擇PostgreSQL還有如下理由：
更好的許可：PostgreSQL採用類似MIT的許可協議，允許開發人員做任何事情，包括在開源或閉源產品中商用，而MySQL的客戶端遵循GPL許可協議，所以開發人員必須向Oracle付費或者將自己的應用程序開源；
更好的數據一致性：
PostgreSQL會在數據插入和更新之前進行嚴格的驗證，確保數據合法才會進行相應的操作，但在MySQL中，開發人員需要將伺服器設定為嚴格SQL模式才能達到同樣的目的，否則可能會產生不規范數據；
伺服器擴展：MySQL提供了插件程序API，支持C/C++或任何兼容C的語言，而且從5.7.3版本開始支持全文搜索，PostgreSQL有一個類似的系統但支持的語言更多，包括C/C++、Java、.Net、Perl、
Python、Ruby、Tcl、ODBC等，它甚至可以在單獨的進程中運行用戶提供的代碼；除了所有關系型資料庫都包含的有關資料庫、表和列的一般信息外，PostgreSQL系統目錄中還可以包含關於數據類型、函數和存取方法的信息，開發人員可以通過修改這些信息實現擴展。
D. centos 7默認搭載mariadb嗎
默認沒有 需要yum安裝下.
MariaDB資料庫管理系統是MySQL的一個分支，主要由開源社區在維護，採用GPL授權許可 MariaDB的目的是完全兼容MySQL，包括API和命令行，使之能輕松成為MySQL的代替品。在存儲引擎方面，使用XtraDB（英語：XtraDB）來代替MySQL的InnoDB。 MariaDB由MySQL的創始人Michael Widenius（英語：Michael Widenius）主導開發，他早前曾以10億美元的價格，將自己創建的公司MySQL AB賣給了SUN，此後，隨著SUN被甲骨文收購，MySQL的所有權也落入Oracle的手中。MariaDB名稱來自Michael Widenius的女兒Maria的名字。
MariaDB基於事務的Maria存儲引擎，替換了MySQL的MyISAM存儲引擎，它使用了Percona的 XtraDB，InnoDB的變體，分支的開發者希望提供訪問即將到來的MySQL 5.4 InnoDB性能。這個版本還包括了 PrimeBase XT (PBXT) 和 FederatedX存儲引擎。
E. MariaDB 是什麼
瑪麗亞資料庫
F. CentOS 7為什麼放棄了MySQL，而改使用MariaDB
MariaDB資料庫管理系統是MySQL的一個分支，主要由開源社區在維護，採用GPL授權許可
。開發這個分支的原因之一是：甲骨文公司收購了MySQL後，有將MySQL閉源的潛在風險，
因此社區採用分支的方式來避開這個風險。
MariaDB的目的是完全兼容MySQL，包括API和命令行，使之能輕松成為MySQL的代替品。
在存儲引擎方面，10.0.9版起使用XtraDB（名稱代號為Aria）來代替MySQL的InnoDB。
MariaDB由MySQL的創始人麥克爾·維德紐斯主導開發，他早前曾以10億美元的價格，
將自己創建的公司MySQL AB賣給了SUN，此後，隨著SUN被甲骨文收購，
MySQL的所有權也落入Oracle的手中。
MariaDB名稱來自麥克爾·維德紐斯的女兒瑪麗亞（英語：Maria）的名字。
G. MariaDB資料庫的特點是什麼
MariaDB 是一個採用 Maria 存儲引擎的MySQL分支版本，是由原來 MySQL 的作者Michael Widenius創辦的公司所開發的免費開源的資料庫伺服器。
這個項目的很多代碼都改編於 MySQL 6.0，例如 「pool of threads」功能提供解決多數據連接問題。MariaDB 5.1.41 RC可以到這里下載，32位和64位已編譯Linux版本，還包括源代碼包。MariaDB基於GPL 2.0發布。
與 MySQL 相比較，MariaDB 更強的地方在於：
Maria 存儲引擎
PBXT 存儲引擎
XtraDB 存儲引擎
FederatedX 存儲引擎
更快的復制查詢處理
線程池
更少的警告和bug
運行速度更快
更多的 Extensions (More index parts, new startup options etc)
更好的功能測試
數據表消除
慢查詢日誌的擴展統計
支持對 Unicode 的排序
相對於MySQL最新的版本5.6來說，在性能、功能、管理、NoSQL擴展方面，MariaDB包含了更豐富的特性。比如微秒的支持、線程池、子查詢優化、組提交、進度報告等。詳情見列表。
參考：網頁鏈接
H. 如何在Ubuntu上安裝和使用MariaDB資料庫
MariaDB概要介紹
MariaDB是MySQL資料庫的一個分支版本，該版本主要是通過開源社區進行維護，MariaDB可以完全兼容MySQL（包括API和命令），主要區別在於存儲引擎使用了XtraDB代替了InnoDB。
安裝MariaDB軟體包
通過一下命令進行安裝：
# apt install mariadb-server python-pymysql
配置mySQL服務啟動參數,為後續安裝openStack提前准備好資料庫環境
創建啟動參數配置文件：/etc/mysql/mariadb.conf.d/99-openstack.cnf
輸入如下內容：
[mysqld]
default-storage-engine = innodb
innodb_file_per_table
max_connections = 2048
collation-server = utf8mb4_general_ci
character-set-server = utf8mb4
重新啟動mysql資料庫服務
使用一下命令重啟mysql
#service mysql restart
如果沒有異常情況，則不會有任何輸出，這時候可以使用如下命令查看服務運行狀態
#service mysql status
啟動mysql異常提示無效的字元編碼問題處理
在步驟3創建的配置文件由於參數的名稱輸錯導致啟動失敗，提示不支持utf8_general_ci
[mysqld]
default-storage-engine = innodb
innodb_file_per_table
max_connections = 2048
collation-server = utf8_general_ci
character-set-erver = utf8
啟動MySQL服務失敗這時候可以通過命令以下命令查看具體原因：
systemctl status mysql.service
通過檢測發現character-set-erver參數名輸錯了導致啟動失敗，將其改為
character-set-server = utf8 即可
給mysql進行安全加固
使用腳本 mysql_sercure_installation進行mysql資料庫安全加固
# mysql_secure_installation
啟動腳本後按提示進行安全加固操作即可完成
使用mysql命令行連接mysql服務，驗證mysql服務是否正常
#myslq -uroot -p
輸入root密碼即可連接到本機的mysql服務
使用IP地址方式連接和管理MySQL
使用如下命令進行連接MySQL發現連接異常(192.168.122.1為本機的IP地址)
#mysql -h192.168.122.1 -uroot -p
輸入密碼後發現連接失敗，原因是因為我們配置的mysql服務參數中沒有綁定IP地址，系統默認使用了local主機名進行，那麼通過參數設定綁定IP地址即可
修改啟動參數配置文件：/etc/mysql/mariadb.conf.d/99-openstack.cnf，增加IP地址綁定
[mysqld]
bind-address = 192.168.122.1
default-storage-engine = innodb
innodb_file_per_table
max_connections = 4096
collation-server = utf8_general_ci
character-set-server = utf8
I. mariadb 與percona server 哪個更適合生產環境
導讀：盡管MySQL是最受歡迎的程序之一，但是許多開發人員認為有必要將其拆分成其他項目，並且每個分支項目都有自己的專長。該 需求以及Oracle對核心產品增長緩慢的擔憂，導致出現了許多開發人員感興趣的子項目和分支。本文將討論受人們關注的三個流行MySQL分 支：Drizzle、MariaDB和Percona Server（包括XtraDB引擎）。文中簡要介紹每個分支出現的原因及其目標，以及是否可在您自己的生產環境中使用它們。
文章內容如下：
簡介
MySQL是歷史上最受歡迎的免費開源程序之一。它是成千上萬個網站的資料庫骨幹，並且可以將它（和Linux）作為過去10年裡Internet呈指數級增長的一個有力證明。
那麼，如果MySQL真的這么重要，為什麼還會出現越來越多的核心MySQ產品的高端衍生產品？這是因為MySQL是免費的開源應用程序，所以開發 人員總是可以獲得其代碼，並按照自己的想法修改代碼，然後再自行分發代碼。在很長的一段時間里，在開發人員自己的生產環境中，沒有任何值得信任的 MySQL分支。但是，這種情況很快就發生了改變。有幾個分支引起了許多人的關注。
為什麼要進行分支？
為什麼需要對MySQL進行分支？這是一個非常合理的問題。成千上萬的網站依賴於MySQL，並且對許多人來說，它似乎是一個很好的解決方案。但 是，通常就是這樣，適合許多人並不一定適合所有人。這促使一些開發人員想要根據自己的需要開發出更好的解決方案。還有什麼能比將良好的解決方案轉換為完美 的解決方案更好的呢？。
下面我們將介紹這些分支尋求改變的更多細節。一些分支認為MySQL變得太臃腫了，提供了許多用戶永遠不會感興趣的功能，犧牲了性能的簡單性。如果 人們對更精簡的MySQL 4特別滿意，那麼為什麼還要在MySQL 5中添加額外的復雜性呢？對於此分支來說，更好的MySQL分支應該更簡單、更快捷，因此提供的功能也較少，但這樣會使這些功能極其迅速地發揮作用，並且 牢記目標受眾，在本例中，目標受眾是高可用性網站。
對於其他分支來說，MySQL並沒有提供足夠多的新功能，或者是添加新功能的速度太慢了。他們可能認為MySQL沒有跟上高可用性網站的目標市場的 發展形勢，這些網站運行於具有大量內存的多核處理器之上。正如熟悉MySQL的人所知道的那樣，MySQL提供了兩種存儲引擎：MyISAM和 InnoDB。這一分支認為這兩種存儲引擎都沒有提供他們所需的內容，因此他們創建了一種非常適合其目標的新存儲引擎。
此外，一些分支的最高目標是成為MySQL的替代產品，在這些產品中，您可以輕松地訪問它們的分支，無需更改任何代碼。該分支使用與MySQL相同 的代碼和界面，因此使過渡變得非常容易。但是，另一個分支聲稱它與MySQL不兼容，需要更改代碼。每個分支的成熟度各不相同，一些分支聲稱已經准備就緒 可以投入生產，而另外一些則聲稱目前自己還遠達不到這一最高目標。
最後，關於MySQL在Oracle下將如何發展仍不太確定。Oracle收購了Sun，也收購了MySQL，現在Oracle控制MySQL產品 本身，並領導開發社區開發新的成品。由於Oracle已經有了一個商業資料庫，因此人們擔心他們可能沒有足夠的資源來使MySQL保持其領先地位。因此， 許多分支也是這些潛在擔心所產生的結果，他們擔心MySQL作為領先的免費開源資料庫提供的功能可能太少、發布周期太慢並且支持費用更昂貴。
XtraDB
XtraDB是一款獨立的產品，但它仍被認為是MySQL的一個分支。XtraDB實際上是基於MySQL的資料庫的一個存儲引擎。XtraDB被 認為是已成為MySQL一部分的標准MyISAM和InnoDB的一個額外存儲引擎。MySQL 4和5使用默認的MyISAM存儲引擎安裝每個表。InnoDB也是一個相對較新的存儲引擎選擇，在建立資料庫時，資料庫管理員和開發人員可以基於每個表 選擇存儲引擎類型。兩個存儲引擎的主要區別是：MyISAM沒有提供事務支持，而InnoDB提供了事務支持。其他差別是許多細微的性能差別，與 MyISAM相比，InnoDB提供了許多細微的性能改進，並且在處理潛在的數據丟失時提供了更高的可靠性和安全性。似乎InnoDB是用於未來改進的更 適合的存儲引擎，因此從版本5.5開始，MySQL已將默認存儲引擎從MyISAM更改為InnoDB。
基於這些優勢，InnoDB存儲引擎本身拆分出了一個分支，一個名為XtraDB的更新的存儲引擎。這個存儲引擎有多新呢？它3年前由 Percona首次發布，因此它相對較新。它是專門針對在現代伺服器上運行的現代高可用性網站設計的。它被設計為在具有十幾個或更多核心和大內存 （32GB及更多）的伺服器上運行。任何公司都可以從伺服器管理公司購買這些類型的伺服器，因此應將資料庫設計為能夠充分利用這些伺服器。
XtraDB分支有另一個目標，即成為InnoDB存儲引擎的簡單替代，這樣用戶就可以輕松地切換其存儲引擎，無需更改任何現有的應用程序代碼。XtraDB必須能夠向後兼容InnoDB，以提供它們想要添加的所有新功能和改進。它們實現了此目標。
XtraDB的速度有多快？我找到的一個性能測試表明：與內置的MySQL 5.1 InnoDB 引擎相比，它每分鍾可處理2.7倍的事務。（請參見參考資料）。速度顯然是一個不可以忽略的因素，在考慮替代產品時更是如此。
Percona
與內置的MySQL存儲引擎相比，XtraDB提供了一些極大的改進，但它不是一款獨立產品，也無法輕松放入現有MySQL安裝。因此，如果您想使用這款新引擎，則必須使用提供它的產品。
Percona Server就是這樣一款產品，由領先的MySQL咨詢公司Percona發布。Percona Server是一款獨立的資料庫產品，為用戶提供了換出其MySQL安裝並換入Percona Server產品的能力。通過這樣做，就可以利用XtraDB存儲引擎。Percona Server聲稱可以完全與MySQL兼容，因此從理論上講，您無需更改軟體中的任何代碼。這確實是一個很大的優勢，適合在您尋找快速性能改進時控制質 量。因此，採用Percona Server的一個很好的理由是，利用XtraDB引擎來盡可能地減少代碼更改。
此外，他們是XtraDB存儲引擎的原作者。Percona將此代碼用作開源代碼，因此您可以在其他產品中找到它，但引擎的最初創建者與編寫此產品的是同一個人，所以您可以隨心所欲地使用此信息。
下面是Percona Server的聲明，該聲明來自它們自己的網站：
可擴展性：處理更多事務；在強大的伺服器上進行擴展
性能：使用了XtraDB的Percona Server速度非常快
可靠性：避免損壞，提供崩潰安全(crash-safe)復制
管理：在線備份，在線表格導入/導出
診斷：高級分析和檢測
靈活性：可變的頁面大小，改進的緩沖池管理
Percona團隊的最終聲明是「Percona Server是由Oracle發布的最接近官方MySQL Enterprise發行版的版本」，因此與其他更改了大量基本核心MySQL代碼的分支有所區別。Percona Server的一個缺點是他們自己管理代碼，不接受外部開發人員的貢獻，以這種方式確保他們對產品中所包含功能的控制。
MariaDB
另一款提供了XtraDB存儲引擎的產品是MariaDB產品。它與Percona產品非常類似，但是提供了更多底層代碼更改，試圖提供比標准 MySQL更多的性能改進。MariaDB直接利用來自Percona的XtraDB引擎，由於它們使用的是完全相同的引擎，因此每次使用存儲引擎時沒有 顯著的差別。
此外，MariaDB提供了MySQL提供的標准存儲引擎，即MyISAM和InnoDB。因此，實際上，可以將它視為MySQL的擴展集，它不僅 提供MySQL提供的所有功能，還提供其他功能。MariaDB還聲稱自己是MySQL的替代，因此從MySQL切換到MariaDB時，無需更改任何基 本代碼即可安裝它。
最後可能也是最重要的一點是，MariaDB的主要創建者是Monty Widenius，也是MySQL的初始創建者。Monty成立了一家名為Monty Program的公司來管理MariaDB的開發，這家公司僱傭開發人員來編寫和改進MariaDB產品。這既是一件好事，也是一件壞事：有利的一面在於 他們是Maria功能和bug修復的佼佼者，但公司不是以贏利為目的，而是由產品驅動的，這可能會帶來問題，因為沒有贏利的公司不一定能長久維持下去。
Drizzle
本文介紹的最後一款產品是Drizzle。與之前介紹的兩款產品不同，Drizzle與MySQL有很大差別，甚至聲稱它們不是MySQL的替代產 品。他們期望對MySQL進行一些重大更改，想要提供一種出色的解決方案來解決高可用性問題，即使這意味著要更改我們已經習慣了的MySQL的各個方面。
在公司的FAQ頁面，閱讀其中提供的問題時就會發現，Drizzle進一步地強調了其基本目標。他們不滿意MySQL 4.1版本之後對MySQL代碼進行的一些更改，聲稱許多開發人員不想花費額外的錢。他們承認其產品與SQL關系資料庫甚至是不兼容的。這確實與 MySQL有很大的不同。
與習慣的MySQL有如此大的變化，我們為什麼還要考慮這款產品呢？准確地講，原因與上面的是相同的，Drizzle是MySQL引擎的一次重大修 改，它清除了一些表現不佳和不必要的功能，將很多代碼重寫，對它們進行了優化，甚至將所用語言從C換成了C++，以獲得所需的代碼。此外，Drizzle 並沒有就此結束修改，該產品在設計時就考慮到了其目標市場，即具有大量內容的多核伺服器、運行Linux的64位機器、雲計算中使用的伺服器、託管網站的 伺服器和每分鍾接收數以萬計點擊率的伺服器。這是一個相當具體的市場。它太具體了嗎？請記住這些類型的公司目前在其資料庫方面投入的資金，如果他們可以安 裝Drizzle而不是MySQL，那麼他們的伺服器成本將削減一半，可以節省很多錢！
那麼，是不是所有人都應該使用Drizzle呢？等等，正如Drizzle反復指出的那樣，它與MySQL不兼容。因此，如果您現在使用的是MySQL平台，那麼需要重寫大量代碼，才能使Drizzle在您的環境中正常工作。
盡管需要額外的工作才能讓它運行，但它並不像Percona或MariaDB那樣快速且易於使用。我之所以介紹Drizzle，是因為盡管目前它可 能不是您的選擇，但幾年之後，它很可能會成為一些人的選擇。因為本文的目標是提高您對未來使用的工具的認識，所以這是向您介紹此產品的好機會。許多領先的 DB專家相信Drizzle將成為未來5年內高可用性資料庫安裝的選擇。
Drizzle是完全開源的產品，公開接受開發人員的貢獻。它不像MariaDB那樣有支持其開發的公司，也不像Percona那樣有大量外部開發人員為其提供貢獻。Drizzle有很好的成長空間並會提供一些新功能，但可能需要重寫大部分MySQL代碼。
J. 數據存儲在mariadb上將mariadb刪掉，數據還能找到嗎
還能找到，MariaDB基於事務的Maria存儲引擎，替換了MySQL的MyISAM存儲引擎，它使用了Percona的 XtraDB，InnoDB的變體，分支的開發者希望提供訪問即將到來的MySQL 5.4 InnoDB性能。這個版本還包括了 PrimeBase XT (PBXT) 和 FederatedX存儲引擎。