国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

案例分享：Gbase慢sql優化案例

IT那活兒 / 3366人閱讀
案例分享：Gbase慢sql優化案例

點擊上方“IT那活兒”公眾號，關注后了解更多內容，不管IT什么活兒，干就完了?。?！

一

慢SQL

此處的sql是相同類型的測試sql，方便大家閱讀。首先把sql拿到生產測試發現確認要很長時間，跑了幾分鐘根本跑不出來。
Sql: select
a.u_id,
b.b_id,
c.c_id,
from a.a a
left join b.b b on a.u id=b.u_id
left join c.c c on b.c_id=c.c_id
limit 100000;
二

慢SQL優化

1. 嘗試去除一個left join條件
等了一會跑出來了。
耗時1分50秒。
2. 再看表數據量
  • a表 四萬條記錄
  • b表將近八千萬條記錄
查詢方式也符合查詢邏輯，大小表關聯查詢一般用小表驅動大表。
3. 嘗試用in 
 有一定的提升，但是根據業務邏輯需要用到b表中很多的字段，而in后面的字段，只能有一個 。

4. 改變思路看表的分布方式

  • 復制表：isReplicate=YEShash
  • 分布表：hash_column= col_name，分布鍵是col_name
  • 隨機分布表：isReplicate=NO，hash_column=null
可以看到小表a是隨機分布表。大表b是哈希分布表。
再看執行計劃：

顯示界面主要組成部分：

  • ID：SQL執行步驟，順序從下向上；
  • MOTION：某個步驟的結果處理方式；
  • OPERATION：某個步驟內的具體執行操作；
  • TABLE：某個operation涉及的表；
  • CONDITION：某個operation操作涉及的條件。
可以看到Motion列有個BROADCAST步驟。
因為小表是隨機分布，即使大表是哈希分布也無法走分布鍵，所以小表拉了復制表。這個筆者理解應該是類似重廣播，就是每一個節點都會有一份復制表。
5. 測試如果小表加上分布鍵會不會提升查詢速度
因為Gbase無法在表建成后加分布鍵 所以新建一張測試表。
需要注意括號內的字段加單引號，再將數據導入。
測試：
結果是毫秒級，如果不加分布鍵則需要1分50秒。
再看執行計劃：
沒有了BROADCAST這個步驟。于是將結果與建議反饋業務側。


本文作者：徐 瑞(上海新炬王翦團隊）

本文來源：“IT那活兒”公眾號

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/129168.html

相關文章

  • 2021年9月國產數據庫大事記

    .markdown-body{word-break:break-word;line-height:1.75;font-weight:400;font-size:15px;overflow-x:hidden;color:#333}.markdown-body h1,.markdown-body h2,.markdown-body h3,.markdown-body h4,.markdown-body...

    suemi 評論0 收藏0

  • 數據庫收集 - 收藏集 - 掘金

    摘要：前言在使用加載數據數據庫常見的優化操作后端掘金一索引將放第一位，不用說，這種優化方式我們一直都在悄悄使用，那便是主鍵索引。 Redis 內存壓縮實戰 - 后端 - 掘金在討論Redis內存壓縮的時候，我們需要了解一下幾個Redis的相關知識。 壓縮列表 ziplist Redis的ziplist是用一段連續的內存來存儲列表數據的一個數據結構，它的結構示例如下圖 zlbytes: 記錄整...

    Little_XM 評論0 收藏0

發表評論

0條評論

IT那活兒

男|高級講師

TA的文章

閱讀更多
最新活動
閱讀需要支付1元查看
<