前言 && 感想

本年度Oralce Open World会议从十月25号到29号，在美国旧金山举行。数万来自全球各地的从业人员涌入Moscone Center，见证一年一度的Oracle生态系统盛事。

本次OOW2015的主题都是围绕在Oracle Cloud，云服务应该是Oracle之后的发力点。几场Oracle CTO（前Oracle CEO）Larry的主题演讲也围绕cloud，详细阐述了Oracle Cloud的设计原则，及相关的云产品，其目标直指Amazon和Microsoft的云服务。

我在OOW的关注点主要是几场KeyNote以及MySQL相关的Topic。先总结下参会的感受吧：

1. Oracle的主场还是集中在Oracle database, Oracle Cloud以及Java。而“不太会赚钱”的MySQL主题则安排的比较少，会场也都是最小的；
2. 关于MySQL，前几天MySQL5.7版本在前几天刚刚宣布GA，因此本次会议的官方主题都是关于新版本的特性介绍，新的版本带来了大量新特性（例如GIS、Build-in JSON、新的Fulltext Parser、Generated Column）以及性能优化（复制性能、InnDB读写性能），大量内部锁竞争的移除，使得新版本MySQL能够在多核环境下更好的Scale Up，发挥硬件的性能；
3. 大部分内容都是已有的技术，并没有什么新的黑科技；
4. 也有几家美国公司来介绍他们如何使用MySQL，但类似Facebook、Twitter这样的MySQL重度用户且对社区有很大贡献的公司却集体缺席，不得不说是个很大的遗憾；
5. 从这几家公司使用MySQL的情况来看，我感觉阿里在MySQL领域的工作绝对是首屈一指的，没有多少公司像我们这样把MySQL玩的这么深入，这么深度的修改源码来适应我们的环境。明年如果有机会，不管谁去参加，我觉得都可以考虑去做几个主题演讲，宣传公司在MySQL社区的影响力；
6. 从交流了解到，美国很多互联网公司都选择把服务器托管在AWS上。未来阿里云的国际化，需要把我们的技术影响力扩展到国外，才能争取到这样的用户。

以下是这五天期间我关注的几个Topic，主要从Oracle 、MySQL官方演讲、业界使用三个方面划分。

Oracle主题

Oracle OpenWorld Welcome Keynote [KEY10818]

Larry Ellison, Executive Chairman of the Board and Chief Technology Officer, Oracle
Brian Krzanich, CEO, Intel Corporation

视频链接

当天第一场重磅keynote，由intel的CEO主持，这次会议着重强调Intel和Oracle的深度合作带来的价值，顺便开刷了下IBM在云计算领域的落伍。最后压轴的是Larry的演讲，主题是Oracle Cloud服务，他明确指出了其在SAAS领域的对手是Salesforce，PaaS领域的对手是微软而不是IBM，IaaS领域的对手是Amazon（Aliyun在美国还是籍籍无名啊…）。相对于这些竞争对手，Oracle要做全平台的云服务提供商：在SaaS提供全部种类的商业应用，例如CX、HCM、ERP、EPM等；在PaaS领域提供完全符合工业标准的平台服务；在IaaS领域突出安全性、可靠性、低开销，标准化的基础设施服务。

为了达成上述目标，Larry从以下几个角度阐述了Oracle云服务的设计目标：

第一是低成本（cost），包括价格上具备竞争优势，通过自动化降低人力成本和人为误差，更轻易的创建和使用应用来减少成本。

第二是高可用性(reliability)，实现零宕机时间。两个方面：

1. fault tolerant，通过冗余设计，hot patching及备份，即时恢复来实现；
2. 自动化(automation)，消除在部署、补丁、备份及恢复期间的人为错误。

第三是高性能，从三个方面阐述：

1. 数据库，in-memory in-flush的列式数据库，部署在云中的Exadata；
2. 中间件，In-memory speed-of-thought Analytics; 3.Sale-out架构，弹性能力，和按需获的性能。

第四是标准化，支持工业标准的SQL、Hadoop、NoSQL等等，让用户能够无锁定的*迁移到其他云服务平台。

第五是兼容性，能够自动迁移负载和数据。例如从公有云和私有云之间*迁移。

第六是安全性，能够持续的抵御黑客攻击。最新发布的SPARC M7处理器在硬件层支持实时的安全监测；另一方面也提供数据加密。

在阐述上述观点后，随后发布了一大堆的云产品，Oracle强势宣布了其正式进入了云计算领域。

Exploring Oracle Database 12c New Features Best Practices for DBAs and Developers [UGF7904]

Ami Aharonovich, CEO, DBAces-ilOUG

PPT链接

介绍了Oracle 12c的一些新特性，以及如何使用这些特性，作为一名MySQL开发，最让我感兴趣的是MySQL中没有的功能，以及是否能将Oracle的这些功能也实现到MySQL中去。以下是几个笔记的点。

隐藏列属性：定义为“column_name TYPE INVISIABLE”。当设置该属性后，这个列的内容对客户端而言就是不可见的，但如果显式的指定列名的话，则可以对该列进行操作，主要用于类似应用迁移之类的场景，例如增加新的列，不影响老的应用，同时新的应用也可以通过指定列的方式进行操作。MySQL可以考虑把这个特性Port过来。这个文档 有对该特性的描述。

默认的sequence值：可以默认获取一个新的sequence值（定义为column_name TYPE DEFAULT seq_name.nextval），另外一种方式是在列上定义一个IDENTIFY属性（id NUMBER GENERATED ALWAYS AS IDENTITY）仔细想想，这货不就是MySQL的Auto-Increment属性么。

Data Redaction：顾名思义，就是数据修订的意思，对返回给客户端的值进行修订，例如将敏感信息用”*“代替返回。有FULL Redaction、Partial Redaction、Regular expression、Random Redaction、No Redaction几种。如下图所示：

具体介绍参阅这篇文章。
下图描述了这个特性的一个典型应用。感觉是个比较有意思的特性，后面看看怎么做的，可以考虑实现到MySQL里

更好的加列操作：如果列的值允许为NULL，加列操作不会产生表上所有记录更新，而是修改元数据。当查询到这个列时，如果尚未有数据，则从元数据中获得其default值，并返回给客户端。同样的思路可以应用于MySQL。

Adaptive Execution PLan：运行过程中自动调整执行计划，最终的计划取决于执行过程中看到的行数。

在该演讲slide的最后贴了大量关于Oracle 12c相关的链接，感兴趣的可以点开了解下。

General Session: Software in Silicon and SPARC Outlook—Secure, Smarter Database/Applications [GEN6421]

Masood Heydari, SVP, Hardware Development, Oracle

PPT链接

介绍新发布的SPARC M7 处理器，其性能强悍，号称有32个core，256线程，4.13GHZ，64MB的L3 Cache, 支持最大2TB的物理内存，支持4路DDR4 内存控制器； 并且相比前一代有3倍IO带宽提升；该处理器还支持Silicon Secured Memory， DB query Acceleration，Inline Decompression，将软件功能集合到硬件中，从而最大化发挥效率。其号称世界上最快的微处理器，其基于硬件的内存安全防护，能够防止黑客非法访问内存内容

MySQL官方演讲

How to Analyze and Tune SQL Queries for Better Performance [TUT3411]

Oystein Grovlen, Senior Principal Software Engineer, Oracle

PPT链接

演讲者为MySQL团队优化器模块的开发人员，重点介绍了优化器的相关知识，包括优化器的执行过程， MySQL 5.7引入的cost model ，5.6版本之后引入的物化统计信息。
其中比较有意思的点是cost model，介绍了用户如何通过设置cost model来影响优化器的行为。
通过实例介绍了索引选择的类型，介绍了join和子查询是如何进行优化器选择的，以及排序和聚合操作。 该演讲的slide干货满满，对优化器感兴趣的同学非常值得一看。

MySQL Replication Tips and Tricks [TUT5467]

Joao Gramacho, Software Developer, Oracle

PPT链接

详细介绍了MySQL的复制模块，以及大量的使用技巧及5.7的新特性，从浅显的知识到更深入的讨论都有涉及，适合对复制模块感兴趣的各个层次人群阅读。

InnoDB: What’s New in MySQL 5.7 [CON3716]

Sunny Brain, InnoDB Developer Manager

暂无PPT

InnoDB的开发主管Sunny Brain介绍了MySQL5.7对InnoDB模块的改进，总的来说，主要包括以下几点：

General tablespace： 一种用户定义的表空间，在磁盘上会生成一个ibd文件，可以指定表空间名来创建表，这些表的数据都存储到一个ibd文件中。

Virtual column：支持虚拟列，即用户通过预设的表达式定义的列，这样的列不存储数据，但支持基于其上建立索引。一种典型的应用是基于Json类型数据之上，使用json相关函数创建虚拟列。隔天Jimmy Yang有个演讲专门介绍这一块。

native partition：将分区表的引擎接口从Server层转移到InnoDB层，这意味着之前每个分区都需要一个存储引擎接口，现在则只需要一个引擎接口，对于包含大量分区的分区表而言，可以减少不少内存消耗。另外这种改变，也使得未来基于分区表做并行查询更加简单。

全文索引：改进了全文索引，可以更好的支持中文全文索引分词，这极大的弥补了5.6版本InnoDB全文索引的不足之处，从5.7版本开始，MySQL用户可以完全抛弃MyISAM引擎的全文索引

R-Tree Index(GIS Support)：开始支持GIS空间数据类型，弥补了MySQL和其他数据库（如PostgreSQL）相比的一大缺憾，GIS对当前基于地理空间的应用是非常重要的功能。

性能优化：在5.7版本对读写性能做了大量的优化，例如优化了读写事务链表的管理，Read View缓存(两个只读查询之间没有新的读写事务，则认为read view是可重用的)，消除了大量的事务锁瓶颈。基于这些改进，新版本的性能（尤其是读性能）能够在多核场景下获得更好的性能。 在讨论到Read view缓存时，我发现在RC隔离级别下，这一优化策略并没有生效，和Sunny讨论了下这个问题，他表示认同。

索引锁优化：引入SX Lock，在对btree做分裂或合并操作时，不再锁住整棵btree，从而降低对读负载的影响。

事务生命周期特性： （主要用于支持5.7另外一个新特性：Group Replication），包括高优先级事务，高优先级获取记录锁（可以从记录锁队列中往前跳），kill其他低优先级事务。目前这几个特性还对终端用户不直接可见。

DDL优化：对于索引创建，在之前的版本中使用先排序数据，再执行插入到新btree中的方式，而新版本则使用自低向上的索引构建方式，即先构建叶子节点，再从叶子节点开始构建非叶子节点，这样具有极高的索引创建效率。

Intrinsic table：主要被优化器使用，在之前版本中使用的是MyISAM引擎来作为查询过程中产生的临时表引擎；在5.7版本中，InnoDB对临时表(intrinsic table)做了大量优化，包括独立的临时表表空间，独立的undo回滚端，减少redo log的记录。下图是他们的性能比较图，可以看到InnoDB在高并发下能获得更好的性能。

Memcached： 由于消除了大量的性能瓶颈，MySQL5.7的Memcached Plugin相比5.6有了数倍的提升，而在稳定性上，也修复了大量的bug，相信5.7版本能够改变5.6版本Memcached plugin无人问津的窘境。

其他还包括诸如大Page Size支持，CRC32的Redo log校验，多个Page cleaner线程及buffer pool刷脏逻辑优化。

总的来说，MySQL5.7是个非常值得期待的版本。

Building Scalable, High-Availability Systems Using MySQL Fabric [CON4975]

Mats Kindahl, Senior Principal Software Developer, Oracle

暂无PPT

介绍了MySQL新组件Fabric，主要用于构建高可用，可扩展的系统。Fabric本质上是一组脚本，算是官方出品的HA和Sharding工具。由于阿里在这一块已经非常的成熟，我对Fabric本身并不感兴趣，感兴趣的可以参阅官方文档。而对为了支持fabric对服务器端代码做的改动比较感兴趣。

总的来说，为了支持Fabric，MySQL本身做了几点改动：
实现一种新的方法来清理session的状态，可以reset 已有的会话，例如清理其内容并释放资源（WL#6797），这在我们RDS里也有类似的实现。

允许MySQL服务器进入一种离线状态，让已有的连接优雅的断开（SUPER账户除外），这主要用于升级或者维护服务器。该特性也用于fabric来辅助管理MySQL集群。(WL#3836)

增加一个服务器层的flag来判断是否有一个新的事务开启了，主要用于连接池的负载均衡，如果一个session未开启事务，就可以把它的请求调度给别的连接。 (WL#6631)

另外在29号也有另外一个关于Fabric的主题演讲，参阅PPT。

MySQL 5.7: What Is New in the Optimizer? [CON3379]

Manyi Lu, Senior engineering manager, Oracle

PPT链接

负责MySQL服务器层的开发主管介绍了MySQL5.7版本对Optimizer模块的优化，主要包括如下几个方面的改进。

Generated Column：用户可以在建表或ALTER时创建的一种新的列类型，列的数据可以通过一个预设的表达式来进行计算，如下建表语句：

CREATE TABLE order_lines
    (orderno integer,
    lineno integer,
    price decimal(10,2),
    qty integer,
   sum_price decimal(10,2) GENERATED ALWAYS AS (qty * price) STORED );

最后一个列的值为qty列和price列相乘得到。STORED属性表示在插入或更新时计算该列的值并存储到物理文件中。你也可以选择VIRTUAL属性，这样就只在查询时计算。这可以满足一些特殊的需求：例如实现基于方法的索引，物化缓存复杂的条件，简化查询SQL表达式。

JSON Support：支持内建的JSON类型的数据存储，并提供一组JSON函数。使用也比较简单，直接将列类型定义为JSON。

对于JSON类型的数据，在插入或更改时，会进行格式检查，通过新的语法和函数，也可以更方便的操作JSON数据。

和Generated Column相结合，我们还可以对json中的数据进行索引创建，从而索引json中的某个数据段。

PS：当天有另外一个演讲专门对JSON做了介绍

Cost Model：用户可以根据自己的硬件场景来配置cost model，进而影响优化器的选择。基于5.7的cost model，解决了如下几个问题：

1. 对于JOIN操作的记录数估计不准确；
2. hard-code的代价常量；
3. 不准确的record-per-key，使用浮点数代替；
4. 使用json输出explain的结果。Manyi Lu强调在下一个版本中，他们会着重解决优化的cost model自动调整功能，而不是依赖人来配置。

新的HINT表达式：在插叙中使用 /+ …/ 来开启一些优化器或者其他选项，例如BKA, BNL, MRR, ICP, SEMIJOIN, SUBQUERY，MAX_EXECUTION_TIME等等常用HINT。

Query Rewrite Plugin：一种新的插件类型，主要解决的问题是在不修改应用的情况下，更改其SQL的行为，例如如果优化器总是为这个SQL选择错误的执行计划，就可以为其加上hint做强制索引选择。

UNION ALL问题：在5.7版本终于解决了臭名昭著的UNION ALL总是创建临时表的问题，多个表做UNIALL ALL时，数据先存储到临时表，然后再发送，但UNION ALL并不需要结果集的顺序性和唯一性，没有必要构建临时表来作去重。

IN表达式优化：在之前的版本中，对于这样的表达式WHERE (a, b) IN ((0, 0), (1, 1))，即时(a,b)上存在索引，也无法使用IN表达式中的值去查询索引，在5.7解决了这个问题，可以使用索引做range scan。

EXPLAIN：可以去查看一个正在运行的SQL的执行计划，这个特性对我们诊断问题非常有用。

最后Manyi Lu罕见的给出了下一个版本优化器模块的RoadMap（Oracle的开发人员通常不会对下一阶段的开发发表评论），包括：

1. 改进对存储过程的支持；
2. 增加类似oracle的直方图；
3. 支持并行查询；
4. 公用表表达式(Common table expression) 。

在后面的讨论中，Manyi Lu也透露了“查询计划缓存”也在开发的计划中（尽管这里没有列出来）。

从优化器的进化可以看出来，MySQL的优化器模块开始变的越来越像Oracle了。希望新版本的MySQL5.7能够改变人们一向的“MySQL优化器很弱”的印象。

Update Everywhere with the MySQL Group Replication Plugin [CON5349]

Nuno Carvalho, Principal Software Engineer, Oracle

暂无PPT

介绍了MySQL的一种新的插件类型：Group Replication plugin，主要用于类似active-active复制拓扑结构的集群管理，支持多个节点更新，自动冲突检测，自动增删节点等功能，类似MariaDB的Galera。Group Replication目前已经到了0.6.0版本，但还没有正式GA。

使用Group Replication，需要保证使用的表都是InnoDB表，并且定义了主键。Binlog需要使用Row模式。

Group Replication的分布式一致性协议基于XCom，一种PaxOS协议的变种。

关于冲突检测，开发了一组Group Communication 工具集，提供了完全有序的广播，也就是说，消息在所有的节点都按照同样的顺序进行应用。当产生一个新的更新消息时（以类似binlog row格式存储）：

1. 在当前实例上完成，但block在commit阶段；
2. group communcattion组件会负责将消息发送到所有依然活跃的节点。
3. 最关键的是决定本地事务是该提交还是回滚。这就涉及到如何进行冲突检测，每个行记录都有一个版本信息，在行被更新时，版本也会递增。主要通过节点间行记录的版本信息来进行冲突检测；
4. 如果不存在冲突，则全部提交；否则全部回滚。

版本信息是通过GTID维护的，所有实例的UUID是全局统一的，并保证了所有节点产生的GTID不会重复。有两个版本信息，一个是database version，也就是本地的version（dbv），另外一个是确认模块的version（cv），下图是一个典型的冲突解决场景：

关于一个事务在Group Replication集群中的生命周期，参阅这篇博客

关于节点踢出和重新加入的逻辑，参阅这篇文章

如何使用Group Replication

在官方博客上还有不少文章介绍Group Replication，感兴趣的可以深入研究下。

What’s New in MySQL 5.7 Security [CON1559]

Georgi Kodinov, Senior Software Development Manager, Oracle

PPT链接

主要介绍了MySQL 5.7 包含的一些安全特性。包括：

企业版特性：

1. SQL防火墙用于包含实例免受预期外的SQL注入侵害;
2. 企业版数据加密。

账户管理：

1. 增加ALTER USER语法来修改用户权限。
2. 临时权限禁止功能；
3. 基于时间的权限失效策略；
4. 服务器提供offline模式。

重构及新功能：
1. 新的权限表格式；
2. 提供基于AES的加解密函数；
3. mysql_secure_install/mysql_install_db使用c语言进行了重构；mysql_upgrade不再调用外部程序。

业界使用

MyRocks： MySQL on RockDB

Yoshinori Matsunobu, database developer at facebook

由于26号没有什么比较值得关注的主题，我们应facebook的邀请，26号下午去拜访了Facebook的MySQL开发团队，了解了下之前我们一直关注的MyRock开发情况，他们的开发Yosh专门为我们做了介绍。

说到MyRock，需要先介绍下RockDB。RockDB是facebook基于LevelDB的一个分支，他们在其上做了大量的优化，目前已经集成到Mogodb 作为一个plugin，Percona公司也开始针对RockDB提供技术支持。RockDB基于LSM存储结构，能够有效的减少磁盘擦写的次数，这对Facebook非常重要，因为在他们那里flash设备已被广泛使用，通过rockdb能够有效的控制磁盘成本。另外更大的SST 文件块大小相比InnoDB获得更好的压缩效果，减少磁盘的存储空间。

但是RockDB仅仅支持key-value，并没有SQL接口，如果想用rockdb取代已被广泛使用的InnoDB，应用修改的成本巨大，因此他们启动了MyRock项目，将RockDB包装成MySQL的一个存储引擎。Yosh透露预计明年会出一个GA版本，目前还处于开发状态，他们也在该项目上和MariaDB进行紧密合作。
为了进一步减少磁盘空间，他们实现了“prefix key encoding”，即对于具有相同前缀的行记录，这些相同的列值只存储一次。不过这样也带来了一些负面作用，即需要在建表时设定是正序存储还是逆序存储，因此需要和应用方商量好。

由于LSM具有分层结构，对查询并不友好，最差情况下每个level可能都需要查询一遍。一次带order by的range scan需要将多个level的结果进行merge，这不像基于Btree结构的InnoDB，直接做一次顺序扫描即可。为了优化该场景，他们在MyRock中引入了bloom filter来加速查询，快速确认某个level是否有需要的记录，减少不必要的IO。

目前MyRock还有一些限制，包括：不支持Online DDL、Foreign Key、Spatial Index、以及Fulltext；所有表必须有primary key；不支持next-key lock，并且必须使用row格式复制；不支持binlog和myrock的XA；ORDER BY DESC/ASC 由于prefix key encoding，总有一个会比较慢点；大量删除操作会影响到整体性能。

总的来说，他们并不期望myrock能完全取代InnoDB，只是期望在某些场景下能利用LSM的优点。目前该项目公布在github上，代码的开发进度、提交日志一目了然，不得不让人敬佩facebook的开源和社区合作精神。

A Global Transaction Identifier Rollout at Dropbox [CON4766]

Rene Cannao, MySQL DBA, Dropbox
David Turner, Database Administrator, Dropbox

PPT链接

Dropbox公司分享了他们如何使用GTID。没啥新东西，主要的问题还是GTID无法动态调整，导致整个MySQL集群无法升级到5.6及之后版本的问题，这个问题在社区（例如Facebook和booking）都做了些简单的patch来绕过这个问题，咱们的RDS MySQL也有相应的改动。 这个问题在5.7版本得到了彻底的解决。Gtid的开启和关闭被划分成了多个阶段，来保证整个复制拓扑的GTID一致性

Making MySQL More Efficient at Pinterest [CON3654]

Ernie Souhrada, Database Engineer, Pinterest
Robert Wultsch, Database Engineer, Pinterest

暂无PPT

Pinterest公司的两位数据库工程师（实际上他们整个team就两个人），一个是前Percona员工，一个是前Facebook员工。他们分享了Pinterest如何让MySQL更高效。

由于只有两名员工，他们选择更多的依靠已有的技术，例如备份使用MySQL Enterprice Backup。他们提到一个比较有意思的问题是，在数据库中他们存储了大量的JSON数据，这些数据列的大小平均为1.2kb。正好他们看到了我们以前分享的关于单列压缩的改进，在他们的场景下测试得出的结论是，列压缩在保证性能的基础上，依然能提供不错的压缩比。

他们在列压缩的基础上，对这个功能进行了扩展，方案交给Percona进行开发。也就是所谓的Predefined Compression dictionary。会后和他们交流了具体的方案，了解了这个改进的具体内容：
其本质是将需要压缩的数据预先定义好，然后在全局使用这个预先定义的数据词典进行压缩。定义两张系统表，一张系统表存储数据词典信息，另外一张表存储列与数据词典的映射。

由于预先定义好了压缩前缀词典，即时一个字符串在某个列中只出现了一次，也是可以被压缩的。
压缩前缀词典可以通过训练已有的数据集得到。这确实是一个非常有趣的思路，对他们的这种场景，减少了72%的磁盘占用。

Binlog Servers at Booking.com [CON4098]

Jean-François Gagné, Senior System Engineer, Booking.com

PPT链接

来自booking的开发人员介绍了他们的binlog server工具，根据其描述，其工作原理就是一个独立的server，从master上读取binlog，存储到本地；然后将自己当做一个“假”的master，将binlog分发到各个slave节点。

在阿里，我们早几年就有了类似的工具，例如DRC， Transfer，精卫等。不过booking结合binlog server实现了其生产环境的高可用，读扩展以及时间点恢复功能。

YouTube Vitess: Cloud-Native MySQL [CON11339]

Anthony Yeh, Software Engineer, Google

PPT链接

来自谷歌的工程师介绍了Youtube的开源项目Vitess。对分布式中间件不太了解。没啥感觉

Feed Your Streams: Zendesk’s Maxwell Generates Kafka Event Stream from MySQL Binlogs [CON3340]

Ben Osheroff, Principle Engineer, zendesk.com

PPT链接

zendisk的工程师分享了另外一款开源的工具，同样也是用于解析Binlog的，不同的是，把binlog的内容解析成了json的格式并复制到Kafka，算是玩出了新意。例如解析出来的数据如下图所示：

Yahoo Case Study: MySQL GTIDs and Parallel or Multithreaded Replication [CON5409]

Yashada Jadhav, MySQL DBA, Yahoo
Stacy Yuan, Sr. MySQL DBA, Yahoo

PPT链接

主要讲了Yahoo关于GTID的使用，介绍了下复制的相关知识以及如何使用Percona版本的MySQL实现online GTID开启。没啥新意，看在难得是妹子的份上听了一会就闪了。但对这块不了解的同学可以看看。

Database Defense in Depth [CON3554]

Geoffrey Anderson, Senior Database Operations Engineer, Box

PPT链接

Box公司的DBA阐述了他们如何使用各种工具来解决MySQL遇到的问题，以保证MySQL的正常运行。没啥新东西。