上述规则的意思是，当SELECT语句中包含 "+CLICKHOUSE" 关键字时，就会自动转发到 ClickHouse 后端去处理，其余的都发送到MySQL后端处理。例如下面这两条SQL就会分别转发到MySQL和ClickHouse后端：
#SQL #1 [root@yejr.run]> SELECT * FROM sbtest1 WHERE id=1; #SQL #2 [root@yejr.run]> SELECT /*+CLICKHOUSE*/ * FROM sbtest1 WHERE id=1;
第二条SQL利用MySQL的注释语法巧妙地实现规则HINT。
查询 stats_mysql_query_digest 表的结果予以确认：
roxysql> select hostgroup, schemaname, username, digest, digest_text from stats_mysql_query_digest;
+-----------+------------+----------+--------------------+----------------------------------+| hostgroup | schemaname | username | digest | digest_text |
+-----------+------------+----------+--------------------+----------------------------------+
| 0 | sbtest | app_user | 0x5662D7CF0442E794 | select * from sbtest1 where id=? |
| 1 | sbtest | app_user | 0x5662D7CF0442E794 | select * from sbtest1 where id=? |
+-----------+------------+----------+--------------------+----------------------------------+
可以看到，两条SQL看起来一样，但分别转发到不同的hostgroup了。
最后配置ProxySQL的监控服务（可选，非必须）：
proxysql> set mysql-monitor_enabled="true";
proxysql> set mysql-monitor_username="monitor";
proxysql> set mysql-monitor_password="monitor";
proxysql> save mysql variables to disk; load mysql variables to runtime;
至此，一个全部基于开源应用的简易HTAP系统就构建好了。
4. 性能对比
在这里，我选用ClickHouse官方提供的benchmark方案：Star Schema Benchmark。
编译完成后先是利用ssb-dbgen生成测试数据（指定参数 -s 50）：
./dbgen -s 50 -T c &
./dbgen -s 50 -T l &
./dbgen -s 50 -T p &
./dbgen -s 50 -T s &
./dbgen -s 50 -T d &
再创建几个测试库表，自行修改建表的DDL以适应MySQL语法。而后导入测试数据，最后根据文档并生成 lineorder_flat 表。
[root@yejr.run]> show table status;
+----------------+--------+---------+------------+-----------+----------------+--------------+
| Name | Engine | Version | Row_format | Rows | Avg_row_length | Data_length |
+----------------+--------+---------+------------+-----------+----------------+--------------+
| customer | InnoDB | 10 | Dynamic | 1378209 | 120 | 166363136 |
| lineorder | InnoDB | 10 | Dynamic | 297927870 | 100 | 29871833088 |
| lineorder_flat | InnoDB | 10 | Dynamic | 292584926 | 430 | 125952851968 |
| part | InnoDB | 10 | Dynamic | 1192880 | 111 | 132792320 |
| supplier | InnoDB | 10 | Dynamic | 99730 | 110 | 11026432 |
+----------------+--------+---------+------------+-----------+----------------+--------------+
数据全部加载完毕后，再在ClickHouse中创建MaterializeMySQL复制通道：
clickhouse :) CREATE DATABASE ssb ENGINE = MaterializeMySQL('172.24.10.10:3380', 'ssb', 'repl', 'repl');
数据量比较大，耐心静待它复制完成即可。
然后连接 ProxySQL，先简单执行大表count()，观察耗时的不同：
#直接执行count()，会转发到后端 MySQL 实例
[root@yejr.run]> select count(*) from lineorder_flat;
+-----------+
| count(*) |
+-----------+
| 300005811 |
+-----------+
1 row in set (3 min 2.14 sec)
#加上HINT规则，会转发到后端 ClickHouse 实例
[root@yejr.run]> select /+CLICKHOUSE/ count(*) from lineorder_flat;
+-----------+
| count(*) |
+-----------+
| 300005811 |
+-----------+
1 row in set (5.67 sec)
光是 count(*) 就差了好多倍。
再选取其中前4个SQL测试，记录的耗时如下：
| Query | MySQL | ClickHouse(从库) | ClickHouse(原生) |
| Q1.1 | 308.388684 | 0.149 | 0.107 |
| Q1.2 | 320.373203 | 0.280 | 0.027 |
| Q1.3 | 279.673361 | 0.346 | 0.030 |
| Q2.1 | 286.451062 | 1.246 | 0.489 |
很明显，直接在MySQL上查询的效率实在太低了，而作为从库的MaterializeMySQL和ClickHouse原生的MergeTree表虽然也有一定差距，但相差也没那么大了，还算是很快的。
4. 其他说明
- ClickHouse的MaterializeMySQL中不支持 create like 语法。例如执行 create table db2.a like db1.a，其中db1是要复制到ClickHouse的，而db2是留在MySQL端，即便这样也会导致ClickHouse端复制报错，需要重启才行。
- ClickHouse的MaterializeMySQL中也不支持函数索引。
- 偶尔发现ProxySQL的监控模块连接到ClickHouse后，会发送 SET wait_timeout=N 命令，会导致ClickHouse报错，但不影响正常使用。重启ProxySQL，或者重启监控开关都可以解决。
Enjoy it :)
</div>