2. 程式人生 > >資料分佈不均勻走HASH JOIN導致的效能問題

資料分佈不均勻走HASH JOIN導致的效能問題

阿新 • • 發佈：2019-02-19 
本文永久地址:http://fuxkdb.com/2017/08/09/%E6%95%B0%E6%8D%AE%E5%88%86%E5%B8%83%E4%B8%8D%E5%9D%87%E5%8C%80%E8%B5%B0HASH-JOIN%E5%AF%BC%E8%87%B4%E7%9A%84%E6%80%A7%E8%83%BD%E9%97%AE%E9%A2%98/
  1. 這個案例是JAVA開發說一個過程跑的很慢，之後我跑這個過程，然後通過指令碼抓出了慢的SQL
  2. tb_user_channel  --1W
  3. tb_channel_info  --1W
  4. base_data_login_info 19W
  5. select
  6. count(distinct a
     
    .user_name),count(distinct a.invest_id)
  7. from base_data_login_info a
  8. where a.str_day <='20160304'and a.str_day >='20160301'
  9. and a.channel_id in(select channel_rlat from tb_user_channel a, tb_channel_info b where a.channel_id = b.channel_id and a.user_id =5002)
  10. and a.platform = a.platform
  11. 就是這條SQL，跑完要7分鐘。base_data_login_info
     
    本來是@db_link，但是我在本地建了一個同樣的表發現還是7分鐘左右，所以排除了可能是由於db_link造成問題的可能性
  12. 看一下這個sql返回多少行，結果秒殺，瞬間就出結果了
  13. select
  14.  count(*)
  15. from base_data_login_info@agent a
  16. where a.str_day <='20160304'and a.str_day >='20160301'
  17. and a.channel_id in(select channel_rlat from tb_user_channel a, tb_channel_info b where a.channel_id = b.channel_id 
     
    and a.user_id =5002)
  18. and a.platform = a.platform
  19. 45122行
  20. 之後單獨跑
  21. select
  22. count(distinct a.user_name),count( a.invest_id)
  23. from base_data_login_info a
  24. where a.str_day <='20160304'and a.str_day >='20160301'
  25. and a.channel_id in(select channel_rlat from tb_user_channel a, tb_channel_info b where a.channel_id = b.channel_id and a.user_id =5002)
  26. and a.platform = a.platform
  27. 或
  28. select
  29. count( a.user_name),count(distinct a.invest_id)
  30. from base_data_login_info a
  31. where a.str_day <='20160304'and a.str_day >='20160301'
  32. and a.channel_id in(select channel_rlat from tb_user_channel a, tb_channel_info b where a.channel_id = b.channel_id and a.user_id =5002)
  33. and a.platform = a.platform
  34. 都是秒殺
  35. 單獨count distinct user_name 或 invest_id 都很快，一起count distinct就很慢了
  36. 那麼這時候其實已經可以通過改寫SQL提示效能了，改寫如下
  37. with t1 as
  38. (select
  39.  a.user_name, a.invest_id
  40. from base_data_login_info@agent a
  41. where a.str_day <='20160304'and a.str_day >='20160301'
  42. and a.channel_id in(select channel_rlat from tb_user_channel a, tb_channel_info b where a.channel_id = b.channel_id and a.user_id =5002)
  43. and a.platform = a.platform)
  44. select(select count(distinct user_name)from t1),(select count(distinct invest_id)from t1)from dual;
  45. Plan hash value:3790966246
  46. -------------------------------------------------------------------------------------------------------------------------------
  47. |Id|Operation|Name|Rows|Bytes|TempSpc|Cost(%CPU)|Time|Inst|IN-OUT|
  48. -------------------------------------------------------------------------------------------------------------------------------
  49. |0| SELECT STATEMENT           ||1|||746(1)|00:00:09|||
  50. |1|  SORT AGGREGATE            ||1|27||||||
  51. |2|   VIEW                     | VM_NWVW_2                |40660|1072K||1589(1)|00:00:20|||
  52. |3|    SORT GROUP BY           ||40660|1072K|6752K|1589(1)|00:00:20|||
  53. |4|     VIEW                   ||190K|5021K||878(1)|00:00:11|||
  54. |5|      TABLE ACCESS FULL     | SYS_TEMP_0FD9D671E_EB8EA |190K|9M||878(1)|00:00:11|||
  55. |6|  SORT AGGREGATE            ||1|27||||||
  56. |7|   VIEW                     | VM_NWVW_3                |41456|1093K||1593(1)|00:00:20|||
  57. |8|    SORT GROUP BY           ||41456|1093K|6752K|1593(1)|00:00:20|||
  58. |9|     VIEW                   ||190K|5021K||878(1)|00:00:11|||
  59. |10|      TABLE ACCESS FULL     | SYS_TEMP_0FD9D671E_EB8EA |190K|9M||878(1)|00:00:11|||
  60. |11|  TEMP TABLE TRANSFORMATION |||||||||
  61. |12|   LOAD AS SELECT           | SYS_TEMP_0FD9D671E_EB8EA ||||||||
  62. |*13|    HASH JOIN RIGHT SEMI    ||190K|22M||744(1)|00:00:09|||
  63. |14|     VIEW                   | VW_NSO_1                 |11535|304K||258(1)|00:00:04|||
  64. |*15|      HASH JOIN             ||11535|360K||258(1)|00:00:04|||
  65. |*16|       TABLE ACCESS FULL    | TB_USER_CHANNEL          |11535|157K||19(0)|00:00:01|||
  66. |17|       TABLE ACCESS FULL    
            
      
    
           
    
              
              
    
            
    
            
    相關推薦
    
			   
            
            
            
 

    

    
    
    
    資料分佈不均勻走HASH JOIN導致的效能問題
    
     
     
								
								            
						
                

本文永久地址:http://fuxkdb.com/2017/08/09/%E6%95%B0%E6%8D%AE%E5%88%86%E5%B8%83%E4%B8%8D%E5%9D%87%E5%8C% 
    

    
  
 

    

    
    
    
    oracle 效能優化操作七：索引提高資料分佈不均勻時查詢效率
    
     
     
                索引的選擇性低，但資料的分佈差異很大時，仍然可以利用索引提高效率。 A、資料分佈不均勻的特殊情況下，選擇性不高的索引也要建立。 表ServiceInfo中資料量很大，假設有一百萬行，其中有一個欄位DisposalCourseFlag，取範圍為列舉：[0，1，2，3，4，5，6 
    

    
  
 

    

    
    
    
    MongoDB雜湊分片為什麼分佈不均勻？
    
     
     
                
原文地址


今天接到一個使用者反饋的問題，sharding叢集，使用wiredtiger引擎，某個DB下集合全部用的hash分片，show
 dbs 發現其中一個shard裡該DB的大小，跟其他的集合差別很大，其他基本在60G左右，而這個shard在200G左右？



 
    

    
  
 

    

    
    
    
    Redis中雜湊分佈不均勻該怎麼辦
    
     
     # 前言

`Redis` 是一個鍵值對資料庫，其鍵是通過雜湊進行儲存的。整個 `Redis` 可以認為是一個外層雜湊，之所以稱為外層雜湊，是因為 `Redis` 內部也提供了一種雜湊型別，這個可以稱之為內部雜湊。當我們採用雜湊物件進行資料儲存時，對整個 `Redis` 而言，就經過了兩層雜湊儲存。

# 雜 
    

    
  
 

    

    
    
    
    資料型別不一致導致的SQL不走索引
    
     
     
                
前幾天，同事發來一條SQL，說是更新操作的時候執行的很慢，我看了下，資料量也不是很大。再檢視執行計劃，發現是執行路徑錯誤導致的，可是為什麼會走錯誤的執行路徑呢？統計資訊並沒有太大的問題。在這裡模擬下：
資料準備：

--1.資料準備，表一：
DROP TABLE t_tes 
    

    
  
 

    

    
    
    
    22、資料分佈演算法：hash+一致性hash+redis cluster的hash slot
    
     
      
 
 1、redis cluster介紹 （1）自動將資料進行分片，每個master上放一部分資料 
 （2）提供內建的高可用支援，部分master不可用時，還是可以繼續工作的在redis cluster架構下，每個redis要放開兩個埠號，比如一個是6379，另外一個就是加10000的埠號，比如1637 
    

    
  
 

    

    
    
    
    解決.net Core中WebApi自動Model驗證導致資料格式不能統一
    
     
     　　最近做專案用WebAPI Core時，想把返回資料的格式，統一弄成：{“errorMsg”:"xxx","Data":"xxxx"}這種。誰知道，WebAPI的model會自動驗證，於是乎格式成了： 
 
我想能不能自己像在MVC裡面那樣自己控制model驗證：ModelState.IsValid。找了很 
    

    
  
 

    

    
    
    
    Django中button的處理 & ajax提交資料時不走Form元件驗證
    
     
     
								
								            
							
							
							button分類：


type=’submit’ 預設型別，會預設提交表單~
type=’button’
type=’reset’


專案中出現的問題:


  ajax提交資料時不走Form元件驗 
    

    
  
 

    

    
    
    
    mysql master-slave搭建測試，附帶雙master FailOver導致資料結果不一致的一些想法
    
     
     
                
mysql主從複製：
首先修改master，slave中的配置檔案，my.ini或my.conf，都加在[mysqld]域中;
master中的配置：
#replication option
server-id=1
log-bin=mysql-bin.log
slave中的 
    

    
  
 

    

    
    
    
    UTF-8編碼Emoji表情或者某些特殊字元是4個位元組導致資料插不進去
    
     
     
                
1.中文寫入亂碼問題：
我輸入的中文編碼是urf8的，建的庫是urf8的，但是插入mysql總是亂碼，一堆"???????????????????????"
我用的是ibatis，終於找到原因了，我是這麼解決的：
原url地址是：jdbc:mysql://localhost 
    

    
  
 

    

    
    
    
    【資料預處理】樣本不均勻
    
     
     工業界機器學習典型問題:正負樣本分佈極不均勻(通常<1:10000），有什麼較好的方案構造訓練集的正負樣本分佈？構造後如何解決訓練資料與預測的分佈不一致？上取樣、下采樣、代價敏感，沒什麼好辦法。這個之前調研過，主要分重取樣和欠取樣！這種不平衡是因為比率的不平衡給一些學習方法帶來問題。但是在某些領域，比如 
    

    
  
 

    

    
    
    
    Hibernate 註解序列生成主鍵執行完select seq_t_user.nextval後不執行insert等語句導致 執行save()或update()方法無效
    
     
     hiberna   不能   nal   自動提交   ext   無效   pen   mave   ransac   題主解決方法：
      
          1)在DAO中獲取session的時候采用sessionFactory.getCurrentSession();不用
           
    

    
  
 

    

    
    
    
    php-fpm 進程在雲服務器cpu分配不均勻
    
     
     int   部分   服務器   div   php-fpm   服務   雲服務器   logs   fpm   8核的雲服務器，開了200個php-fpm進程，用top命令查看  大部分進程都在cpu 0 上跑著，導致其他cpu 負載很低，cpu分配不均勻；
使用shell 解決問題:
列出所有php-f 
    

    
  
 

    

    
    
    
    為什麽不取消註冊BroadcastReceiver會導致內存泄漏
    
     
     tro   什麽   roi   sta   還得   -c   交流   span   筆記   原始問題是這樣：然後扔到了很多Android開發交流群裏。接著產生了很多的見解，我感覺比較靠譜的有以下：1、onDestroy被回調代不代表Activity被回收了？官方是這麽說的Perform any fin 
    

    
  
 

    

    
    
    
    android 橫豎屏切換不重走生命周期
    
     
     orien   man   ati   nta   系統   生命周期   oar   hang   andro   android在系統配置發生改變時，Activity會被重新創建，但是某些情況下我們希望系統配置改變時不會重新創建Activity，這個時候我們可以給Activity指定相對應的configC 
    

    
  
 

    

    
    
    
    從拼產品到拼營銷，頭條是不是走偏了？
    
     
     進入   命中   資金   而且   影響   人的   容易   獲得   政策   “個性化的信息推薦引擎”今日頭條走到今天，“算法”功不可沒。但這款以技術取勝的產品，在人民日3評算法之後，正越發的焦慮。
一、頭條的焦慮
人們常說，沒有一帆風順的路，人生總要經歷坎坷。過去的幾年，頭條的發展可謂順風順水， 
    

    
  
 

    

    
    
    
    Firebird hash join
    
     
     detail   express   sql   access   哈希   fire   alt   lan   can   Firebird 現可支持哈希連接（hash join），各中大型數據庫，哈希連接已成為平常，相對於循環嵌套連接（Nested Loop Join），在數據量較大的情況下，哈希連接性 
    

    
  
 

    

    
    
    
    資料處理不常用語句3
    
     
      
 
 ###########################時間序列#################################
data_bs.index = pd.date_range
(start='2018-08-01 00:00:00',periods=744,freq='h',norma 
    

    
  
 

    

    
    
    
    談Elasticsearch下分散式儲存的資料分佈
    
     
      
 
  
  
   對於一個分散式儲存系統來說，資料是分散儲存在多個節點上的。如何讓資料均衡的分佈在不同節點上，來保證其高可用性？所謂均衡，是指系統中每個節點的負載是均勻的，並且在發現有不均勻的情況或者有節點增加/刪除時，能及時進行調整，保持均勻狀態。本文將探討Elasticsearch的資料分佈方法， 
    

    
  
 

    

    
    
    
    伺服器資料恢復通用方法/伺服器硬碟故障導致資料丟失解決方案
    
     
      
 
 [伺服器資料恢復原因推斷] 
 伺服器資料丟失情況很多，通常無法明確伺服器資料丟失的原因，常見的丟失原因有：伺服器硬碟出現故障，管理員或者伺服器自動進行fsck操作，這一操作可能造成更加嚴重資料丟失或者導致伺服器資料恢復的難度增加。伺服器資料丟失後執行mkfs操作，若操作未完成則容易導致部分塊組全部