箱子加入查詢需要太多時間

前提條件：我需要在一個查詢中找到所有匹配結果，其結果大於40K。箱子加入查詢需要太多時間

要求：兩張表 - product和product_category。我試圖從product_category表中獲取具有匹配類別的所有產品。

表結構：

CREATE TABLE catalog.product (
    product_id string PRIMARY KEY index using plain, 
    name string, 
    sku string, 
) clustered by (product_id) into 4 shards; 

create table catalog.product_category (
    category_id string primary key index using plain, 
    product_id string primary key index using plain, 
    INDEX product_category_index using plain(product_id, category_id) 
    active boolean, 
    parent_category_id integer, 
    updated_at timestamp 
);

連接查詢：

select p.product_id from catalog.product_category pc join catalog.product p on p.product_id=pc.product_id limit 40000;

試過許多東西 - 索引的product_id（包括整數和字符串）等

結果：爲了showup 35K導致它每次超過90秒。

問題：如何優化查詢響應時間？

其他的一些信息： - CPU核心-4 - 試圖與一個或多個節點 - 默認拆分 - 產品總數 - 35K和PRODUCT_CATEGORY只有35K enteries。

用例：我想使用crateDB作爲持久緩存，但是對於給定的查詢響應時間，我們無法真正做到這一點。所以我們將轉向像REDIS或Memcache這樣的內存數據庫。選擇crateDB的原因是對持久數據的查詢能力。

來源

2017-02-17 Sanjay Kumar

似乎除了引擎和查詢以外的其他一些問題。 –

複製查詢並直接在你的數據庫中查詢。（例如，我們檢查PHPMYADMIN） –

你可以嘗試顛倒你的表連接嗎？「產品」，然後是「product_category」 – GauravJ

加入STRING類型的列與加入NUMERIC類型（對字符串值的等式檢查比數字值要貴得多）相比非常昂貴。如果您沒有特殊原因這樣做，我建議將它們更改爲NUMERIC類型（例如INTEGER，LONG，...），這可以將查詢速度提高多倍。

Btw。 index using plain是所有列的默認索引設置，因此您可以將其忽略。此外，複合索引product_category_index無助於改進連接查詢，只需使用包含此索引列的WHERE子句對其進行篩選即可。

更新

的另一項改進，你可以做的是增加一個ORDER BY p.product_id, pc.product_id條款。這樣，加入算法可以在到達您的應用LIMIT時停止。

來源

2017-03-28 09:03:11

@SanjayKumar用'ORDER BY'建議更新了我的答案。 –

我嘗試了你所說的，表現得到極快速度的唯一方法是將所有內容放在一張表中。雖然它比內存訪問速度慢但可比。謝謝@薩巴斯蒂安。 –

箱子加入查詢需要太多時間

回答

相關問題