因为我们对MySQL的改动，是在MySQL的基础上进行二次开发的，一种是性能调优，一种是线上问题的解决，还有功能开发，针对于新的业务需求来实现。
我们会通过在压测过程中比较他们资源竞争的情况，比如说内存资源或锁资源，下图中的前三个是我们对redo log所做的性能调优，第一个是redo log，通过减少sync 盘的次数来提升性能，第二部分是通过多缓冲buffer，即Redo Log 在Sync的同时不影响其它事务日志的写入，第三个则可以保证事务在向系统缓冲区写Redo 日志时互不影响，提升并发性。Select offset limit 操作则是将计算下推到引擎层，降低 CPU资源消耗的同时，提升性能。
而在功能方面，我们实现了官方版本所没有的功能，比如加密、审计、线程池，并行复制。首先是审计功能，官方的版本是没有审计这个功能的，只有企业版才有，我们结合自己的实际情况，为了保证用户的性能，我们做了一个audit的插件，从而保证性能的同时实现了用户所需要的功能。
第三个是thread handling，我们在测试压力测试的时候，随着并发的加大，性能会首先提升，然后下降，原因则是系统内部各种资源的竟争比较严重，TXSQL 通过把 Thread Pool 引入来解决这个问题，并且解决了以下几个问题：
解决了Threadpool 情况下全局读锁所造成的死锁问题
解决了 Dump 线程对于Thread Pool 的影响
添加新的 Information Schema 表来观察ThreadPool内部的运行情况
当主库压力不断变大的时候，我们备库的消耗数赶不上主库生产的时候，从5.1，5.5， 5.6，5.7，这个问题始终没有得到很好的解决，5.6的时候虽然有一个并行算法，但是并不能完全解决延迟问题，我们引入了自己的并行，从而很好解决了这个问题。当你主库延迟的时候，主库挂了，备库没有消费完累积的 RelayLog之前，服务器是不能够提供服务的，如果接受服务的话会有双写的问题。
无论是我们在上云过程中还是服务用户过程中，都遇到了各种各样的困难。
比如我们在帮一个游戏公司上云过程中发现了他们的性能问题，我们对系统进行分析的时候对它进行了优化，调优了各种参数并升级内核，最终使用户的性能从7万上升到17万。
第二案例比较突出的是游戏客户，他们的实例遇到了内存泄露的问题，占用内存不断上升，造成了机器的 OOM，这个问题我们花了将近一周的时间找到问题RootCause，然后用一周的时间进行灰度发布和测试，我们Fix Bug的速度一般是两周，而官方受限于版本发布，一般都需要两到三个月才能解决。
TXSQL只是作为内核版本来帮助用户进行计算。我们的稳定性有几个来保证，一个是全链路监控，一个是机器层面操作系统方面的监控，还有MySQL的秒级监控，以及人工的在线帮助。
TXSQL未来的发展方向在保持稳定性，性能调优和功能实现的基础上，未来我们会以这几个方向。
批量计算：对于可以让 Engine做的事情，我们可以将计算下推到Engine层来做，减少消耗。
执行计划缓存也是我们在不久将来要做的事情，之前做过一个测试，最简单的基于主键的查询就会有10%的性能提升。
为了解决存储的问题，我们将RocksDB 引入到了TXSQL中,即 TXRocks，也会在近期推出这个产品，在支持事务操作的同时，可以极大的降低用户成本。
更多相关资料，请点击下方链接获取。
TXSQL云计算时代数据库核弹头.pdf
问答
云数据库MySQL连接方式
相关阅读
深度揭秘腾讯云新一代企业级HTAP数据库TBase核心概念
10款常见MySQL高可用方案选型解读
利用Zipkin追踪Mysql数据库调用链