数据库选型粗略对比，欢迎补充！！！

关系型数据库 Oracle、SQL Server、 MySQL 、PostgreSQL、SQLite

• Oracle：甲骨文开发的商业数据库，不开源，支持所有主流平台，性能好，功能强，稳定性好，安全性好，支持大数据量，比较复杂，收费昂贵
• SQL Server：微软开发的商业数据库，只能在 Windows 运行
• MySQL ：甲骨文拥有的开源数据库，支持多种操作系统，体积小，功能弱些，简单的操作性能好，复杂的操作性能差些
• PostgreSQL：使用 BSD 协议的完全开源免费的项目，支持多种操作系统，功能更强大，可以和多种开源工具配合
• SQLite：开源、轻型、无服务器、零配置，一个数据库就只是一个文件，在应用程序内执行操作，占用资源小，可用于嵌入式或小型应用

Oracle 多用于银行等高要求的领域，要求不高的比如互联网行业多用 MySQL 和 PostgreSQL，而 SQLite 用于嵌入式或作为应用程序内的数据库使用，SQL Server 用于 Window 服务器；

MySQL (开源，非国产，关系型数据库，最流行)

(1) 数据库介绍

MySQL 是一个关系型数据库管理系统，由瑞典 MySQL AB 公司开发，目前属于 Oracle 公司。 MySQL 是一种关联数据库管理系统，关联数据库将数据保存在不同的表中，而不是将所有数据放在一个大仓库内，这样就增加了速度并提高了灵活性。

• MySQL 是开源的，目前隶属于 Oracle 旗下产品。
• MySQL 支持大型的数据库。可以处理拥有上千万条记录的大型数据库。
• MySQL 使用标准的 SQL 数据语言形式。
• MySQL 可以运行于多个系统上，并且支持多种语言。这些编程语言包括 C、C++、Python、Java、Perl、PHP、Eiffel、Ruby 和 TCL等。
• MySQL 是可以定制的，采用了 GPL 协议，可以修改源码来开发自己的 MySQL 系统。

** MySQL 数据库的可扩展性**

• 支持基于二进制日志的逻辑复制
• 存在多种第三方数据库中间件，支持读写分离及分库分表

(2) 适用场景

• Web网站系统
• 日志记录系统
• 数据仓库系统
• 嵌入式系统

(3)性能估算

单机性能

MySQL 支持大型数据库，

• 支持 5000 万条记录的数据仓库，
• 32 位系统表文件最大可支持 4GB，
• 64 位系统支持最大的表文件为8TB。

查询性能

• 主键查询： 千万级别数据 == 1-10ms

• 唯一索引查询： 千万级别数据 == 10-100ms

• 非唯一索引查询： 千万级别数据 == 100-1000ms

• 无索引数据： 百万级别数据 == 1000ms+

• 非插入的更新删除操作： 同查询性能

• 插入操作： 1w–10w tps (依赖配置优化)

集群

如果应用程序要向 MySQL 数据库插入上万条甚至更多的海量数据，对单机的 MySQL 数据库肯定压力很大，但是对于 MySQL 集群，在其中的一个 MySQL 节点插入这么大的数据，和单机 MySQL 服务器没有什么区别，那么这种情况下 MySQL 集群是如何提高性能和效率的呢？分库分表构建集群；

---

MySQL 与 MongoDB 的对比压测：

百万、千万级别的下不同查询量不同并发量的压测结果

数据库表中记录数总量在百万、千万级别的压测数据及结果如表所示。

亿级别的下不同查询量不同并发量的压测结果

数据库表中记录数总量在亿级别的压测数据及结果如表所示。

压测结果分析：
1）当每次查询数据量在500条时，无论表中数据总量千万或者亿级别，Mysql和MongoDB在100线程并发的情况下查询性能相当，表现良好，平均响应时间在500ms以内，TPS在230左右。
2）当每次查询数据量在5000条时，表中数据总量为千万级别时，MongoDB在50线程并发情况下查询性能不及Mysql 的一半，100线程并发情况查询性能都很差，平均响应时间在4500ms左右，表中数据总量为亿级别时，在50个及以上的并发情况下，MongoDB和Mysql性能都较差。
 在本案例简单数据模型下的时间范围内的等值查询应用场景下，MongoDB在高并发条件下的大数据量查询性能并没有比Mysql更好。另外还有一点需要注意的是，在本案例中，数据总量由百万级别到千万级别再到亿级别的变化过程中，对于查询性能的影响都不是很大，但对于查询数据量的数倍增长却十分敏感，所以在考量数据库查询性能的时候，也要重点考量应用的单次查询量的需求。
 尽管MongoDB在我们的这种应用场景下并没有达到我们预期的性能，我们也简单的调研了下Mysql和MongoDB对于内存的使用机制以及一些可能影响查询效率的内部配置。

(4) 优缺点

优点：

• 体积小、速度快、总体拥有成本低，开源；

• 核心程序采用完全的多线程编程。用多线程和C语言实现的 MySQL 能很容易充分利用CPU；

• MySQL 有一个非常灵活而且安全的权限和口令系统。当客户与 MySQL 服务器连接时，他们之间所有的口令传送被加密，而且 MySQL 支持主机认证；

• 支持大型的数据库， 可以方便地支持上千万条记录的数据库。作为一个开放源代码的数据库，可以针对不同的应用进行相应的修改；

• 拥有一个非常快速而且稳定的基于线程的内存分配系统，可以持续使用面不必担心其稳定性；

缺点：

• 不支持热备份；

• MySQL 最大的缺点是其安全系统，主要是复杂而非标准，另外只有到调用 MySQL admin 来重读用户权限时才发生改变；

• 没有一种存储过程(Stored Procedure)语言，这是对习惯于企业级数据库的程序员的最大限制；

• MySQL 的价格随平台和安装方式变化。Linux的 MySQL 如果由用户自己或系统管理员而不是第三方安装则是免费的，第三方案则必须付许可费。Unix 或Linux自行安装 免费 、Unix或Linux 第三方安装 收费。

(5) 工作原理架构

一、MySQL逻辑架构

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-e9Uhp2iu-1658461638235)(C:\Users\acer\AppData\Roaming\Typora\typora-user-images\image-20220117151510816.png)]

   MySQL逻辑架构整体分为三层，最上层为客户层，并非MySQL所独有，诸如，连接处理、授权认证、安全等功能均在这一层处理。

    MySQL大多数核心服务均在中间这一层，包括查询解析、分析、优化、缓存、内置函数（时间、数学、加密等），所有的跨存储引擎的功能也在这一层实现：存储过程、触发器、视图等。

    最下层为存储引擎，其负责MySQL中的数据存储和提取，中间的服务层通过API与存储引擎通信，这些API接口屏蔽了不同存储引擎的差异。

二、MySQL查询过程
当向MySQL发送一个请求的时候：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KNgh6Bc0-1658461638237)(C:\Users\acer\AppData\Roaming\Typora\typora-user-images\image-20220117151541651.png)]

1.客户端/服务端通信协议
MySQL客户端/服务端通信协议是“半双工”的：在任意时刻，要么是服务器向客户端发送数据，要么是客户端向服务器发送数据，这两个动作不能同时发生。一旦一端开始发送消息，另一端要接受完整个消息才能响应它，所以我们无法也无须将一个消息切成小块独立发送，也没有办法进行流量控制。

   客户端用一个单独的数据包将查询请求发送给服务器，所以当查询语句很长的时候，需要设置max_allowed_packet参数。但是需要的注意的是，如果查询实在是太大，服务端会拒绝接受更多数据并抛出异常。

  与之相反的是，服务器响应给用户的数据通常会很多，由多个数据包组成。但是当服务器响应客户端请求时，客户端必须完整的接受整个返回结果，而不能简单的只取前面几条结果，然后让服务器停止发送。因而在实际开发中，尽量保持查询简单且只返回必需的数据，减小通信间数据包的大小和数量是一个非常好的习惯，这也是查询中尽量避免使用SELECT * 以及加上LIMIT限制的原因之一。

2.查询缓存
在解析一个查询语句前，如果查询缓存是打开的，那么MySQL会检查这个查询语句是否命中查询缓存中的数据。如果当前查询恰好命中查询缓存，在检查一次用户权限后直接返回缓存中的结果。这种情况下，查询不会被解析，也不会生成执行计划，更不会执行。

   MySQL将缓存存放在一个引用表（类似于HashMap的数据结构），通过一个哈希值索引，这个哈希值通过查询本身、当前要查询的数据库、客户端协议版本号等一些可能影响结果的信息计算得来。所以两个查询在任何字符上的不同（空格、注释），都会导致缓存不会命中。

   如果查询中包含任何用户自定义函数、存储函数、用户变量、临时表、mysql库中的系统表，其查询结果都不会被缓存。比如函数NOW()或者CURRENT_DATE()会因为不同的查询时间，返回不同的查询结果，再比如包含CURRENT_USER或者CONNECION_ID()的查询语句会因为不同的用户而返回不同的结果，将这样的查询结果缓存起来没有任何的意义。

3.缓存失效
MySQL的查询缓存系统会跟踪查询中涉及的每个表，如果这些表（数据或结构）发生变化，那么和这张表相关的所有缓存数据都将失效。正因为如此，在任何的写操作时，MySQL必须将对应表的所有缓存都设置为失效。如果查询缓存非常大或者碎片很多，这个操作就可能带来很大的系统消耗，甚至导致系统僵死一会儿。而且查询缓存对系统的额外消耗也不仅仅在写操作，读操作也不例外：

        1.任何的查询语句在开始之前都必须经过检查，即使这条SQL语句永远不会命中缓存

        2.如果查询结果可以被缓存，那么执行完成后，会将结果存入缓存，也会带来额外的系统消耗

基于此，要知道并不是什么情况下查询缓存都会提高系统性能，缓存和失效都会带来额外消耗，只有当缓存带来的资源节约大于其本身消耗的资源时，才会给系统带来性能提升。但要如何评估打开缓存是否能够带来性能提升是一件非常困难的事情，。如果系统确实存在一些性能问题，可以尝试打开查询缓存，并在数据库设计上做一些优化：比如：

        1.用多个小表代替一个大表，注意不要过度设计

        2.批量插入代替循环单条插入

        3.合理控制缓存空间大小，一般来说其大小设置为几十兆比较合适

        4.可以通过SQL_CACHE和SQL_NO_CACHE来控制某个查询语句是否需要进行缓存

   不要轻易打开查询缓存，特别是写密集型应用。如果实在是忍不住，可以将query_cache_type 设置为DEMAND，这时只有加入SQL_CACH的查询才会走缓存，其他查询则不会，这样可以非常自由地控制哪些查询需要被缓存。

4.语法解析和预处理
MySQL通过关键字将SQL语句进行解析，并生成一颗对应的解析树。这个过程解析器主要通过语法规则来验证和解析。比如SQL中是否使用了错误的关键字或者关键字的顺序是否正确等等。预处理则会根据MySQL规则进一步检查解析树是否合法。比如检查要查询的数据表和数据列是否存在等等。

5.查询优化
语法树被认为是合法之后，并且有优化器将其转化成查询计划，多数情况下，一条查询可以有很多种执行方式，最后都返回相应的结果，优化器的作用就是找到这其中最好的执行计划。

  MySQL使用基于成本的优化器，它尝试预测一个查询使用某种执行计划时的成本，并选择其中成本最小的一个。在MySQL可以通过查询当前会话的last_query_cost的值来得到其计算当前查询的成本。（show status like 'last_query_cost'）

show status like 'last_query_cost';
+-------------+| Variable_name | Value |
+-------------+| Last_query_cost | 6391.799000 |

​ 示例中的结果表示优化器认为大概需要做6391个数据页的随机查找才能完成上面的查询。这个结果是根据一些列的统计信息计算得来的，这些统计信息包括：每张表或者索引的页面个数、索引的基数、索引和数据行的长度、索引的分布情况等等。

   有非常多的原因会导致MySQL选择错误的执行计划，比如统计信息不准确、不会考虑不受其控制的操作成本（用户自定义函数、存储过程）、MySQL认为的最优跟我们想的不一样（我们希望执行时间尽可能短，但MySQL值选择它认为成本小的，但成本小并不意味着执行时间短）等等。

MySQL的查询优化器是一个非常复杂的部件，它使用了非常多的优化策略来生成一个最优的执行计划：

1.重新定义表的关联顺序（多张表关联查询时，并不一定按照SQL中指定的顺序进行，但有一些技巧可以指定关联顺序）

2.优化MIN()和MAX()函数（找某列的最小值，如果该列有索引，只需要查找B+Tree索引最左端，反之则可以找到最大值）

3.提前终止查询（使用Limit时，查找到满足数量的结果集后会立即终止查询）

4.优化排序（在老版本MySQL会使用两次传输排序，即先读取行指针和需要排序的字段在内存中对其排序，然后再根据排序结果去读取数据行，而新版本采用的是单次传输排序，也就是一次读取所有的数据行，然后根据给定的列排序）

6.查询执行引擎
在完成解析和优化阶段以后，MySQL会生成对应的执行计划，查询执行引擎根据执行计划给出的指令逐步执行得出结果。整个执行过程的大部分操作均是通过调用存储引擎实现的接口来完成，这些接口被称为handler API。查询过程中的每一张表由一个handler实例表示，实际上，MySQL在查询优化阶段就为每一张表创建了一个handler实例，优化器可以根据这些实例的接口来获取表的相关信息，包括表的所有列名、索引统计信息等。存储引擎接口提供了非常丰富的功能，但其底层仅有几十个接口，这些接口像塔积木一样完成了一次查询的大部分操作。

7.返回结果给客户端
查询执行的最后一个阶段就是将结果返回给客户端。即使查询不到数据，MySQL仍然会返回这个查询的相关信息，比如该查询影响到的行数以及执行时间等等。

如果查询缓存被打开且这个查询可以被缓存，MySQL也会将结果存放到缓存中。

结果集返回客户端是一个增量且逐步返回的过程。有可能MySQL在生成第一条结果时，就开始向客户端逐步返回结果集了。这样服务端就无须存储太多结果而消耗过多内存，也可以让客户端第一时间获得返回结果。需要注意的是，结果集中的每一行都会以一个满足①中所描述的通信协议的数据包发送，再通过TCP协议进行传输，在传输过程中，可能对MySQL的数据包进行缓存然后批量发送。

三、MySQL整个查询执行过程

1.客户端向MySQL服务器发送一条查询请求

2.服务器首先先检查查询缓存，如果命中缓存，则立刻返回存储在缓存中的结果。否则进入下一级段

3.服务器进行SQL解析、预处理、再由优化器生成对应的执行计划

4.MySQL根据执行计划，调用存储引擎的API来执行查询

5.将结果返回给客户端，同时缓存查询结果

TiDB （开源，国产，分布式关系型数据库）

(1) 数据库介绍

[ TiDB ](https://github.com/pingcap/ TiDB ) 是 PingCAP 公司自主设计、研发的开源分布式关系型数据库，是一款同时支持在线事务处理与在线分析处理的融合型分布式数据库产品，具备水平扩容或者缩容、金融级高可用、实时 HTAP、云原生的分布式数据库、兼容 MySQL 5.7 协议和 MySQL 生态等重要特性。目标是为用户提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解决方案。

特点：

TiDB 高度兼容 MySQL 5.7 协议、MySQL 5.7 常用的功能及语法。MySQL 5.7 生态中的系统工具（PHPMyAdmin、Navicat、MySQL Workbench、mysqldump、Mydumper/Myloader）、客户端等均适用于 TiDB 。

但 TiDB 尚未支持一些 MySQL 功能，可能的原因如下：

• 有更好的解决方案，例如 JSON 取代 XML 函数。
• 目前对这些功能的需求度不高，例如存储流程和函数。
• 一些功能在分布式系统上的实现难度较大。

除此以外， TiDB 不支持 MySQL 复制协议，但提供了专用工具用于与 MySQL 复制数据

• 从 MySQL 复制：[ TiDB Data Migration (DM)](https://docs.pingcap.com/zh/ TiDB -data-migration/stable/overview) 是将 MySQL/MariaDB 数据迁移到 TiDB 的工具，可用于增量数据的复制。
• 向 MySQL 复制：[TiCDC](https://docs.pingcap.com/zh/ TiDB /v4.0/ticdc-overview) 是一款通过拉取 TiKV 变更日志实现的 TiDB 增量数据同步工具，可通过 [MySQL sink](https://docs.pingcap.com/zh/ TiDB /v4.0/ticdc-overview#sink-支持) 将 TiDB 增量数据复制到 MySQL。

(2) 适用场景

TiDB 适合高可用、强一致要求较高、数据规模较大等各种应用场景。 四大核心应用场景如下：

• 对数据一致性及高可靠、系统高可用、可扩展性、容灾要求较高的金融行业属性的场景

  众所周知，金融行业对数据一致性及高可靠、系统高可用、可扩展性、容灾要求较高。传统的解决方案是同城两个机房提供服务、异地一个机房提供数据容灾能力但不提供服务，此解决方案存在以下缺点：资源利用率低、维护成本高、RTO (Recovery Time Objective) 及 RPO (Recovery Point Objective) 无法真实达到企业所期望的值。 TiDB 采用多副本 + Multi-Raft 协议的方式将数据调度到不同的机房、机架、机器，当部分机器出现故障时系统可自动进行切换，确保系统的 RTO <= 30s 及 RPO = 0。

• 对存储容量、可扩展性、并发要求较高的海量数据及高并发的 OLTP 场景

  随着业务的高速发展，数据呈现爆炸性的增长，传统的单机数据库无法满足因数据爆炸性的增长对数据库的容量要求，可行方案是采用分库分表的中间件产品或者 NewSQL 数据库替代、采用高端的存储设备等，其中性价比最大的是 NewSQL 数据库，例如： TiDB 。 TiDB 采用计算、存储分离的架构，可对计算、存储分别进行扩容和缩容，计算最大支持 512 节点，每个节点最大支持 1000 并发，集群容量最大支持 PB 级别。

• Real-time HTAP 场景

  随着 5G、物联网、人工智能的高速发展，企业所生产的数据会越来越多，其规模可能达到数百 TB 甚至 PB 级别，传统的解决方案是通过 OLTP 型数据库处理在线联机交易业务，通过 ETL 工具将数据同步到 OLAP 型数据库进行数据分析，这种处理方案存在存储成本高、实时性差等多方面的问题。 TiDB 在 4.0 版本中引入列存储引擎 TiFlash 结合行存储引擎 TiKV 构建真正的 HTAP 数据库，在增加少量存储成本的情况下，可以同一个系统中做联机交易处理、实时数据分析，极大地节省企业的成本。

• 数据汇聚、二次加工处理的场景

  当前绝大部分企业的业务数据都分散在不同的系统中，没有一个统一的汇总，随着业务的发展，企业的决策层需要了解整个公司的业务状况以便及时做出决策，故需要将分散在各个系统的数据汇聚在同一个系统并进行二次加工处理生成 T+0 或 T+1 的报表。传统常见的解决方案是采用 ETL + Hadoop 来完成，但 Hadoop 体系太复杂，运维、存储成本太高无法满足用户的需求。与 Hadoop 相比， TiDB 就简单得多，业务通过 ETL 工具或者 TiDB 的同步工具将数据同步到 TiDB ，在 TiDB 中可通过 SQL 直接生成报表。

(3) 性能估算

近对比 TiDB 和 MySQL 在大表复杂join方面， TiDB 比MySQL快很多（至少三倍），这应该得益于 TiDB 的 分布式架构，把逻辑计算下推到各个数据节点并行执行导致的。

​ 由于 TiDB 有着很好的水平分布式扩展，突破了单实例容量的限制，和分库分表比，应该有着更好的优势。

TiDB Sysbench 性能对比测试报告

Point Select 性能

Threads	v5.2.2 TPS	v5.3.0 TPS	v5.2.2 95% latency (ms)	v5.3.0 95% latency (ms)	TPS 提升 (%)
300	267673.17	267516.77	1.76	1.67	-0.06
600	369820.29	361672.56	2.91	2.97	-2.20
900	417143.31	416479.47	4.1	4.18	-0.16

v5.3.0 对比 v5.2.2，Point Select 性能基本持平，略下降了 0.81%。

Update Non-index 性能

Threads	v5.2.2 TPS	v5.3.0 TPS	v5.2.2 95% latency (ms)	v5.3.0 95% latency (ms)	TPS 提升 (%)
300	39715.31	40041.03	11.87	12.08	0.82
600	50239.42	51110.04	20.74	20.37	1.73
900	57073.97	57252.74	28.16	27.66	0.31

v5.3.0 对比 v5.2.2，Update Non-index 性能基本持平，略上升了 0.95%。

Update Index 性能

Threads	v5.2.2 TPS	v5.3.0 TPS	v5.2.2 95% latency (ms)	v5.3.0 95% latency (ms)	TPS 提升 (%)
300	17634.03	17821.1	25.74	25.74	1.06
600	20998.59	21534.13	46.63	45.79	2.55
900	23420.75	23859.64	64.47	62.19	1.87

v5.3.0 对比 v5.2.2，Update Index 性能基本持平，略上升了 1.83%。

Read Write 性能

Threads	v5.2.2 TPS	v5.3.0 TPS	v5.2.2 95% latency (ms)	v5.3.0 95% latency (ms)	TPS 提升 (%)
300	3872.01	3848.63	106.75	106.75	-0.60
600	4514.17	4471.77	200.47	196.89	-0.94
900	4877.05	4861.45	287.38	282.25	-0.32

v5.3.0 对比 v5.2.2，Read Write 性能基本持平，略下降了 0.62%。