- BE推荐16核64GB以上，FE推荐8核16GB以上。
- 磁盘可以使用HDD或者SSD。
- CPU必须支持AVX2指令集，
cat /proc/cpuinfo |grep avx2确认有输出即可，如果没有支持，建议更换机器，StarRocks的向量化技术需要CPU指令集支持才能发挥更好的效果。 - 网络需要万兆网卡和万兆交换机。
- 参数配置参考 配置参数
- 通过合理的分区可以有效的裁剪scan的数据量。我们一般从数据的管理角度来选择分区键，选用时间或者区域作为分区键。
- 使用动态分区可以定期自动创建分区，比如每天创建出新的分区。
- 选择高基数的列来作为分桶键（如果有唯一ID就用这个列来作为 分桶键 即可），这样保证数据在各个bucket中尽可能均衡，如果碰到数据倾斜严重的，数据可以使用多列作为分桶键（但一般不要太多）。
- 分桶的数量影响查询的并行度，最佳实践是计算一下数据存储量，将每个tablet设置成 100MB ~ 1GB 之间。
- 在机器比较少的情况下，如果想充分利用机器资源可以考虑使用
BE数量 * cpu core / 2来设置bucket数量。例如有100GB的CSV文件(未压缩)，导入StarRocks，有4台BE，每台64C，只有一个分区，那么可以采用 bucket数量4 * 64 /2 = 128，这样每个tablet的数据也在781MB，同时也能充分利用CPU资源。
- 排序键要根据查询的特点来设计。
- 将经常作为过滤条件和group by的列作为排序键可以加速查询。
- 如果是有大量点查，建议把查询点查的ID放到第一列。例如 查询主要类型是
select sum(revenue) from lineorder where user_id='aaa100'; 并且有很高的并发，强烈推荐把user_id 作为排序键的第一列。 - 如果查询的主要是聚合和scan比较多，建议把低基数的列放在前面。例如 查询的主要类型是
select region, nation, count(*) from lineorder_flat group by region, nation，把region作为第一列、nation作为第二列会更合适。低基数的列放在前面可以有助于数据局部性。
- 用尽量精确的类型。比如能够使用整形就不要用字符串类型，能够使用int就不要使用bigint，精确的数据类型能够更好的发挥数据库的性能。
- 通过session变量 parallel_fragment_exec_instance_num 可以设置查询的并行度（单个 BE 内部的并行度），如果我们觉得查询性能不够好但是cpu资源充足可以通过 set parallel_fragment_exec_instance_num = 16; 来调整这里并行度可以 设置成CPU核数量的一半 。
- 通过set global parallel_fragment_exec_instance_num = 16; 可以让session变量全局有效。
- parallel_fragment_exec_instance_num 受到每个BE的tablet数量的影响，比如 一张表的bucket数量是 32, 有3个分区，分布在4个BE上，那么每个BE的tablet数量是 32 * 3 / 4 = 24, 那么单机的并行度无法超过24，即使你set parallel_fragment_exec_instance_num = 32 ，但是实际执行的时候并行度还是会变成24。
- 对于需要进行高QPS查询的场景，因为机器整体资源是充分利用的，所以建议设置parallel_fragment_exec_instance_num为1，这样可以减少不同查询之间的资源竞争，反而整体可以提升QPS。