文章目录

• 前言
• 一、数据库基本概念
• • 1.什么是数据库
  • 2.SQL和 MySQL的区别
  • 3.数据库的三大范式
• 二、数据库索引
• • 1.为什么要使用索引
  • 2.什么时候使用索引
  • 3. 索引中的数据结构与算法
  • • Hash索引：
    • 位图索引
    • B树索引：
    • B+树索引：
    • B+树跟B树的比较：
    • B+树跟Hush索引的区别
  • 4.MySql的最左前缀匹配原则
  • 5.聚簇索引
• 三.数据库的优化
• • 1.结构优化
  • 2.分库分表
  • 3.MySql主从复制
  • • 主从复制的作用
    • 主从复制的原理
    • 基于主从复制的读写分离
• 四.数据库事务
• • ACID规则：
  • 事务状态：
  • **事务相互影响**：
  • 隔离级别：
• 五.锁模式
• • 锁的分类：
  • 与事务隔离级别的关系：
  • 解决死锁的方式
  • 乐观锁与悲观锁
• 四.Redis
• • 1.对Redis的简单理解
  • 2.Redis的数据类型
  • 3.Redis的淘汰策略
• 总结

前言

数据库作为每一个后端程序员都必须学习的东西，有必要写一个专辑总结一下知识点，也方便回顾知识点和以后的面试，内容不涉及SQL语句。

提示：以下是本篇文章正文内容，仅供参考

一、数据库基本概念

1.什么是数据库

数据库（DB）其实就是一堆储存文件，存东西的地方而已。
而我们熟知的MySQL、SQL Server、Oracle、Redis等叫做数据库管理系统（DBMS）。
数据库可以分为：关系型数据库和非关系型数据库

2.SQL和 MySQL的区别

这是一个很多新手都很迷惑的概念，可以这样理解：
SQL就是一门语言，操作关系型数据库用的，可以用来增删改查。
而 MySQL是一个软件，像一些简单的操作总不能每次都通过代码查询吧，所以通过这个软件就可以通过鼠标点击来实现SQL查询的功能。

3.数据库的三大范式

数据库三范式只是基本理念，由此可建立冗余较小、结构较合理的表结构，但实际设计中还是要根据需求实际情况实际分析设计，兼顾性能和需求方面的考虑，无需一昧追求满足三范式

二、数据库索引

1.为什么要使用索引

优势：
1.通过创建唯一性索引，可以保证数据库表中每一行数据的唯一性。
2.可以提高数据检索的效率，降低数据库的IO成本，类似于书的目录。
3.通过索引列对数据进行排序，降低数据排序的成本，降低了CPU的消耗。
4.被索引的列会自动进行排序，包括【单列索引】和【组合索引】，只是组合索引的排序要复杂一些。
5.如果按照索引列的顺序进行排序，对应order by语句来说，效率就会提高很多。
劣势：
1.空间上：索引需要占 物理空间，除了数据表占数据空间之外，每一个索引还要占一定的物理空间，如果要建立聚簇索引，那么需要的空间就会更大。
2.时间上：索引虽然会提高查询效率，但是会降低更新表的效率。比如每次对表进行增删改操作，MySQL不仅要保存数据，还有保存或者更新对应的索引文件。

2.什么时候使用索引

1. 在 查询中很少使用 或者参考的列不要创建索引。由于这些列很少使用到，增加索引反而会降低系统的维护速度和增大空间需求。
2. 只有很少数据值的列也不应该增加索引。由于这些列的取值很少，区分度太低，例如人事表中的性别，在查询时，需要在表中搜索的数据行的比例很大。增加索引，并不能明显加快检索速度。
3. 定义为 text、image 和 bit 数据类型的列不应该增加索引。这是因为，这些列的数据量要么相当大，要么取值很少。
4. 当修改性能远远大于检索性能 时，不应该创建索引。这时因为，二者是相互矛盾的，当增加索引时，会提高检索性能，但是会降低修改性能。
5. 定义有外键 的数据列一定要创建索引。

3. 索引中的数据结构与算法

数据库索引根据结构分类，主要有 B 树索引、Hash 索引 和 位图索引 三种。

Hash索引：

哈希索引采用一定的 哈希算法（常见哈希算法有 直接定址法、平方取中法、折叠法、除数取余法、随机数法），将数据库字段数据转换成定长的 Hash 值，与这条数据的行指针一并存入 Hash 表的对应位置，如果发生 Hash 碰撞（两个不同关键字的 Hash 值相同），则在对应 Hash 键下以 链表形式 存储。

检索时不需要类似 B+ 树那样从根节点到叶子节点逐级查找，只需一次哈希算法即可立刻定位到相应的位置，速度非常快，平均检索时间为 O(1)。

位图索引

B 树索引擅长于处理包含许多不同值的列，但是在处理基数较小的列时会变得很难使用。如果用户查询的列的基数非常的小， 即只有几个固定值，如性别、婚姻状况、行政区等等，要么不使用索引，查询时一行行扫描所有记录，要么考虑建立位图索引。当进行数据查找时，只要查找相关位图中的所有 1 值即可（可根据查询需求进行与、或运算）。

B树索引：

一棵 m 阶 B-Tree 的特性如下：

• 每个结点最多 m 个子结点；
• 除了根结点和叶子结点外，每个结点最少有 m/2（向上取整）个子结点；
• 所有的叶子结点都位于同一层；
• 每个结点都包含 k 个元素（关键字），这里 m/2≤k<m，这里 m/2 向下取整；
• 每个节点中的元素（关键字）从小到大排列；
• 每个元素子左结点的值，都小于或等于该元素，右结点的值都大于或等于该元素。

B+树索引：

特点：

• 所有的非叶子结点只存储关键字信息；
• 所有具体数据都存在叶子结点中；
• 所有的叶子结点中包含了全部元素的信息；
• 所有叶子节点之间都有一个链指针。
  这个是最常用的结构

B+树跟B树的比较：

B+树跟Hush索引的区别

• Hash 索引进行等值查询更快（一般情况下），但是却无法进行范围查询；
• Hash 索引不支持使用索引进行排序；
• Hash索引不支持模糊查询以及多列索引的最左前缀匹配，原理也是因为 Hash 函数的不可预测；
• Hash 索引任何时候都避免不了回表查询数据，而B+ 树在符合某些条件（聚簇索引，覆盖索引等）的时候可以只通过索引完成查询；
• Hash索引虽然在等值查询上较快，但是不稳定，性能不可预测，当某个键值存在大量重复的时候，发生 Hash 碰撞，此时效率可能极差；而 B+ 树的查询效率比较稳定，对于所有的查询都是从根结点到叶子结点，且树的高度较低。

4.MySql的最左前缀匹配原则

在 MySQL 建立 联合索引（多列索引） 时会遵守最左前缀匹配原则，即 最左优先，在检索数据时从联合索引的最左边开始匹配。例如有一个 3列索引（a,b,c），则已经对（a）、（a,b）、（a,b,c）上建立了索引。所以在创建 多列索引时，要根据业务需求，where 子句中
使用最频繁 的一列放在最左边。根据最左前缀匹配原则，MySQL 会一直向右匹配直到遇到 范围查询（>、<、between、like）就停止匹配，比如采用查询条件where a = 1 and b = 2 and c > 3 and d = 4 时，如果建立（a,b,c,d）顺序的索引，d是用不到索引的，如果建立（a,b,d,c）的索引则都可以用到，并且 where 子句中 a、b、d 的顺序可以任意调整。如果建立的索引顺序是 （a,b） ，那么根据最左前缀匹配原则，直接采用查询条件 where b = 1 是无法利用到索引的。

5.聚簇索引

聚簇索引，又称 聚集索引， 首先并不是一种索引类型，而是一种数据存储方式。具体的，聚簇索引指将 数据存储 和 索引 放到一起，找到索引也就找到了数据。

MySQL 里只有 INNODB 表支持聚簇索引，INNODB 表数据本身就是聚簇索引，非叶子节点按照主键顺序存放，叶子节点存放主键以及对应的行记录。所以对 INNODB 表进行全表顺序扫描会非常快。
特点
1.因为索引和数据存放在一起，所以具有更高的检索效率；
2.相比于非聚簇索引，聚簇索引可以减少磁盘的 IO 次数；
3.表的物理存储依据聚簇索引的结构，所以一个数据表只能有一个聚簇索引，但可以拥有多个非聚簇索引；
4.一般而言，会在频繁使用、排序的字段上创建聚簇索引。

三.数据库的优化

1.结构优化

1. 将字段很多的表分解成多个表
   对于字段较多的表，如果有些字段的使用频率很低，可以将这些字段分离出来形成新表。
2. 增加中间表
   对于需要经常 联合查询 的表，通过建立中间表以提高查询效率，具体地，将需要通过联合查询的数据插入到中间表中，然后将原来的联合查询改为对中间表的查询。
3. 增加冗余字段
   大家都知道设计数据表时应尽量遵循范式理论的规约，尽可能的减少冗余字段，让数据库设计看起来精致、优雅。但是，表的规范化程度越高，表和表之间的关系越多，需要连接查询的情况也就越多，性能也就越差，所以合理的加入冗余字段可以提高查询速度。

2.分库分表

数据库中的数据量不一定是可控的，随着时间和业务的发展，库中的表会越来越多，表中的数据量也会越来越大，相应地数据操作，例如 增删改查的开销 也会越来越大；另外，若不进行分布式部署，而一台服务器的 资源 （CPU、磁盘、内存、IO 等）是有限的，最终数据库所能承载的数据量、数据处理能力都将遭遇瓶颈。所以，从 性能 和 可用性 角度考虑，会进行数据库拆分处理，具体地说，把原本存储于一个库的数据分块存储到多个库上，把原本存储于一个表的数据分块存储到多个表上，即 分库分表。还可以增加默认查询条件，比如聊天记录，默认一周内，从而增加查询效率

缺点：
1.事务问题

分库分表后，就成了分布式事务。如果依赖数据库本身的分布式事务管理功能去执行事务，将付出高昂的性能代价； 如果由应用程序去协助控制，形成程序逻辑上的事务，又会造成编程方面的负担。

2.跨库跨表的 JOIN 问题

在执行了分库分表之后，难以避免会将原本逻辑关联性很强的数据划分到不同的表、不同的库上，这时，表的关联操作将受到限制，我们无法 JOIN 位于不同分库的表，也无法 JOIN 分表粒度不同的表，结果原本一次查询能够完成的业务，可能需要多次查询才能完成。

3.额外的数据管理负担和数据运算压力

额外的数据管理负担，最为常见的是数据的 定位问题 和数据的 增删改查 的重复执行问题，这些都可以通过应用程序来解决，但必然会引起额外的逻辑运算。

3.MySql主从复制

主从复制是指将 主数据库（Master）中的 DDL 和 DML 操作通过二进制日志传输到 从数据库（Slave） 上，然后将这些日志重新执行（重做），从而使得从数据库的数据与主数据库保持一致。MySQL 支持单向、异步复制，复制过程中一个服务器充当主服务器，而一个或多个其它服务器充当从服务器。

主从复制的作用

1. 当主数据库出现问题时，可以切换到从数据库；
2. 可以进行数据库层面的读写分离，实现负载均衡；
3. 可以在从数据库上进行实时数据备份。

主从复制的原理

MySQL 的主从复制是一个 异步 的复制过程（一般情况下感觉是实时的），数据将从一个 MySQL 数据库（Master）复制到另外一个 MySQL 数据库（Slave），在 Master 与 Slave 之间实现整个主从复制的过程是由三个线程参与完成的，其中有两个线程（SQL 线程和 I/O 线程）在 Slave 端，另外一个线程（ I/O 线程）在 Master 端。

1. Master 端：打开二进制日志（binlog ）记录功能 —— 记录下所有改变了数据库数据的语句，放进 Master 的 binlog 中；

2. Slave 端：开启一个 I/O 线程 —— 负责从 Master上拉取 binlog 内容，放进自己的中继日志（Relay log）中；

3. Slave 端：SQL 执行线程 —— 读取 Relay log，并顺序执行该日志中的 SQL 事件。

下面具体举例：

【文件描述】
主库:
binlog 二进制日志文件
从库:
relaylog 中继日志
master.info 主库信息文件
relaylog.info relaylog应用的信息
主库:
Binlog_Dump Thread : DUMP_T – 二进制转储线程，主从连接后把二进制日志发送给从库
从库:
slave_IO_Thread : IO_T – 接到主库，向主库发生请求更新binlog
slave_SQL_Thread : SQL_T – 读取从库的中继日志，并且执行日志中的事件

1. 从库执行change master to 命令(主库的连接信息+复制的起点)
2. 从库会将以上信息,记录到master.info文件
3. 从库执行 start slave 命令,立即开启IO_T和SQL_T
4. 从库 IO_T,读取master.info文件中的信息 获取到IP,port,User,Pass,binlog的位置信息
5. 从库IO_T请求连接主库,主库专门提供一个DUMP_T,负责和IO_T交互
6. IO_T根据binlog的位置信息或(GTID),请求主库新的binlog
7. 主库通过DUMP_T将最新的binlog,通过网络TP(传送)给从库的IO_T
8. IO_T接收到新的binlog日志,存储到TCP/IP缓存,立即返回ACK给主库,并更新master.info
9. IO_T将TCP/IP缓存中数据,转储到磁盘relaylog中.
10. SQL_T读取relay.info中的信息,获取到上次已经应用过的relaylog的位置信息
11. SQL_T会按照上次的位置点回放最新的relaylog,再次更新relay.info信息
12. 从库会自动清除应用过relaylog(中继日志文件),避免占用过多的磁盘空间

基于主从复制的读写分离

MySQL 读写分离的实现方式主要基于 主从复制，通过 路由的方式 使应用对数据库的写请求只在 Master 上进行，读请求在 Slave 上进行。

具体地，有以下四种实现方案：

方案一：基于 MySQL proxy 代理

在应用和数据库之间增加 代理层，代理层接收应用对数据库的请求，根据不同请求类型（即是读 read 还是写 write）转发到不同的实例，在实现读写分离的同时可以实现负载均衡。MySQL 的代理最常见的是 mysql-proxy、cobar、mycat、Atlas 等。

方案二：基于应用内路由

基于应用内路由的方式即为在应用程序中实现，针对不同的请求类型去不同的实例执行 SQL。

具体实现可基于 spring 的 aop：用 aop 来拦截 spring 项目的 dao 层方法，根据方法名称就可以判断要执行的类型，进而动态切换主从数据源。

方案三：基于 MySQL-Connector-Java 的 JDBC 驱动方式

Java 程序通过在连接 MySQL 的 JDBC 中配置主库与从库等地址，JDBC 会自动将读请求发送给从库，将写请求发送给主库，此外， MySQL 的 JDBC 驱动还能够实现多个从库的负载均衡。

方案四：基于 sharding-jdbc 的方式

sharding-sphere 是强大的读写分离、分表分库中间件，sharding-jdbc 是 sharding-sphere 的核心模块。

四.数据库事务

数据库的 事务（Transaction）是一种机制、一个操作序列，包含了一组数据库操作命令，其执行的结果必须使数据库从一种一致性状态变到另一种一致性状态。事务把所有的命令作为一个整体一起向系统提交或撤销操作请求，即这一组数据库命令要么都执行，要么都不执行，因此事务是一个不可分割的工作逻辑单元。如果任意一个操作失败，那么整组操作即为失败，会回到操作前状态或者是上一个节点。

因此，事务是保持 逻辑数据一致性 和 可恢复性 的重要利器。而锁是实现事务的关键，可以保证事务的完整性和并发性

ACID规则：

• 原子性：顾名思义，事务最小的处理单元，不能再分，要么全部执行，要么都不执行
• 一致性：事务前后数据的完整性必须保持一致
• 隔离性：不同并发的事务相互独立，不被彼此干扰
• 持久性：数据的改变是持久的，不受故障的影响

事务状态：

事务在其整个生命周期中会经历不同的状态

• 活跃状态：所有正在执行的事务的初始态。
• 部分提交状态：由于其所做的 更改 存储在 主内存的缓冲区 中，所以叫做部分提交
• 失败状态：如果某个检查在活动状态下失败，在活动状态或部分提交状态发生一些错误，并且事务无法进一步执行，则事务进入失败状态。
• 中止状态：如果任何事务已达到失败状态，则恢复管理器将数据库回滚到开始执行的原始状态。
• 提交状态：如果所有操作成功执行，则来自 部分提交状态 的事务进入提交状态。无法从此状态回滚，它是一个新的 一致状态。

事务相互影响：

• 脏读（Dirty Read）

一个事务读取了另一个事务未提交的数据。

• 不可重复读（Non-repeatable Read）

就是在一个事务范围内，两次相同的查询会返回两个不同的数据，这是因为在此间隔内有其他事务对数据进行了修改。

• 幻读（Phantom Read）

幻读是指当事务 不是独立执行时 发生的一种现象，例如有一个事务对表中的数据进行了修改，这种修改涉及到表中的全部数据行，同时，第一个事务也修改这个表中的数据，这种修改是向表中 插入一行新数据。那么，第一个事务的用户发现表中还有没有修改的数据行，就好像发生了幻觉一样。

• 丢失更新（Lost Update）

两个事务同时读取同一条记录，事务 A 先修改记录，事务 B 也修改记录（B 是不知道 A 修改过），当 B 提交数据后， 其修改结果覆盖了 A 的修改结果，导致事务 A 更新丢失。

隔离级别：

为了尽可能的避免上述事务之间的相互影响，从而达到事务的四大特性，SQL 标准定义了 4 种不同的事务隔离级别（TRANSACTION ISOLATION LEVEL），即 并发事务对同一资源的读取深度层次，由低到高依次是 读取未提交（READ-UNCOMMITTED）、读取已提交（READ-COMMITTED）、可重复读（REPEATABLE-READ）、可串行化（SERIALIZABLE），这 4 个级别与事务相互间影响问题对应如下：

• 读取未提交

最低的隔离级别，一个事务可以读到另一个事务未提交的结果，所有的并发事务问题都会发生。

• 读取已提交

只有在事务提交后，其更新结果才会被其他事务看见，可以解决 脏读问题，但是不可重复读或幻读仍有可能发生。Oracle 默认采用的是该隔离级别。

• 可重复读

在一个事务中，对于同一份数据的读取结果总是相同的，无论是否有其他事务对这份数据进行操作，以及这个事务是否提交，除非数据是被本身事务自己所修改。可以解决 脏读、不可重复读。MySQL 默认采用可重复读隔离级别。

• 可串行化

事务 串行化执行，隔离级别最高，完全服从 ACID，牺牲了系统的并发性，也就是说，所有事务依次逐个执行，所以可以解决并发事务的所有问题。

五.锁模式

锁的分类：

共享锁（S）：又叫 他读锁。可以并发读取数据，但不能修改数据。也就是说当数据资源上存在共享锁时，所有的事务都不能对该数据进行修改，直到数据读取完成，共享锁释放。

排它锁（X）：又叫 独占锁、写锁。对数据资源进行增删改操作时，不允许其它事务操作这块资源，直到排它锁被释放，从而防止同时对同一资源进行多重操作。

更新锁（U）：防止出现 死锁 的锁模式，两个事务对一个数据资源进行先读取再修改的情况下，使用共享锁和排它锁有时会出现死锁现象，而使用更新锁就可以避免死锁的出现。
资源的更新锁一次只能分配给一个事务，如果需要对资源进行修改，更新锁会变成排它锁，否则变为共享锁。

意向锁：表示 SQL Server 需要在 层次结构中的某些底层资源上 获取共享锁或排它锁。例如，放置在 表级 的 共享意向锁 表示事务打算在表中的页或行上放置共享锁。在表级设置意向锁可防止另一个事务随后在包含那一页的表上获取排它锁。
意向锁可以提高性能，因为 SQL Server 仅在 表级 检查意向锁来确定事务是否可以安全地获取该表上的锁，而无须检查表中的每行或每页上的锁以确定事务是否可以锁定整个表。
意向锁包括意向共享 (IS)、意向排它 (IX) 以及与意向排它共享 (SIX)。

架构锁：在执行 依赖于表架构的操作 时使用。架构锁的类型为：架构修改 (Sch-M) 和架构稳定性 (Sch-S)，执行表的数据定义语言 （DDL）操作（例如添加列或除去表）时使用架构修改锁，当编译查询时，使用架构稳定性锁。

大容量更新锁（BU）：向表中大容量复制数据并指定了 TABLOCK 提示时使用。 大容量更新锁允许进程将数据并发地大容量复制到同一表，同时防止其它不进行大容量复制数据的进程访问该表。

与事务隔离级别的关系：

在 读取未提交 隔离级别下，读取数据不需要加 共享锁，这样就不会跟被修改的数据上的 排他锁 冲突；

在 读取已提交 隔离级别下，读操作需要加 共享锁，但是在语句执行完以后释放共享锁；

在 可重复读 隔离级别下，读操作需要加 共享锁，但是在事务提交之前并不释放共享锁，也就是必须等待事务执行完毕以后才释放共享锁；

可串行化 是限制性最强的隔离级别，因为该级别 锁定整个范围的键，并一直持有锁，直到事务完成。

解决死锁的方式

• 如果不同程序并发存取多个表，尽量约定 以相同的顺序访问表，可以大大降低死锁机会；
• 在同一个事务中，尽可能做到 一次锁定所需要的所有资源，减少死锁产生概率；
• 对于非常容易产生死锁的业务部分，可以尝试使用 升级锁定颗粒度，通过 表级锁 定来减少死锁产生的概率。

乐观锁与悲观锁

• 悲观锁：假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作。在查询完数据的时候就把事务锁起来，直到提交事务。这对于长事务来讲，可能会严重影响系统的并发处理能力。实现方式：使用数据库中的锁机制。

• 乐观锁：假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性。乐观锁适用于 读多写少 的应用场景，这样可以提高吞吐量。实现方式：一般会使用版本号机制或 CAS 算法实现

四.Redis

1.对Redis的简单理解

Redis，全称为 Remote Dictionary Server，本质上是一个 Key-Value 类型的内存数据库，整个数据库统统加载在内存当中进行操作，定期通过异步操作把数据库数据写入磁盘或把修改操作写入追加的记录文件，并且在此基础上实现 Master-Slave（主从）同步。它支持存储的 Value 类型多样，包括 String（字符串）、List（链表）、Set（集合）、zset（sorted set —— 有序集合）和 Hash（哈希类型），这些数据类型都支持 push/pop、add/remove 及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。

Redis 的主要缺点是数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，因此 Redis 适合的场景主要局限在较小数据量的高性能操作和运算上。虽然 Redis 文件事件处理器以单线程方式运行，但是通过使用 I/O 多路复用程序 来监听多个套接字，文件事件处理器既实现了高性能的网络通信模型，又可以很好地与 Redis 服务器中其他同样以单线程运行的模块进行对接，这保持了 Redis 内部单线程设计的简单性。

2.Redis的数据类型

1. String（字符串），是 Redis 最基本的数据类型，二进制安全的，可以包含任何数据，比如 JPG 图片或者序列化的对象，最大能存储 512 MB。
2. Hash（哈希），是一个键值对（key => value）集合，特别适合用于存储对象。
3. List（列表），Redis 列表是简单的字符串列表，按照插入顺序排序，可以添加一个元素到列表的头部（左边）或者尾部（右边）。
4. Set（集合），是 String 类型的无序集合，通过哈希表实现，添删查找操作的复杂度都是 O(1)。
5. Sorted set（有序集合），和 Set 一样也是 String 类型元素的集合，且不允许元素重复， 不同的是每个元素都会关联一个 Double 类型的分数（可重复）， 通过此分数来为集合中的成员进行从小到大的排序。

3.Redis的淘汰策略

LRU算法还是很出名的，其他的到没怎么了解过

• no-eviction：不删除策略，达到最大内存限制时刻，如果需要更多内存，直接返回错误信息；
• allkey-lru：从所有 Key 的哈希表（server.db[i].dict）中随机挑选多个 Key，然后在选到的 Key 中利用 lru 算法淘汰最近最少使用的数据；
• volatile-lru：从已设置过期时间的哈希表（server.db[i].expires）中随机挑选多个 Key，然后在选到的 Key 中用 lru 算法淘汰最近最少使用的数据；
• volatile-random：从已设置过期时间的哈希表（server.db[i].expires）中随机挑选 Key淘汰掉；
• allkey-random：从所有的 Key 的哈希表（server.db[i].dict）中随机挑选数据淘汰；
• volatile-ttl：从已设置过期时间的哈希表（server.db[i].expires）中随机挑选多个 Key，然后在选到的 Key 中选择剩余时间最短的数据淘汰掉。

总结

数据库是每个召唤师的必经之路，争取早日上登上王者。