MySQL代表了开源数据库的快速发展，从2004年前后的Wiki、WordPress等轻量级Web 2.0应用起步，到2010年阿里巴巴在电商及支付场景大规模使用MySQL数据库，再到2012年开始阿里云RDS for MySQL为成千上万家客户提供可靠的关系数据库服务，积累了来自内外部功能、性能、安全方面的众多需求，培养了一支强劲的MySQL研发团队，并打造了面向企业场景的AliSQL分支，高效演进并稳定地服务着内外部关键业务场景。
让我们来一起看一下AliSQL中面向企业场景的设计及功能。
1丨MySQL 80 Compatiable
MySQL 80有5个非常好的企业级功能，来逐一看一下：
🔸Atomic DDL，MySQL 80去掉了表结构frm文件，实现了元数据信息字典化，可以保证DDL操作处理或回滚干净，避免了表删除不干净的情况。
🔸Instant Add Column，元数据字典化后，向表最后面加列（无默认值）时，可以只更改数据字典，而不需要更改表数据，实现了极快速的加列。
🔸Window Function，窗口函数可以用来快速实现复杂的报表，在许多企业应用场景中都会出现。
🔸Temp Engine，执行特别复杂的SQL时，需要用到内存之外的临时空间，以前版本会动态地创建和删除文件，而在MySQL 80中，使用了集中式的Temp Engine，避免不停地创建和删除文件，有效降低了文件系统的压力。
🔸Hash Join，MySQL 8018中实现了Hash Join，可以加快多表（三表）以上关联的SQL性能，在企业场景中由于业务逻辑复杂，多表关联是常态，绝对的企业级功能。
我们在2019年推出了基于MySQL 80版本的AliSQL版本，远远领先于同行。
2丨Dynamic Thread Pool
企业级场景（包括互联网与非互联网场景）的商业数字化程度越来越高，应用场景越来越丰富，RDS数据库如何在有限资源（4c/8c规格，云上弹性降底企业成本）的情况下提供高质量服务，会面临以下挑战：
🔸如何在有限的资源下，支持更多的数据库连接数？
🔸如何支持更高的短连接能力？
🔸如何在有限的资源下，提高资源的使用效率，提升性能？
🔸如何进行并发控制或隔离，保证核心业务逻辑的稳定性？
Dynamic Thread Pool可以很好地解决上述问题，
🔸采用Listener & Worker机制，将所有请求放到Worker队列中，由共享的Worker线程来执行不同用户的请求，从而不需要每个客户端会话都创建一个后台线程（非Dynamic Thread Pool）来执行请求，比如1000个客户端连接发起请求，服务器端只需要数十个Worker线程即可，而不需要创建1000个线程，从而可以在有限资源内创建更多的连接。
🔸由于每个连接后面并不对应固定的线程，创建新连接时没有线程的操作，因此建立新连接的成本大大降底，从而可以提供更高和更稳定的连接创建能力。
🔸通过控制了有限资源内的线程数，减少了线程切换，有效降低了SYS CPU的使用，提升了CPU的资源使用效率。在高并发的sysbench point select测试中，Dynamic Thread Pool可以提升10%左右的性能；在低并发时，Dynamic Thread Pool可以动态切换回专用模式，即每个连接都有专用的Worker对应，从而保证高低并发下都有极好的性能。
🔸在数据库中有读写操作，SQL操作也可以分为简单操作和复杂操作，为了防止相互影响，Dynamic Thread Pool设计了多个队列，按SQL的操作成本将SQL进行分类，各自进入不同的队列，并在队列上进行并发的控制，从而可以隔离不同类型操作的相互影响。比如说核心业务逻辑中都是简单查询，新建应用未经评审的复杂SQL就不会影响核心逻辑。
🔸Dynamic Thread Pool可以动态启停，不需要重启数据库实例。这是AliSQL Dynamic Thread Pool一个非常重大的技术创新与突破。
Dynamic Thread Pool已经在RDS 5.6/5.7/8.0版本上线，并已经默认开启，所有用户和客户都可以受益。TPCC模型最接近企业核心业务场景，在1024或2048客户端并发的TPCC测试中，Dynamic Thread Pool可以提升50%-100%左右的TpmC，并节约10%到20%的CPU资源消耗，给阿里云所有客户带来实实在在的技术红利。
3丨Index Mutex Tuning
TPCC模型最接近企业核心业务场景，对此场景的优化可以让企业应用受益。在TPCC的压力测试中，发现Index的锁非常重，在节点分裂时会阻塞所有的其他操作。AliSQL对此进行了优化，有效地降低了压测过程中，索引节点分裂的成本，大大地提升了TPCC场景的处理能力。在全内存的测试中，单机达到了39W的TpmC，相对于原生版本提升35-50%不等（大规格测试，5.6提升35%、5.7提升40%、8.0进升45%）。
此优化已在RDS 56/57/80上同步优化发布上线。
4丨TDE & SM4
RDS 5.6/5.7/8.0都已经全线支持，并且支持SM4国密算法，可以确保客户数据的安全。
5丨Performance Insight
应用侧的SQL优化对系统及业务的优化至关重要，原生的MySQL中缺少行之有效的监控数据，AliSQL结合不同数据库的经验，并结合内部外部客户的需求，在SQL性能这块做了丰富的扩展，包含以下五个方面的扩展：
🔸table_stats，记录每个表增删除改查的行数，可以快速地了解现有系统中的数据存取行为，判断业务的核心表，判断哪些表适合来作缓存处理。
🔸index_stats，记录用到的索引以及索引被使用的频率，可以快速地了解索引的使用情况，判断哪些索引是多余的，判断哪些索引是核心的索引。
🔸Performance Point，记录了每个SQL的细粒度性能数据，包括SQL语句的时间（包括消耗时间、执行时间、Server层MDL锁的时间、事务锁的时间）、SQL IO的信息（包括这条SQL引起的数据读、数据写、日志生成、内存访问、物理读写的量及IO时间）、以及内核层面的锁（包括Mutex、RW Lock）的次数和时间。很容易找到值得优化的SQL语句，如果有一定的源代码能力，也可以分析和改进MySQL的锁机制。
🔸Performance Agent，使用内置Daemon程序，在同一时间点收集不同唯度（CPU、内存、网络、磁盘IO、Server、InnoDB、Linux Kernel、File System）的关键性能数据，每秒收集一次，以格式化文本方式在后台记录，便于事后进行性能分析，同时也是内存表的方式提供访问，方便客户直接使用Grafana等工具来展示RDS数据库性能曲线。
🔸IO_STATISTICS，记录实例级各种不同IO的总量及时间，默认每2秒一个值（可配置），可以直接使用Grafana等工具来展示。
在仔细分析原生Performance Schema后，AliSQL中增加了这些额外的性能相关的数据，如实地反映了系统的运行情况，方便我们进行事后性能问题诊断，也方便了客户进行SQL性能分析，也可以让第三方基于这些性能数据来为客户提供更好的性能优化服务。
6丨Async File Purge
在文件系统中删除一个特别大的文件（Drop Table/Partition、Truncate Table/Partition）时，可能会锁定整个文件系统，导致同一个文件系统上的其他操作无法进行，阻塞整个实例。AliSQL中对这种行为进行了优化，当接到删除表或分区的操作时，会记一个文件异步清理的任务，将表或分区的操作先做完，然后由后台线程以相对温和的方式进行清理。其原理是将大文件一步一步变小，到某个安全大小后，才彻底删除文件。
7丨Slow Log Rotate
某些业务场景下，会产生大量的慢SQL语句，会被记录在慢日志中，而原生的MySQL一直使用单个文件机制会一直保持Slow Log文件打开，导致文件变得特别大（可高在上百GB），需要在关闭MySQL实例的情况下，才能对Slow Log文件进行维护，非常地不友好。
AliSQL对此作出了改进，设计了Slow Log切换机制，可以定时或到指定大小后进行切换（切换指令由外部触发），避免需要重启数据库实例来维护Slow Log文件（比如释放Slow Log空间）。其间还修复了以CSV格式存放Slow Log时，SQL执行时间范围超过35天（通常是Binlog Dump命令）引起的损坏问题。
8丨SQL Outline
SQL Hint是非常有效的优化手段，AliSQL对SQL Hint做了功能扩展，可以在运行过程中将SQL计算中的路径信息用相应的SQL Hint进行持久化保存，以保证执行计划的稳定性。可以有效应对以下场景下的SQL执行计划变更：
🔸数据库版本升级，优化器行为会发生变化，SQL计算计划可能变好也可能变坏。
🔸DDL操作，新建索引后，会导致原有的SQL执行计划发生变化。
🔸统计信息发生变化，重新收集或人工设置后，SQL执行计划可能发生变化。
对于核心业务的SQL，应当使用SQL Outline进行固化，避免SQL执行计划变坏。
AliSQL还提供API进行SQL Hint编辑，即可以手工给SQL加一个Hint，进行透明的SQL优化，可以在无法更改应用程序代码的情况下进行SQL优化。并在此基础上，与AliSQL其他的优化功能进行集成，比如Statement Queue、Query Cache（研发中）等，可以通过在SQL Outline中指定Hint来启用Statement Queeu的并发控制，或启用Query Cache，实现对应用透明的SQL优化。
9丨Binlog XA Tuning
MySQL的逻辑日志（Binlog）给数据订阅带来了极大的便捷性，但也给性能带来了负面影响。在服务客户的过程中，我们发现企业场景对性能的要求越来越高，便对启用Binlog后的事务提交机制进行了重大的技术突破，在不影响Binlog的前提下，去除了XA机制带来的所有负面性能影响，相较于原生的MySQL，事务处理性能提升将近一倍。更实现了事务提交的Pipeline机制，交由Dynamic Thread Pool的线程去回复用户事务提交结果，进一步降底了线程池的线程数，提升了系统处理效率。
10丨DDL Recycle Bin
在MySQL中DDL语句是无法回滚的，因此Drop/Truncate表或分区的操作会变得极期危险，在商业数据库中也是如此。
Oracle在10g中加入了回收站的功能，可以将Drop/Truncate的表或分区先放到回收站中，后续根据空间的使用情况，按先进先出的策略自动回收。这样就可以在Drop/Truncate误操作手，从回收站中快速恢复数据，而不需要进行实例基于时间点的恢复来找回误操作的表，AliSQL在8.0上也实现了此回收站功能。
AliSQL还有其他的企业级功能，例如Sequence引挚、Statement Queue等，在这里不一一详细解释。
从业务中找需求，从技术中找需求，从运行维护中找需求，从合作伙伴中找需求，所有的需求方都是我们的客户，一直致力于让AliSQL更加开放更加面向企业级应用。
大型企业数据库服务首选
专属主机组RDS MySQL服务重磅发布！
👇
1月9日15:00 — 17:00
举办联合发布会！
扫码立即预约！
（需登陆阿里云账号哦！）
