又到了我们Halo[MySQL]数据库向大家介绍最近研发进展的时候（上一次是2024年3月，半年前。之前的文章中也提到过，我们的研发节奏是每半年推出一个大版本，这个节奏2年多来坚持得还比较好。）
写上一篇文章时，我们的“支持MySQL用户变量”特性正在开发之中，现在这个特性已经及时完成并经过了严格的测试，并在一些客户环境下应用上了。用户变量是MySQL独有的一个特性，并且被使用的比较多。在自定义的函数和存储过程中几乎无处不在，同时用户变量也经常和系统变量结合起来使用，例如：用于缓存系统变量的旧值和后续恢复：
set @autocommit_backup = @@autocommit; set @@autocommit = new_val; set @@autocommit = @autocommit_backup我们这次深入思考和构思，采取了非常彻底的实现方案，可以说做到了一步到位。
用户变量实现好之后，我们把之前初步实现的“支持MySQL系统变量”的方案做了全面的重构。因为我们不断的发现随着各种开发语言和数据库框架，客户端工具的接入（已经接入我们Halo[MySQL]的项目涉及的开发语言有：Java，Python，C，C#/.Net，Php等，这些开发语言相应的标注库/三方库/数据库框架基本全部涉及到，我们支持的客户端工具有Navicat，DBeaver等），时不时的会遇到新的“MySQL系统变量”，而我们之前的实现方案相对不够灵活，遇到新的MySQL系统变量时，我们需要修改代码再重新发布。这一次我们决定寻求一个一劳永逸的方案，重构之后我们达到了这个目标。我们再遇到新的“MySQL系统变量”时，只需要DBA执行一条SQL语句即可实现“实时”支持，对用户的友好度非常好，例如：
replace into information_schema.variables values('have_query_cache', '1', '1', 1, true, false, '0|1', 'NO|YES', 'NO|YES'); 用户变量实现好之后，“支持MySQL自定义函数和储存过程的语法”特性的前提条件就有了。MySQL自定义函数和储存过程的使用在我们的客户场景中非常常见非常重要。在我们Halo的内核中支持MySQL自定义函数和储存过程的语法相对来说也是非常复杂，工作量非常大的。我们研发同学努力了2个多月，最终拿出了一个非常好的结果。
再接下来，我们完成了“支持MySQL的分区表”这个功能特性。这个功能特性相对来说应用的少一些，所以我们放在后面。
到此，我们Halo[MySQL]就基本完成了官方MySQL所有主要的语法功能特性。同时我们的Halo[MySQL]也达到了一个新的里程碑：之前我们迁移客户的存量数据库时，需要借助第三方工具，将从MySQL导出的脚本转换为我们Halo的语法，再执行到我们Halo数据库上。现在我们可以摆脱对第三方工具的依赖，直接将从MySQL导出的脚本拿到我们Halo[MySQL]上执行即可。
当然，后续我们还有不少的工作要继续努力：很多语法特性细节需要支持和完善——不能不说，MySQL实在是太灵活了，灵活得有些让人摸不着头脑。但是，只要有客户需要，我们就义无反顾。
谢谢大家的阅读。后续敬请大家期待。
