在 MySQL 创造类似 PipelineDB 的流视图(continuous view)

公司的系统采用的是 Google Cloud SQL 提供的 MySQL 数据库，由于历史原因，数据库成本极高，需要对它进行优化缩减成本。

相比 PostgresSQL，MySQL 主要缺少以下特性，导致优化难度极高：

1. 缺少部分索引。部分索引可以将一亿行数据中活跃的那部分数据（往往只有几百万行）隔离出来。

2. 缺少计算索引。MySQL 的索引不能是表达式。

3. 不支持并行。MySQL不能让一个查询分布到多个核，从而缩短查询执行时间。由于只能用一个核，运行时间较长的的SQL很容易造成锁超时，各个服务日志里充满了锁超时错误。

弃暗投明换PG或者上Lambda架构等做法都过于复杂，不考虑。

在优化过程中我发现，如 MySQL 能支持类似流视图，很多主要语句的执行问题可以迎刃而解。

什么是流视图？

基于 Postgresql 的 PipelineDB 支持 Continuous View，使数据库具备了类似流式计算的效果。

    流式数据库PipelineDB（集成Kafka） - 简书 

    流计算风云再起 - PostgreSQL携PipelineDB力挺IoT(物联网), 大幅提升性能和开发效率-云栖社区-阿里云

采用速度层对新增数据执行计算后放入快速存储，而不是在查询时开始计算，这是 Lambda 之类大数据架构的精髓思想。流视图将这套架构包装为一个直观易懂的数据库新事物，和关系理论又不相违，是很巧妙的设计。显然，流视图在很多场景都可以取代 Spark 之类大数据架构，为用户提供更实时的统计查询服务。

羡慕是没用的，没有就自己搞，如何实现流视图？

流视图的原理可以想见：流视图本身是一个表，程序侦听视图相关的各个表的变化，将变化更新到相应的流视图的数据行。

侦听数据变化是实现流视图的必备基础。

在SQL中侦听变化的方式主要是触发器。给每个表建一个触发器很不明智，干出来也不漂亮。我想到一个很好的方案：BINLOG。找了一下，目前已有若干支持 binlog 转 MQ 的方案。我选择了 canal，备选 maxwell。在实施过程中发现，canal 往 MQ 推送的消息没有都是字符串且不支持枚举，而 maxwell 虽然消息很棒，还支持 js 做 filter，但是经常出错崩溃，CPU高，处理不了太大的 binlog，终还是采用了 canal。相比来说 canal 一直在阿里实用，运行非常稳定，CPU 耗费低，从来不出错。

有了 BINLOG，后面就是搞发明创造了，做架构写代码，终成果如下：