SQL クエリ
このトピックでは、SQL に関するよくある質問への回答を提供します。
StarRocks はクエリ結果のキャッシュをサポートしていますか?
StarRocks は最終的なクエリ結果を直接キャッシュしません。v2.5 以降、StarRocks は Query Cache 機能を使用して、キャッシュ内の最初の段階の集約の中間結果を保存します。以前のクエリと意味的に同等の新しいクエリは、キャッシュされた計算結果を再利用して計算を高速化できます。Query Cache は BE メモリを使用します。詳細は Query cache を参照してください。
計算に Null が含まれる場合、ISNULL() 関数を除いて関数の計算結果は false になります
標準 SQL では、NULL 値を持つオペランドを含むすべての計算は NULL を返します。
StarRocks は DECODE 関数をサポートしていますか?
StarRocks は Oracle データベースの DECODE 関数をサポートしていません。StarRocks は MySQL と互換性があるため、CASE WHEN ステートメントを使用できます。
StarRocks の主キーテーブルにデータがロードされた直後に最新のデータをクエリできますか?
はい。StarRocks は Google Mesa を参考にしてデータをマージします。StarRocks では、BE がデータマージをトリガーし、データをマージするための 2 種類の Compaction を持っています。データマージが完了していない場合は、クエリ中に完了します。したがって、データロード後に最新のデータを読み取ることができます。
StarRocks に保存された utf8mb4 文字が切り捨てられたり文字化けしたりしますか?
いいえ。
alter table コマンドを実行すると "table's state is not normal" というエラーが発生する
このエラーは、前回の変更が完了していないために発生します。以下のコードを実行して、前回の変更の状態を確認できます。
show tablet from lineitem where State="ALTER";
変更操作にかかる時間はデータ量に関連しています。一般的に、変更は数分で完了します。テーブルを変更している間は、データロードが変更の完了速度を低下させるため、StarRocks へのデータロードを停止することをお勧めします。
Apache Hive の外部テーブルをクエリすると "get partition detail failed: org.apache.doris.common.DdlException: get hive partition meta data failed: java.net.UnknownHostException:hadooptest" というエラーが発生する
このエラーは、Apache Hive パーティションのメタデータを取得できない場合に発生します。この問題を解決するには、core-sit.xml と hdfs-site.xml を fe.conf ファイルと be.conf ファイルにコピーしてください。
データをクエリすると "planner use long time 3000 remaining task num 1" というエラーが発生する
このエラーは通常、完全なガベジコレクション (full GC) によって発生し、バックエンドのモニタリングと fe.gc ログを使用して確認できます。この問題を解決するには、以下の操作のいずれかを実行します。
- SQL のクライアントが複数のフロントエンド (FEs) に同時にアクセスできるようにして、負荷を分散します。
- Java Virtual Machine (JVM) のヒープサイズを fe.conf ファイルで 8 GB から 16 GB に変更して、メモリを増やし、full GC の影響を軽減します。
列 A のカーディナリティが小さい場合、select B from tbl order by A limit 10 のクエリ結果が毎回異なる
SQL は列 A の順序を保証することしかできず、列 B の順序が各クエリで同 じであることを保証できません。MySQL はスタンドアロンデータベースであるため、列 A と列 B の順序を保証できます。
StarRocks は分散型データベースであり、基礎となるテーブルに保存されたデータはシャーディングパターンになっています。列 A のデータは複数のマシンに分散されているため、複数のマシンから返される列 B の順序は各クエリで異なる場合があり、結果として B の順序が毎回一致しません。この問題を解決するには、select B from tbl order by A limit 10 を select B from tbl order by A,B limit 10 に変更します。
SELECT * と SELECT の間に列効率の大きなギャップがあるのはなぜですか?
この問題を解決するには、プロファイルを確認し、MERGE の詳細を確認してください。
-
ストレージ層での集約に時間がかかりすぎていないか確認します。
-
インジケータ列が多すぎるか確認します。もしそうなら、何百万行もの列を集約します。
MERGE:
- aggr: 26s270ms
- sort: 15s551ms
DELETE はネストされた関数をサポートしていますか?
ネストされた関数はサポートされていません。例えば、DELETE from test_new WHERE to_days(now())-to_days(publish_time) >7; の to_days(now()) などです。