TIDB入门了解，对比MySql

爱被打了一巴掌 2023-06-15 11:19 53阅读 0赞

# TIDB是什么？MySql是什么？ #

**TiDB** 是 PingCAP 公司受 Google Spanner / F1 论文启发而设计的开源分布式 HTAP (Hybrid Transactional and Analytical Processing) 数据库，结合了传统的 [RDBMS][] 和[NoSQL][RDBMS] 的最佳特性。TiDB 兼容 MySQL，支持无限的水平扩展，具备**强一致性**和**高可用性**。TiDB 的目标是为 OLTP(Online Transactional Processing) 和 OLAP (Online Analytical Processing) 场景提供一站式的解决方案。

TiDB 是一个分布式 [NewSQL][RDBMS] 数据库。它支持水平弹性扩展、ACID 事务、标准 SQL、MySQL 语法和 MySQL 协议，具有数据强一致的高可用特性，是一个不仅适合 OLTP 场景还适合 OLAP 场景的混合数据库。

**MySQL**是一个关系型数据库管理系统，由瑞典MySQL AB 公司开发，目前属于 Oracle 旗下产品。MySQL 是最流行的关系型数据库管理系统之一，在 WEB 应用方面，MySQL是最好的 RDBMS (Relational Database Management System，关系数据库管理系统) 应用软件之一。  
MySQL是一种关系数据库管理系统，关系数据库将数据保存在不同的表中，而不是将所有数据放在一个大仓库内，这样就增加了速度并提高了灵活性。  
MySQL所使用的 SQL 语言是用于访问数据库的最常用标准化语言。MySQL 软件采用了双授权政策，分为社区版和商业版，由于其体积小、速度快、总体拥有成本低，尤其是开放源码这一特点，一般中小型网站的开发都选择 MySQL 作为网站数据库。

# TIDB适用场景；MySql适用场景： #

###### TIDB适用场景： ######

1.  原业务的MySql的业务逻辑遇到单机容量或者性能瓶颈时，可以考虑适用TiDB无缝替换MySql。
2.  大数据量下，MySql复杂查询很慢。
3.  大数据量下，数据增长很快，接近单机处理的极限，不想分库分表或者使用数据库中间件等对业务侵入性较大、对业务有约束的Sharding方案。
4.  大数据量下，有高并发实时写入、实时查询、实时统计分析的需求。
5.  有分布式事务、多数据中心的数据100%强一致性、auto-failover的高可用的需求。

###### MySql适用场景： ######

1.  Web网站系统
2.  日志记录系统
3.  数据仓库系统
4.  嵌入式系统

###### TIDB不适用场景： ######

1.  单机MySql能满足的场景用不到TiDB。
2.  数据条数少于5000W的场景下通常用不到TiDB，TiDB是为大规模的数据场景设计的。
3.  如果你的应用数据量小（所有数据千万级别行以下），且没有高可用、强一致性或者多数据中心复制等要求，那么就不适合适用TiDB。

###### MySql不适用场景 ######

1.  单机MySql无法满足的场景。
2.  数据条数大于5000W的场景下MySql通常无法满足。
3.  应用数据量特别大，请求次数频繁。

# TIDB和MySql的核心特点： #

###### TIDB核心特点： ######

1.  高度兼容MySql  
    大多数情况下，无需修改代码即可从MySql轻松迁移至TiDB，分库分表后的MySql集群亦可通过TiDB工具进行实时迁移。
2.  水平弹性扩展  
    通过简单地增加新节点即可实现TiDB的水平扩展，按需扩展吞吐或存储，轻松应对高并发、海量数据场景。
3.  分布式事务  
    TiDB 100% 支持标准的ACID事务。
4.  真正金融级高可用  
    相比于传统主从（M-S）复制方案，基于Raft的多数派选举协议可以提供金融级的100%数据强一致性保证，且在不丢失大多数读本的前提下，可以实现故障的自动恢复（auto-failover），无需人工介入。
5.  一站式HTAP解决方案  
    TiDB作为典型的OLTP（联机事务处理）行存数据库，同事兼具强大的OLAP（联机分析处理）性能，配合TiSpark，可提供一站式HTAP解决方案，一份存储同时处理OLTP&OLAP无需传统繁琐的[ETL][]过程。
6.  云原生SQL数据库  
    TiDB是为云而设计的数据库，同[Kubernetes][]深度耦合，支持公有云、私有云和混合云，使部署、配置和维护变得十分简单。  
    TiDB的设计目标是100%的OLTP场景和80%的OLAP场景，更复杂的OLAP分析可以通过TiSpark项目来完成。TiDB对业务没有任何侵入性，能优雅的替换传统的数据库中间件、数据库分表分库等Sharding方案。同时它也让开发运维人员不用关注数据库Scale的细节问题，专注于业务开发，极大的提升研发的生产力。

###### MySql核心特点： ######

1.  开源、免费、成本低
2.  性能高、移植性也好
3.  体积小，便于安装

# TiDB和MySql的差异： #

###### TiDB事务和MySql事物的差异 ######

###### MySql事务和TiDB事务对比 ######

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0l0aXNzb2hhcmR0b2c_size_16_color_FFFFFF_t_70]

在 TiDB 中执行的事务 b，返回影响条数是 1（认为已经修改成功），但是提交后查询，status 却不是事务 b 修改的值，而是事务 a 修改的值。

可见，MySql事务和TiDB事务存在这样的差异：**MySql事务中，可以通过影响行数，作为写入（或修改）是否成功的依据；而TiDB中，这却是不可行的！**

作为开发者我们需要考虑下面的问题：

同步RPC调用中，如果需要严格依赖影响条数以确认返回值，那将如何是好？  
多表操作中，如果需要严格依赖某个主表数据更新结果，作为是否更新（或写入）其他表的判断依据，那将如何是好？

原因分析及解决方案

*  **对于MySql，当更新某条记录时，会先获取该记录对应的行级锁（排它锁），获取成功则进行后续的事务操作，获取失败则阻塞等待。**
 *  **对于TiDB，使用Percolator事务模型：可以理解为乐观锁实现，事务开启、事务中都不会加锁，而是在提交时才加锁。**

其简要流程如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0l0aXNzb2hhcmR0b2c_size_16_color_FFFFFF_t_70 1]  
在事务提交的PreWrite阶段，当“锁检查”失败时：如果开启冲突重试，事务提交将会进行重试；如果未开启冲突重试，将会抛出写入冲突异常。

可见，对于MySql，由于在写入操作时加上了排他锁，变相将并行事务从逻辑上串行化；而对于TiDB，属于乐观锁模型，在事务提交时才加锁，并使用事务开启时获取的“全局时间戳”作为“锁检查”的依据。

所以，在业务面避免TiDB事务差异的本质在于避免锁冲突，即，当事务执行时，不产生别的事务时间戳（无其他事务并行）。处理方式为事务串行化。

TiDB事务串行化  
在业务层，可以借助分布式锁，实行串行化处理，如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0l0aXNzb2hhcmR0b2c_size_16_color_FFFFFF_t_70 2]  
基于Spring和分布式锁的事务管理器拓展  
在Spring生态下，spring-tx中定义了统一的事务管理器接口：PlatformTransactionManager，其中有获取事务（getTransaction）、提交（commit）、回滚（rollback）三个基本方法；使用装饰器模式，事务串行化组件可做如下设计：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0l0aXNzb2hhcmR0b2c_size_16_color_FFFFFF_t_70 3]  
其中，关键点有：

超时时间：为避免死锁，锁必须有超时时间；为避免锁超时导致事务并行，事务必须有超时时间，而且锁超时时间必须大于事务超时时间（时间差最好在秒级）。

加锁时机：TiDB中“锁检查”的依据是事务开启时获取的“全局时间戳”，所以加锁时机必须在事务开启前。

事务模板接口设计  
隐藏复杂的事务重写逻辑，暴露简单友好的API：

public interface LockTransactionTemplate { 
    
    	/** * 阻塞模式事务模板 * @param action 事务回调action * @return */
    	public <T> T lockableExecute(TransactionCallback<T> action, LockKeys<?>...LockKeys);
    }

/** * 非阻塞模式事务模板 * @param action 事务回调action * @return */
    	public <T> T lockableExecute(NonBlockingAcquireCallback<T> action, LockKeys<?>...LockKeys);

TiDB 查询和 MySQL 的差异  
在 TiDB 使用过程中，偶尔会有这样的情况，某几个字段建立了索引，但是查询过程还是很慢，甚至不经过索引检索。

索引混淆型（举例）  
表结构：

CREATE TABLE `t_test` (
          `id` bigint(20) NOT NULL DEFAULT '0' COMMENT '主键id',
          `a` int(11) NOT NULL DEFAULT '0' COMMENT 'a',
          `b` int(11) NOT NULL DEFAULT '0' COMMENT 'b',
          `c` int(11) NOT NULL DEFAULT '0' COMMENT 'c',
          PRIMARY KEY (`id`),
          KEY `idx_a_b` (`a`,`b`),
          KEY `idx_c` (`c`)
        ) ENGINE=InnoDB;

查询：如果需要查询 (a=1 且 b=1）或 c=2 的数据，在 MySQL 中，sql 可以写为：

SELECT id from t_test where (a=1 and b=1) or (c=2);

MySQL 做查询优化时，会检索到 idx\_a\_b 和 idx\_c 两个索引；但是在 TiDB（v2.0.8-9）中，这个 sql 会成为一个慢 SQL，需要改写为：

SELECT id from t_test where (a=1 and b=1) UNION SELECT id from t_test where (c=2);

小结：导致该问题的原因，可以理解为TiDB的sql解析还有优化空间。

冷热数据型（举例）  
表结构：

CREATE TABLE `t_job_record` (
          `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键id',
          `job_code` varchar(255) NOT NULL DEFAULT '' COMMENT '任务code',
          `record_id` bigint(20) NOT NULL DEFAULT '0' COMMENT '记录id',
          `status` tinyint(3) NOT NULL DEFAULT '0' COMMENT '执行状态:0 待处理',
          `execute_time` bigint(20) NOT NULL DEFAULT '0' COMMENT '执行时间（毫秒）',
          PRIMARY KEY (`id`),
          KEY `idx_status_execute_time` (`status`,`execute_time`),
          KEY `idx_record_id` (`record_id`)
        ) ENGINE=InnoDB COMMENT='异步任务job'

数据说明：

*  冷数据，status=1的数据（已经处理过的数据）；
 *  热数据，status=0并且execute\_time<=当前时间的数据。

慢查询：对于热数据，数据量一般不大，但是查询频率度很高，假设当前（毫秒级）时间为：1546361579646，则在MySql中，查询sql为：

SELECT * FROM t_job_record where status=0 and execute_time<= 1546361579646

这个在 MySQL 中很高效的查询，在 TiDB 中虽然也可从索引检索，但其耗时却不尽人意（百万级数据量，耗时百毫秒级）。

原因分析：在 TiDB 中，底层索引结构为 LSM-Tree，如下图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0l0aXNzb2hhcmR0b2c_size_16_color_FFFFFF_t_70 4]  
当从内存级的C0层查询不到数据时，会逐层扫描硬盘中各层；且merge操作为异步操作，索引数据更新会存在一定的延迟，可能存在无效索引。由于逐层扫描和异步merge，使得查询效率较低。

优化方式：尽可能缩小过滤范围，比如结合异步job获取记录频率，在保证不遗漏数据的前提下，合理设置execute\_time筛选区间，例如1小时，sql改写为：

SELECT * FROM t_job_record  where status=0 and execute_time>1546357979646  and execute_time<= 1546361579646

优化效果：耗时10毫秒级别（以下）。

关于查询的启发  
在基于TiDB的业务开发中，先摒弃传统关系型数据库带来的对sql先入为主的理解或经验，谨慎设计每一个sql，如DBA（数据库管理员）所提倡：**设计sql时务必关注执行计划，必要时请教DBA。**

和MySql相比，TiDB的底层存储和结构决定了其特殊性和差异性；但是，TiDB支持MySql协议，他们也存在一些共同之处，比如在TiDB中使用“预编译”和“批处理”，同样可以获得一定的性能提升。

服务端预编译  
在MySql中，可以使用PREPARE stmt\_name FROM preparable\_stm对sql语句进行预编译，然后使用EXECUTE stmt\_name \[USING @var\_name \[,@var\_name\]…\]执行预编译语句。如此，同一sql的多次操作，可以获得比常规sql更高得性能。

mysql-jdbc源码中，实现了标准的Statement和PreparedStatement的同时，还有一个ServerPreparedStatement实现，ServerPreparedStatement属于PreparedStatement的拓展，三者对比如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0l0aXNzb2hhcmR0b2c_size_16_color_FFFFFF_t_70 5]  
容易发现，PreparedStatement和Statement的区别主要区别在于参数处理，而对于发送数据包，调用服务器端的处理逻辑是一样（或类似）的；经测试，二者速度相当。其实PreparedStatement并不是服务器端预处理的；ServerPreparedStatement才是真正的服务器端预处理，速度也较PreparedStatement快；其使用场景一般是：频繁的数据库访问，sql数量有限（有缓存淘汰策略，使用不宜会导致两次IO）。

批处理：  
对于多条数据写入，常用sql为insert…values(…),(…);而对于多条数据更新，亦可以使用update…case…when…then…end来减少IO次数，但他们都有一个特点，数据条数越多，sql越复杂，sql解析成本也更高，耗时增长可能高于线性增长。而批处理，可以复用一条简单的sql，实现批量数据的写入或更新，为系统带来更低、更稳定的耗时。

对于批处理，作为客户端，java.sql.Statement 主要定义了两个接口方法，addBatch 和 executeBatch 来支持批处理。

批处理的简要流程说明如下：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0l0aXNzb2hhcmR0b2c_size_16_color_FFFFFF_t_70 6]  
经业务中实践，使用批处理方式的写入（或更新），比常规 insert … values(…),(…)（或 update … case … when… then… end）性能更稳定，耗时也更低。

# TiDB和MySql的整体架构： #

###### TiDB整体架构： ######

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0l0aXNzb2hhcmR0b2c_size_16_color_FFFFFF_t_70 7]

### TiDB Server ###

TiDB Server 负责接收 SQL 请求，处理 SQL 相关的逻辑，并通过 PD 找到存储计算所需数据的 TiKV 地址，与 TiKV 交互获取数据，最终返回结果。 TiDB Server 是无状态的，其本身并不存储数据，只负责计算，可以无限水平扩展，可以通过负载均衡组件（如LVS、HAProxy 或 F5）对外提供统一的接入地址。TiDB采用go语言编写。

### PD Server ###

Placement Driver (简称 PD) 是整个集群的管理模块，其主要工作有三个： 一是存储集群的元信息（某个 Key 存储在哪个 TiKV 节点）；二是对 TiKV 集群进行调度和负载均衡（如数据的迁移、Raft group leader 的迁移等）；三是分配全局唯一且递增的事务 ID。PD通过内嵌etcd来支持数据分布和容错。PD 采用go语言编写。

PD 是一个集群，需要部署奇数个节点，一般线上推荐至少部署 3 个节点。PD在选举的过程中无法对外提供服务，这个时间大约是3秒。

### TiKV Server ###

TiKV Server 负责存储数据，从外部看 TiKV 是一个分布式的提供事务的 Key-Value 存储引擎，基于Google Spanner, HBase 设计，但脱离了底层较为复杂的HDFS。通过RocksDB将key-value值存在本地地盘，使用 Raft 协议做复制，保持数据的一致性和容灾。存储数据的基本单位是 Region，每个 Region 负责存储一个 Key Range （从 StartKey 到 EndKey 的左闭右开区间）的数据，每个 TiKV 节点会负责多个 Region 。TiKV 使用 Raft 协议做复制，保持数据的一致性和容灾。副本以 Region 为单位进行管理，不同节点上的多个 Region 构成一个 Raft Group，互为副本。数据在多个 TiKV 之间的负载均衡由 PD 调度，这里也是以 Region 为单位进行调度。TiKV采用Rust语言编写。

### TiSpark ###

TiSpark 作为 TiDB 中解决用户复杂 OLAP 需求的主要组件，将 Spark SQL 直接运行在 TiDB 存储层上，同时融合 TiKV 分布式集群的优势，并融入大数据社区生态。至此，TiDB 可以通过一套系统，同时支持 OLTP 与 OLAP，免除用户数据同步的烦恼。

### TiDB Operator ###

TiDB Operator 提供在主流云基础设施（Kubernetes）上部署管理 TiDB 集群的能力。它结合云原生社区的容器编排最佳实践与 TiDB 的专业运维知识，集成一键部署、多集群混部、自动运维、故障自愈等能力，极大地降低了用户使用和管理 TiDB 的门槛与成本。

### syncer syncer通过binlog能方便地将 MySQL 的数据增量导入到 TiDB。 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0l0aXNzb2hhcmR0b2c_size_16_color_FFFFFF_t_70 8]

### TiDB-Binlog 将数据备份到其他数据库，也可以TiDB 集群故障时恢复。 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0l0aXNzb2hhcmR0b2c_size_16_color_FFFFFF_t_70 9]

###### MySql整体架构： ######

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0l0aXNzb2hhcmR0b2c_size_16_color_FFFFFF_t_70 10]

### MySQL向外提供的交互接口（Connectors） ###

Connectors组件，是MySQL向外提供的交互组件，如java,.net,php等语言可以通过该组件来操作SQL语句，实现与SQL的交互。

### 管理服务组件和工具组件(Management Service & Utilities) ###

提供对MySQL的集成管理，如备份(Backup),恢复(Recovery),安全管理(Security)等

### 连接池组件(Connection Pool) ###

负责监听对客户端向MySQL Server端的各种请求，接收请求，转发请求到目标模块。每个成功连接MySQL Server的客户请求都会被  
创建或分配一个线程，该线程负责客户端与MySQL Server端的通信，接收客户端发送的命令，传递服务端的结果信息等。

### SQL接口组件(SQL Interface) ###

接收用户SQL命令，如DML,DDL和存储过程等，并将最终结果返回给用户。

### 查询分析器组件(Parser) ###

首先分析SQL命令语法的合法性，并尝试将SQL命令分解成数据结构，若分解失败，则提示SQL语句不合理。

### 优化器组件（Optimizer） ###

对SQL命令按照标准流程进行优化分析。

### 缓存主件（Caches & Buffers） ###

缓存和缓冲组件

### MySQL存储引擎 ###

1.  什么是MySQL存储引擎？  
    MySQL属于关系型数据库，而关系型数据库的存储是以表的形式进行的，对于表的创建，数据的存储，检索，更新等都是由MySQL  
    存储引擎完成的，这也是MySQL存储引擎在MySQL中扮演的重要角色。  
    研究过SQL Server和Oracle的读者可能很清楚，这两种数据库的存储引擎只有一个，而MySQL的存储引擎种类比较多，如MyISAM存储  
    引擎，InnoDB存储引擎和Memory存储引擎。  
    MySQL之所以有多种存储引擎，是因为MySQL的开源性决定的。MySQL存储引擎，从种类上来说，大致可归结为官方存储引擎和第三  
    方存储引起。MySQL的开源性，允许第三方基于MySQL骨架，开发适合自己业务需求的存储引擎。
2.  MySQL存储引擎作用？  
    MySQL存储引擎在MySQL中扮演重要角色，其作比较重要作用，大致归结为如下两方面：  
    作用一：**管理表创建，数据检索，索引创建等**  
    作用二：**满足自定义存储引擎开发。**
3.  MySQL引擎种类？  
    不同种类的存储引擎，在存储表时的存储引擎表机制也有所不同，从MySQL存储引擎种类上来说，可以分为官方存储引擎和第三方存储引擎。  
    当前，也存在多种MySQL存储引擎，如MyISAM存储引擎，InnoDB存储引擎，NDB存储引擎，Archive存储引擎，Federated存储引擎，Memory  
    存储引擎，Merge存储引擎，Parter存储引擎，Community存储引擎，Custom存储引擎和其他存储引擎。  
    其中，比较常用的存储引擎包括InnoDB存储引擎，MyISAM存储引擎和Momery存储引擎。
4.  几种典型MySQL存储引擎比较？

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0l0aXNzb2hhcmR0b2c_size_16_color_FFFFFF_t_70 11]

### 物理文件（File System） ###

实际存储MySQL 数据库文件和一些日志文件等的系统，如Linux，Unix,Windows等。

# TiDB原理和MySql原理 #

###### [TiDB原理][TiDB] ######

![在这里插入图片描述][20191123143230865.png]  
TiDB 架构是 SQL 层和 KV 存储层分离，相当于 InnoDB 插件存储引擎与 MySQL 的关系。从下图可以看出整个系统是高度分层的，最底层选用了当前比较流行的存储引擎 RocksDB，RockDB 性能很好但是是单机的，为了保证高可用所以写多份，上层使用 Raft 协议来保证单机失效后数据不丢失不出错。保证有了比较安全的 KV 存储的基础上再去构建多版本，再去构建分布式事务，这样就构成了存储层 TiKV。有了 TiKV，TiDB 层只需要实现 SQL 层，再加上 MySQL 协议的支持，应用程序就能像访问 MySQL 那样去访问 TiDB 了。

###### [MySql原理][MySql] ######

在上面的"MySql整体架构"基本上都讲过了，再看一下别人写的吧！  
[时光传送门][MySql]

[RDBMS]: https://blog.csdn.net/belalds/article/details/84029384
[ETL]: https://www.cnblogs.com/yjd_hycf_space/p/7772722.html
[Kubernetes]: http://www.dockone.io/article/932
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0l0aXNzb2hhcmR0b2c_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20191122160405987.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0l0aXNzb2hhcmR0b2c=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0l0aXNzb2hhcmR0b2c_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20191122161836301.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0l0aXNzb2hhcmR0b2c=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0l0aXNzb2hhcmR0b2c_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20191122171203937.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0l0aXNzb2hhcmR0b2c=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0l0aXNzb2hhcmR0b2c_size_16_color_FFFFFF_t_70 3]: https://img-blog.csdnimg.cn/20191122171817862.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0l0aXNzb2hhcmR0b2c=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0l0aXNzb2hhcmR0b2c_size_16_color_FFFFFF_t_70 4]: https://img-blog.csdnimg.cn/20191122175655687.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0l0aXNzb2hhcmR0b2c=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0l0aXNzb2hhcmR0b2c_size_16_color_FFFFFF_t_70 5]: https://img-blog.csdnimg.cn/20191123090921172.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0l0aXNzb2hhcmR0b2c=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0l0aXNzb2hhcmR0b2c_size_16_color_FFFFFF_t_70 6]: https://img-blog.csdnimg.cn/20191123105753489.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0l0aXNzb2hhcmR0b2c=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0l0aXNzb2hhcmR0b2c_size_16_color_FFFFFF_t_70 7]: https://img-blog.csdnimg.cn/20191123115010771.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0l0aXNzb2hhcmR0b2c=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0l0aXNzb2hhcmR0b2c_size_16_color_FFFFFF_t_70 8]: https://img-blog.csdnimg.cn/2019112312001011.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0l0aXNzb2hhcmR0b2c=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0l0aXNzb2hhcmR0b2c_size_16_color_FFFFFF_t_70 9]: https://img-blog.csdnimg.cn/20191123141005404.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0l0aXNzb2hhcmR0b2c=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0l0aXNzb2hhcmR0b2c_size_16_color_FFFFFF_t_70 10]: https://img-blog.csdnimg.cn/20191123141548413.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0l0aXNzb2hhcmR0b2c=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0l0aXNzb2hhcmR0b2c_size_16_color_FFFFFF_t_70 11]: https://img-blog.csdnimg.cn/20191123142347622.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0l0aXNzb2hhcmR0b2c=,size_16,color_FFFFFF,t_70
[TiDB]: http://www.sohu.com/a/138003618_736949
[20191123143230865.png]: https://img-blog.csdnimg.cn/20191123143230865.png
[MySql]: https://www.2cto.com/database/201801/715716.html