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存储引擎。