- StarRocks
- 产品简介
- 快速开始
- 表设计
- 数据导入
- 数据提取
- 使用StarRocks
- 管理手册
- 参考手册
- SQL参考
- 用户账户管理
- 集群管理
- ADMIN CANCEL REPAIR
- ADMIN CHECK TABLET
- ADMIN REPAIR
- ADMIN SET CONFIG
- ADMIN SET REPLICA STATUS
- ADMIN SHOW CONFIG
- ADMIN SHOW REPLICA DISTRIBUTION
- ADMIN SHOW REPLICA STATUS
- ALTER SYSTEM
- CANCEL DECOMMISSION
- CREATE RESOURCE GROUP
- CREATE FILE
- DROP FILE
- INSTALL PLUGIN
- SHOW BACKENDS
- SHOW BROKER
- SHOW FRONTENDS
- SHOW FULL COLUMNS
- SHOW INDEX
- SHOW PLUGINS
- SHOW TABLE STATUS
- SHOW FILE
- UNINSTALL PLUGIN
- DDL
- ALTER DATABASE
- ALTER TABLE
- ALTER VIEW
- ALTER RESOURCE
- BACKUP
- CANCEL BACKUP
- CANCEL RESTORE
- CREATE DATABASE
- CREATE INDEX
- CREATE MATERIALIZED VIEW
- CREATE REPOSITORY
- CREATE RESOURCE
- CREATE TABLE AS SELECT
- CREATE TABLE LIKE
- CREATE TABLE
- CREATE VIEW
- CREATE FUNCTION
- DROP DATABASE
- DROP INDEX
- DROP MATERIALIZED VIEW
- DROP REPOSITORY
- DROP RESOURCE
- DROP TABLE
- DROP VIEW
- DROP FUNCTION
- HLL
- RECOVER
- RESTORE
- SHOW RESOURCES
- SHOW FUNCTION
- TRUNCATE TABLE
- DML
- ALTER ROUTINE LOAD
- BROKER LOAD
- CANCEL LOAD
- CANCEL EXPORT
- DELETE
- EXPORT
- GROUP BY
- INSERT
- PAUSE ROUTINE LOAD
- RESUME ROUTINE LOAD
- CREATE ROUTINE LOAD
- SELECT
- SHOW ALTER
- SHOW BACKUP
- SHOW DATA
- SHOW DATABASES
- SHOW DELETE
- SHOW DYNAMIC PARTITION TABLES
- SHOW EXPORT
- SHOW LOAD
- SHOW PARTITIONS
- SHOW PROPERTY
- SHOW REPOSITORIES
- SHOW RESTORE
- SHOW ROUTINE LOAD
- SHOW ROUTINE LOAD TASK
- SHOW SNAPSHOT
- SHOW TABLES
- SHOW TABLET
- SHOW TRANSACTION
- SPARK LOAD
- STOP ROUTINE LOAD
- STREAM LOAD
- 数据类型
- 辅助命令
- 函数参考
- 日期函数
- convert_tz
- curdate
- current_timestamp
- curtime
- datediff
- date_add
- date_format
- date_sub
- date_trunc
- day
- dayname
- dayofmonth
- dayofweek
- dayofyear
- from_days
- from_unixtime
- hour
- minute
- month
- monthname
- now
- second
- str_to_date
- timediff
- time_slice
- timestampadd
- timestampdiff
- to_date
- to_days
- unix_timestamp
- utc_timestamp
- week
- weekofyear
- year
- date_floor
- hours_diff
- minutes_diff
- months_diff
- seconds_diff
- weeks_diff
- years_diff
- quarter
- timestamp
- time_to_sec
- str2date
- microseconds_add
- microseconds_sub
- 加密函数
- 地理位置函数
- 字符串函数
- JSON 函数
- 模糊/正则匹配函数
- 工具函数
- 聚合函数
- Bitmap函数
- 数组函数
- bit函数
- cast函数
- hash函数
- 条件函数
- 百分位函数
- 数学函数
- 日期函数
- 系统变量
- 错误码
- 系统限制
- SQL参考
- 常见问题解答
- 性能测试
- Release Notes
查询相关问题
构建物化视图失败:fail to allocate memory
修改 be.conf 中的memory_limitation_per_thread_for_schema_change
。
该参数表示单个schema change任务允许占用的最大内存,默认大小2G。
StarRocks对结果缓存这块有限制吗?
starrocks不会对结果缓存,第一次查询慢后面快的原因是因为后续的查询使用了操作系统的 pagecache。
pagecache大小可以通过设置 be.conf 中storage_page_cache_limit
参数来限制pagecache,默认20G。
当字段为NULL时,除了is null, 其他所有的计算结果都是false
标准sql中null和其他表达式计算结果都是null。
[bigint等值查询中加引号]出现多余数据
select cust_id,idno
from llyt_dev.dwd_mbr_custinfo_dd
where Pt= ‘2021-06-30’
and cust_id = ‘20210129005809043707’
limit 10 offset 0;
+---------------------+-----------------------------------------+
| cust_id | idno |
+---------------------+-----------------------------------------+
| 20210129005809436 | yjdgjwsnfmdhjw294F93kmHCNMX39dw= |
| 20210129005809436 | sdhnswjwijeifme3kmHCNMX39gfgrdw= |
| 20210129005809436 | Tjoedk3js82nswndrf43X39hbggggbw= |
| 20210129005809436 | denuwjaxh73e39592jwshbnjdi22ogw= |
| 20210129005809436 | ckxwmsd2mei3nrunjrihj93dm3ijin2= |
| 20210129005809436 | djm2emdi3mfi3mfu4jro2ji2ndimi3n= |
+---------------------+-----------------------------------------+
select cust_id,idno
from llyt_dev.dwd_mbr_custinfo_dd
where Pt= ‘2021-06-30’
and cust_id = 20210129005809043707
limit 10 offset 0;
+---------------------+-----------------------------------------+
| cust_id | idno |
+---------------------+-----------------------------------------+
| 20210189979989976 | xuywehuhfuhruehfurhghcfCNMX39dw= |
+---------------------+-----------------------------------------+
问题描述:
where里bigint类型,查询加单引号,查出很多无关数据。
解决方案:
字符串和int比较,相当于 cast 成double。int比较时,不要加引号。同时,加了引号,还会导致没法命中索引。
StarRocks有decode函数吗?
不支持Oracle中的decode函数,StarRocks语法兼容MySQL,可以使用case when。
StarRocks的主键覆盖是立刻生效的吗?还是说要等后台慢慢合并数据?
StarRocks的后台合并就是参考google的mesa的模型,有两层compaction,会后台策略触发合并。如果没有合并完成,查询的时候会合并,但是读出来只会有一个最新的版本,不存在「导入后数据读不到最新版本」的情况。
StarRocks存储utf8mb4的字符 会不会被截断或者乱码?
MySQL的“utf8mb4”是真正的“UTF-8”,所以StarRocks是没问题的
[Schema change] alter table 时显示:table's state is not normal
Alter table 是异步的,之前有过alter table 操作还没完成,可以通过
show tablet from lineitem where State="ALTER";
查看alter状态,执行时间与数据量大小有关系,一般是分钟级别,建议alter过程中停止数据导入。导入会降低alter 速度。
[hive外部表查询问题] 查询hive外部表的时候报错获取分区失败
问题描述:
查询hive外部表是具体报错信息为:
get partition detail failed: com.starrocks.common.DdlException: get hive partition meta data failed: java.net.UnknownHostException:hadooptest(具体hdfs-ha的名字)
解决方案:
把core-site.xml和hdfs-site.xml文件拷贝到 fe/conf 和 be/conf中即可。
问题原因:
获取配置单元分区元数据失败。
大表查询结果慢,没有谓词下推
多张大表关联时,旧planner有时没有自动谓词下推,比如:
A JOIN B ON A.col1=B.col1 JOIN C on B.col1=C.col1 where A.col1='北京' ,
可以更改为:
A JOIN B ON A.col1=B.col1 JOIN C on A.col1=C.col1 where A.col1='北京',
或者升级较新版本并开启CBO,然后会有此类谓词下推操作,优化查询性能。
查询报错 planner use long time 3000 remaining task num 1
解决方案:
查看fe.gc日志看是否是多并发引起的full gc问题。
如果查看后台监控和日志初步判断有频繁gc,两个方案:
- 可以让sqlclient去同时访问多个fe去做负载均衡;
- 修改fe.conf中jvm8g为16g(更大内存,减少 full gc 影响);
当A基数很小时,select B from tbl order by A limit 10查询结果每次不一样
解决方案:
select B from tbl order by A,B limit 10
,将B也进行排序就能保证结果一致。
问题原因:
上面的SQL只能保证A是有序的,并不能保证每次查询出来的B顺序是一致的,MySQL能保证这点因为它是单机数据库,而StarRocks是分布式数据库,底层表数据存储是sharding的,A的数据分布在多台机器上,每次查询多台机器返回的顺序可能不同,就会导致每次B顺序不一致。
select * 和select 具体列效率差距过大
select * 和select 时具体列效率差距会很大,这时我们应该去排查profile,看MERGE的具体信息。
- 确认是否是存储层聚合消耗的时间过长。
- 确认是否指标列有很多,需要对几百万行的几百列进行聚合。
MERGE:
- aggr: 26s270ms
- sort: 15s551ms
目前delete中不支持嵌套函数
类似这种:DELETE from test_new WHERE to_days(now())-to_days(publish_time) >7;
to_days(now())这个嵌套了,目前不支持。
在一个 database 中有上百张表后,use database 会特别慢
mysql -uroot -h127.0.0.1 -P8867 -A
,client连接的时候加上-A参数,-A不会预读数据库信息,切换database会很快。
be/fe日志文件太多,怎么处理?
调整日志级别和参数大小,详情参考文档中log相关的参数默认值和作用说明:参数配置
更改副本数失败:table lineorder is colocate table, cannot change replicationNum
colocate table是有group的,一个组包含多个表,不支持单个表修改副本数,现在的话,需要把group内的所有表的group_with属性设置成空,然后给所有的表设置一下replication_num,然后再把所有表的group_with属性设置回去。
varchar 设置成最大值对存储有没有影响
varchar是变长存储,存储跟数据实际长度有关,建表时指定不同的varchar长度对同一数据的查询性能影响很小
truncate table 失败,报错create partititon timeout
目前truncate会先创建对应空分区再swap,如果存在大量创建分区任务,积压就会超时,compaction过程中会持锁很长时间,也导致建表拿不到锁,如果集群导入比较多,设置be.conf中参数tablet_map_shard_size=512,可以降低锁冲突
hive外表访问出错,Failed to specify server's Kerberos principal name
在fe/be conf的hdfs-site.xml里加如下信息:
<property>
<name>dfs.namenode.kerberos.principal.pattern</name>
<value>*</value>
</property>
2021-10在StarRocks里是合法的日期格式吗?可以用作分区字段吗?
不可以,需要调整成2021-10-01这种格式再分区。
StarRocks on ES,创建Elasticsearch外表时,如果相关字符串长度过长,超过256,同时Elasticsearch使用动态mapping, 那么使用select语句将会导致无法查询到该列
动态mapping 这时候es的数据类型为 "k4": { "type": "text", "fields": { "keyword": { "type": "keyword", "ignore_above": 256 } } }
starRocks 将使用 keyword 数据类型转换该查询语句,因为该列的数据 keyword 长度超过 256,所以无法查询该列。
解决办法:去除该字段映射中的 "fields": { "keyword": { "type": "keyword", "ignore_above": 256 } }
让其使用 text 即可。
- 查询相关问题
- 构建物化视图失败:fail to allocate memory
- StarRocks对结果缓存这块有限制吗?
- 当字段为NULL时,除了is null, 其他所有的计算结果都是false
- bigint等值查询中加引号出现多余数据
- StarRocks有decode函数吗?
- StarRocks的主键覆盖是立刻生效的吗?还是说要等后台慢慢合并数据?
- StarRocks存储utf8mb4的字符 会不会被截断或者乱码?
- Schema change alter table 时显示:table's state is not normal
- hive外部表查询问题 查询hive外部表的时候报错获取分区失败
- 大表查询结果慢,没有谓词下推
- 查询报错 planner use long time 3000 remaining task num 1
- 当A基数很小时,select B from tbl order by A limit 10查询结果每次不一样
- select * 和select 具体列效率差距过大
- 目前delete中不支持嵌套函数
- 在一个 database 中有上百张表后,use database 会特别慢
- be/fe日志文件太多,怎么处理?
- 更改副本数失败:table lineorder is colocate table, cannot change replicationNum
- varchar 设置成最大值对存储有没有影响
- truncate table 失败,报错create partititon timeout
- hive外表访问出错,Failed to specify server's Kerberos principal name
- 2021-10在StarRocks里是合法的日期格式吗?可以用作分区字段吗?
- StarRocks on ES,创建Elasticsearch外表时,如果相关字符串长度过长,超过256,同时Elasticsearch使用动态mapping, 那么使用select语句将会导致无法查询到该列