连接方式：

使用mysql客户端连接，包括但不限于：
cmd连接：mysql -h127.0.0.1 -P9030 -uroot；
Navicat、Datagrip等工具，DataSource直接选择Mysql即可。

系统架构：

StarRocks集群由FE和BE构成，FrontEnd简称FE，是StarRocks的前端节点，负责管理元数据，管理客户端连接，进行查询规划，查询调度等工作。
BackEnd简称BE，是StarRocks的后端节点，负责数据存储，计算执行，以及compaction，副本管理等工作。

可以理解为，FE负责统筹规划、分发任务、收集信息、反馈给用户，BE负责实际处理、查询、管理数据。
（下图来自StarRocks官网）

存储表

1、 模型：StarRocks表的种类，分为明细模型（默认）、聚合模型、更新模型和主键模型。其中，更新模型、主键模型为特殊的聚合模型。

2、数据分布

分区（Partition）、分桶（Distribution）

StarRocks使用先分区后分桶的方式, 可灵活地支持两种分布方式：

Hash分布：不采用分区方式，整个table作为一个分区, 指定分桶的数量；
Range-Hash的组合数据分布： 即指定分区数量， 指定每个分区的分桶数量。

在StarRocks中，只支持range分区（目前测试），建list分区会报错。且range的类型只支持int、date，不支持range columns分区。

索引

官方文档给出了稀疏索引、Bloomfilter和Bitmap的概念。稀疏索引是建表时自动创建的，（所以建表时要考虑将常用来查询的字段放在前面）手动创建索引目前只支持位图索引（Bitmap）。

关于Bloomfilter 的说明详见官方文档。

也可以在表上创建Rollup（类似于物化索引）

性能优化

在官方文档中，提到了Colocate Join这一概念。

Colocation Join 功能，是将一组拥有相同 Colocation Group Schema的 Table 组成一个Colocation Group。并保证这些 Table 对应的分桶副本会落在相同一组BE 节点上。使得当 CG 内的表进行分桶列上的 Join 操作时，可以直接进行本地数据 Join，减少数据在节点间的传输耗时。

大致可理解为，当几张大表需要进行join联查时，可将其常用的join字段组成同一个CG，在查询时在同一BE上联查，避免网络传输耗时。

建表时可通过：proteries(“colocate_with” = “group_name”)来指定该表归属的CG。

同一个CG中的表的分区数量可以不同，但分桶键的字段类型顺序、数量、副本数必须相同，分桶的数量也必须相同。

参考文档：https://docs.starrocks.com/zh-cn/main/introduction/StarRocks_intro

如有错误，欢迎指正！