2. 程式人生 > 其它 >關於查詢轉換的一些簡單分析(二) (r3筆記第68天)

關於查詢轉換的一些簡單分析(二) (r3筆記第68天)

阿新 • • 發佈：2022-05-04

關於查詢轉換的作用，在之前的一篇博文裡面也大概說了檢視合併和子查詢巢狀的部分。http://blog.itpub.net/23718752/viewspace-1310272/ 今天來舉一個例項來分析一下。 這條sql語句是在生產環境中執行的，目前執行速度在0.1秒左右。我們來看看從查詢轉換的角度來看，對於同一條sql語句，反覆的變化就能夠折騰出不少的東西來。 sql語句如下：

select  soc
  from SERVICE_DETAILS ser  --大表，資料量過億，做了分割槽
where  agreement_no in (select subscriber_no
                          from  subscriber  --中級表，資料量百萬
                          where sub_status = 'A'
                           and  (subscriber_no, prim_resource_tp) in (select agreement_no, resource_type from  agreement_resource where resource_value='0910600138')  --大表，資料量千萬，做了分割槽
                            )
   and soc_status =  'A'

執行計劃如下：


Plan hash value:  1540053094
-----------------------------------------------------------------------------------------------------------------------------------
|  Id  | Operation                                | Name                   | Rows   | Bytes | Cost (%CPU)| Time     | Pstart| Pstop  |
-----------------------------------------------------------------------------------------------------------------------------------
|    0 | SELECT STATEMENT                         |                        |     7  |   196 |     7  (15)| 00:00:01 |       |       |
|   1 |  NESTED LOOPS                             |                        |       |       |            |           |       |       |
|   2 |   NESTED LOOPS                           |                         |     7 |   196 |     7  (15)| 00:00:01 |       |        |
|   3 |    VIEW                                  | VW_NSO_1               |      1 |    13 |     5   (0)| 00:00:01 |       |       |
|   4 |     HASH  UNIQUE                          |                        |     1 |    36 |             |          |       |       |
|   5 |      NESTED LOOPS                         |                        |       |       |            |          |       |        |
|   6 |       NESTED LOOPS                       |                         |     1 |    36 |     5   (0)| 00:00:01 |       |       |
|   7 |         PARTITION RANGE ALL               |                        |     1 |    25 |      4   (0)| 00:00:01 |     1 |    11 |
|   8 |         TABLE ACCESS BY LOCAL  INDEX ROWID| AGREEMENT_RESOURCE     |     1 |    25 |     4   (0)| 00:00:01 |      1 |    11 |
|*  9 |          INDEX RANGE SCAN                |  AGREEMENT_RESOURCE_1IX |     1 |       |     3   (0)| 00:00:01 |     1 |    11  |
|* 10 |        INDEX UNIQUE SCAN                 | SUBSCRIBER_PK          |      1 |       |     1   (0)| 00:00:01 |       |       |
|* 11 |       TABLE  ACCESS BY INDEX ROWID        | SUBSCRIBER             |     1 |    11 |     1    (0)| 00:00:01 |       |       |
|* 12 |    INDEX RANGE SCAN                       | SERVICE_DETAILS_PK     |     9 |       |     1   (0)| 00:00:01 |       |        |
|* 13 |   TABLE ACCESS BY INDEX ROWID            | SERVICE_DETAILS         |     7 |   105 |     1   (0)| 00:00:01 |       |        |
-----------------------------------------------------------------------------------------------------------------------------------
Predicate  Information (identified by operation  id):
---------------------------------------------------
   9 -  access("RESOURCE_VALUE"='0910600138')
  10 -  access("SUBSCRIBER_NO"="AGREEMENT_NO")
  11 - filter("SUB_STATUS"='A' AND  "PRIM_RESOURCE_TP"="RESOURCE_TYPE")
  12 -  access("AGREEMENT_NO"="SUBSCRIBER_NO")
  13 - filter("SOC_STATUS"='A')

對應的索引資訊如下。

INDEX_NAME                      TABLESPACE INDEX_TYPE UNIQUENES PAR COLUMN_LIST                     TABLE_TYPE STATUS   NUM_ROWS LAST_ANAL  G
------------------------------ ---------- ---------- --------- ---  ------------------------------ ---------- ------ ---------- ---------  -
SERVICE_DETAILS_PK             INDXS01    NORMAL     UNIQUE    NO   AGREEMENT_NO,SOC,SOC_SEQ_NO    TABLE      VALID   117595228 23-OCT-14  N

INDEX_NAME                     TABLESPACE INDEX_TYPE UNIQUENES  PAR COLUMN_LIST                    TABLE_TYPE STATUS   NUM_ROWS LAST_ANAL  G
------------------------------ ---------- ---------- --------- ---  ------------------------------ ---------- ------ ---------- ---------  -
SUBSCRIBER_1IX                 INDXM01    NORMAL     NONUNIQUE NO   CH_NODE_ID                     TABLE      VALID     6994331 23-OCT-14  N
SUBSCRIBER_2IX                 INDXM01    NORMAL     NONUNIQUE NO   EXTERNAL_ID                    TABLE      VALID     6994329 23-OCT-14  N
SUBSCRIBER_3IX                 INDXM01    NORMAL     NONUNIQUE NO   CUSTOMER_ID,SUB_STATUS         TABLE      VALID     6994331 23-OCT-14  N
SUBSCRIBER_PK                  INDXM01    NORMAL     UNIQUE    NO   SUBSCRIBER_NO                  TABLE      VALID     6994331 23-OCT-14  N

INDEX_NAME                     TABLESPACE INDEX_TYPE UNIQUENES  PAR COLUMN_LIST                    TABLE_TYPE STATUS   NUM_ROWS LAST_ANAL  G
------------------------------ ---------- ---------- --------- ---  ------------------------------ ---------- ------ ---------- ---------  -
AGREEMENT_RESOURCE_1IX                    NORMAL     NONUNIQUE YES  RESOURCE_VALUE,RESOURCE_TYPE   TABLE      N/A      25762156 22-OCT-14  N
AGREEMENT_RESOURCE_2IX                    NORMAL     NONUNIQUE YES  FROM_RESOURCE_VAL,RESOURCE_TYPE TABLE      N/A      25762156 22-OCT-14 N                                                                     
AGREEMENT_RESOURCE_3IX                    NORMAL     NONUNIQUE YES  RESOURCE_SCOPE_ID              TABLE      N/A             0 22-OCT-14  N
AGREEMENT_RESOURCE_PK                     NORMAL     UNIQUE    YES  AGREEMENT_NO,RESRC_SEQ_NO,AGREEMENT_KEY  TABLE      N/A      25762156  22-OCT-14 N

這個查詢能夠從千萬級的記錄中耗時0.1秒就查出資料，確實是比較理想的。我們來試著折騰一下這條sql語句。 -->改動第一步，從in 切換為exists 我們先從語句的等價性來看，in切換為exists，標黃部分為變化的部分，語句的效果是等價的。

select  soc
  from SERVICE_DETAILS ser
where exists  (select subscriber_no
                           from subscriber
                         where ser.agreement_no=subscriber.subscriber_no
           and sub_status = 'A'
                           and (subscriber_no,  prim_resource_tp) in (select agreement_no, resource_type from agreement_resource  where resource_value='0910600138')
                           )
   and  soc_status = 'A'

但是執行計劃就讓人大失所望。


Plan hash value:  3038362059
-----------------------------------------------------------------------------------------------------------------------------
|  Id  | Operation                            | Name                  | Rows  |  Bytes | Cost (%CPU)| Time     | Pstart| Pstop  |
------------------------------------------------------------------------------------------------------------------------------
|    0 | SELECT STATEMENT                     |                       |     7 |    105 |   300M  (1)|999:59:59 |        |       |
|*  1 |  FILTER                              |                        |       |       |            |          |       |       |
|*  2 |   TABLE ACCESS FULL                  |  SERVICE_DETAILS       |    96M|  1384M|   530K  (1)| 01:46:06 |       |        |
|   3 |   NESTED LOOPS                       |                       |      1 |    36 |     3   (0)| 00:00:01 |       |       |
|*  4 |    TABLE ACCESS  BY INDEX ROWID       | SUBSCRIBER            |     1 |    11 |     1   (0)|  00:00:01 |       |       |
|*  5 |     INDEX UNIQUE SCAN                |  SUBSCRIBER_PK         |     1 |       |     1   (0)| 00:00:01 |       |        |
|   6 |    PARTITION RANGE ALL               |                       |      1 |    25 |     2   (0)| 00:00:01 |     1 |    11 |
|*  7 |     TABLE ACCESS  BY LOCAL INDEX ROWID| AGREEMENT_RESOURCE    |     1 |    25 |     2   (0)|  00:00:01 |     1 |    11 |
|*  8 |      INDEX RANGE SCAN                |  AGREEMENT_RESOURCE_PK |     4 |       |     2   (0)| 00:00:01 |     1 |    11  |
------------------------------------------------------------------------------------------------------------------------------
Predicate  Information (identified by operation  id):
---------------------------------------------------
   1 - filter(  EXISTS (SELECT 0 FROM "PRDAPPO"."SUBSCRIBER"  "SUBSCRIBER","PRDAPPO"."AGREEMENT_RESOURCE"
               "AGREEMENT_RESOURCE" WHERE "AGREEMENT_NO"=:B1 AND "RESOURCE_VALUE"='0910600138'  AND
              "PRIM_RESOURCE_TP"="RESOURCE_TYPE" AND  "SUBSCRIBER"."SUBSCRIBER_NO"=:B2 AND "SUB_STATUS"='A'))
   2 -  filter("SOC_STATUS"='A')
   4 - filter("SUB_STATUS"='A')
   5 -  access("SUBSCRIBER"."SUBSCRIBER_NO"=:B1)
   7 -  filter("RESOURCE_VALUE"='0910600138' AND  "PRIM_RESOURCE_TP"="RESOURCE_TYPE")
   8 -  access("AGREEMENT_NO"=:B1)

發現了全表掃描，而且資源消耗很高。時間消耗已經得到了理論的最高值。 可見，在某些場景中，exists和in還是有所不同，在優化器分析的過程中還是對一些細節做了區別處理。稍後來解釋。 -->改動第二步，去除in,exists 我們嘗試去除語句中的in部分。直接把相關的表放在from之後。查詢條件也等價保持不變。這種方法看似沒有經過任何的調優，但是從查詢轉換的角度來說，可能oracle更能夠合理的做出分析。

select   ser.soc
  from subscriber sub,agreement_resource agr,SERVICE_DETAILS  ser
where  sub.sub_status = 'A' and sub.subscriber_no=agr.agreement_no and  sub.prim_resource_tp= agr.resource_type  and resource_value='0910600138'
and   ser.agreement_no =sub.subscriber_no
   and ser.soc_status = 'A'

執行計劃如下。

Plan hash value:  3783316108
--------------------------------------------------------------------------------------------------------------------------------
|  Id  | Operation                             | Name                   | Rows  |  Bytes | Cost (%CPU)| Time     | Pstart| Pstop  |
--------------------------------------------------------------------------------------------------------------------------------
|    0 | SELECT STATEMENT                      |                        |     8 |    408 |     6   (0)| 00:00:01 |       |       |
|   1 |  NESTED LOOPS                          |                        |       |       |            |          |        |       |
|   2 |   NESTED LOOPS                        |                         |     8 |   408 |     6   (0)| 00:00:01 |       |       |
|   3 |     NESTED LOOPS                       |                        |     1 |    36 |      5   (0)| 00:00:01 |       |       |
|   4 |     PARTITION RANGE ALL                |                        |     1 |    25 |     4   (0)| 00:00:01 |     1 |     11 |
|   5 |      TABLE ACCESS BY LOCAL INDEX ROWID| AGREEMENT_RESOURCE      |     1 |    25 |     4   (0)| 00:00:01 |     1 |    11 |
|*  6 |        INDEX RANGE SCAN                | AGREEMENT_RESOURCE_1IX |     1 |       |     3    (0)| 00:00:01 |     1 |    11 |
|*  7 |     TABLE ACCESS BY INDEX ROWID        | SUBSCRIBER             |     1 |    11 |     1   (0)| 00:00:01 |       |        |
|*  8 |      INDEX UNIQUE SCAN                | SUBSCRIBER_PK          |      1 |       |     1   (0)| 00:00:01 |       |       |
|*  9 |    INDEX  RANGE SCAN                   | SERVICE_DETAILS_PK     |     9 |       |     1    (0)| 00:00:01 |       |       |
|* 10 |   TABLE ACCESS BY INDEX ROWID          | SERVICE_DETAILS        |     7 |   105 |     1   (0)| 00:00:01 |       |        |
--------------------------------------------------------------------------------------------------------------------------------
Predicate  Information (identified by operation  id):
---------------------------------------------------
   6 -  access("RESOURCE_VALUE"='0910600138')
   7 - filter("SUB"."SUB_STATUS"='A'  AND "SUB"."PRIM_RESOURCE_TP"="AGR"."RESOURCE_TYPE")
   8 -  access("SUB"."SUBSCRIBER_NO"="AGR"."AGREEMENT_NO")
   9 -  access("SER"."AGREEMENT_NO"="SUB"."SUBSCRIBER_NO")
  10 -  filter("SER"."SOC_STATUS"='A')

-->改動第三步，從檢視合併的角度調整 從檢視合併的角度來看，可以使用下面的方式進行調整，定義一個子查詢，然後再和service_details關聯。

select   ser.soc
  from 
(select  subscriber_no
                           from subscriber
                          where sub_status = 'A'
                           and (subscriber_no,  prim_resource_tp) in (select agreement_no, resource_type from agreement_resource  where resource_value='0910600138')) temp,
SERVICE_DETAILS ser
where  agreement_no =temp.subscriber_no
   and soc_status =  'A'

執行計劃如下：

Plan hash value:  3927794511
---------------------------------------------------------------------------------------------------------------------------------
|  Id  | Operation                              | Name                   | Rows  |  Bytes | Cost (%CPU)| Time     | Pstart| Pstop  |
---------------------------------------------------------------------------------------------------------------------------------
|    0 | SELECT STATEMENT                       |                        |     8 |    408 |     7  (15)| 00:00:01 |       |       |
|   1 |  NESTED LOOPS                           |                        |       |       |            |           |       |       |
|   2 |   NESTED LOOPS                         |                         |     8 |   408 |     7  (15)| 00:00:01 |       |       |
|   3  |    NESTED LOOPS                        |                        |     1 |     36 |     6  (17)| 00:00:01 |       |       |
|   4 |     SORT UNIQUE                         |                        |     1 |    25 |     4   (0)| 00:00:01  |       |       |
|   5 |      PARTITION RANGE ALL               |                         |     1 |    25 |     4   (0)| 00:00:01 |     1 |    11 |
|   6  |       TABLE ACCESS BY LOCAL INDEX ROWID| AGREEMENT_RESOURCE     |     1 |     25 |     4   (0)| 00:00:01 |     1 |    11 |
|*  7 |        INDEX RANGE SCAN                 | AGREEMENT_RESOURCE_1IX |     1 |       |     3   (0)| 00:00:01  |     1 |    11 |
|*  8 |     TABLE ACCESS BY INDEX ROWID        | SUBSCRIBER              |     1 |    11 |     1   (0)| 00:00:01 |       |       |
|*  9 |       INDEX UNIQUE SCAN                 | SUBSCRIBER_PK          |     1 |        |     1   (0)| 00:00:01 |       |       |
|* 10 |    INDEX RANGE SCAN                     | SERVICE_DETAILS_PK     |     9 |       |     1   (0)| 00:00:01 |        |       |
|* 11 |   TABLE ACCESS BY INDEX ROWID          |  SERVICE_DETAILS        |     7 |   105 |     1   (0)| 00:00:01 |       |        |
---------------------------------------------------------------------------------------------------------------------------------
Predicate  Information (identified by operation  id):
---------------------------------------------------
   7 -  access("RESOURCE_VALUE"='0910600138')
   8 - filter("SUB_STATUS"='A' AND  "PRIM_RESOURCE_TP"="RESOURCE_TYPE")
   9 -  access("SUBSCRIBER_NO"="AGREEMENT_NO")
  10 -  access("AGREEMENT_NO"="SUBSCRIBER_NO")
  11 -  filter("SOC_STATUS"='A')

-->改動第4步，從子查詢解巢狀的角度調整 回到exists的那個問題，執行的時候，exists的效能要比in差很遠(在這個例子中,需要視業務場景而定) 我們看看怎麼調整讓它也快起來。我們加入hint，使得子查詢解巢狀被禁用。優先從子查詢中先輸出資料。

select  soc
  from SERVICE_DETAILS ser
where exists  (select /*+ UNNEST */ subscriber_no
                           from subscriber
                         where  ser.agreement_no=subscriber.subscriber_no
          and sub_status = 'A'
                            and (subscriber_no, prim_resource_tp) in (select  agreement_no, resource_type from agreement_resource where  resource_value='0910600138')
                           )
   and  soc_status = 'A'

執行計劃如下。可以看到又得到了我們預期的效果。

Plan hash value:  2142047497
-----------------------------------------------------------------------------------------------------------------------------------
|  Id  | Operation                                | Name                   | Rows   | Bytes | Cost (%CPU)| Time     | Pstart| Pstop  |
-----------------------------------------------------------------------------------------------------------------------------------
|    0 | SELECT STATEMENT                         |                        |     7  |   196 |     7  (15)| 00:00:01 |       |       |
|   1 |  NESTED LOOPS                             |                        |       |       |            |           |       |       |
|   2 |   NESTED LOOPS                           |                         |     7 |   196 |     7  (15)| 00:00:01 |       |        |
|   3 |    VIEW                                  | VW_SQ_1                |      1 |    13 |     5   (0)| 00:00:01 |       |       |
|   4 |     HASH  UNIQUE                          |                        |     1 |    36 |             |          |       |       |
|   5 |      NESTED LOOPS                         |                        |       |       |            |          |       |        |
|   6 |       NESTED LOOPS                       |                         |     1 |    36 |     5   (0)| 00:00:01 |       |       |
|   7 |         PARTITION RANGE ALL               |                        |     1 |    25 |      4   (0)| 00:00:01 |     1 |    11 |
|   8 |         TABLE ACCESS BY LOCAL  INDEX ROWID| AGREEMENT_RESOURCE     |     1 |    25 |     4   (0)| 00:00:01 |      1 |    11 |
|*  9 |          INDEX RANGE SCAN                |  AGREEMENT_RESOURCE_1IX |     1 |       |     3   (0)| 00:00:01 |     1 |    11  |
|* 10 |        INDEX UNIQUE SCAN                 | SUBSCRIBER_PK          |      1 |       |     1   (0)| 00:00:01 |       |       |
|* 11 |       TABLE  ACCESS BY INDEX ROWID        | SUBSCRIBER             |     1 |    11 |     1    (0)| 00:00:01 |       |       |
|* 12 |    INDEX RANGE SCAN                       | SERVICE_DETAILS_PK     |     9 |       |     1   (0)| 00:00:01 |       |        |
|* 13 |   TABLE ACCESS BY INDEX ROWID            | SERVICE_DETAILS         |     7 |   105 |     1   (0)| 00:00:01 |       |        |
-----------------------------------------------------------------------------------------------------------------------------------
Predicate  Information (identified by operation  id):
---------------------------------------------------
   9 -  access("RESOURCE_VALUE"='0910600138')
  10 -  access("SUBSCRIBER_NO"="AGREEMENT_NO")
  11 - filter("SUB_STATUS"='A' AND  "PRIM_RESOURCE_TP"="RESOURCE_TYPE")
  12 -  access("SER"."AGREEMENT_NO"="ITEM_0")
  13 - filter("SOC_STATUS"='A')

相關推薦

關於查詢轉換的一些簡單分析(二) (r3筆記第68天)

關於查詢轉換的作用，在之前的一篇博文裡面也大概說了檢視合併和子查詢巢狀的部分。http://blog.itpub.net/23718752/viewspace-1310272/ 今天來舉一個例項來分析一下。

關於查詢轉換的一些簡單分析(三) (r3筆記第69天)

關於查詢轉換,已經討論了檢視合併和子查詢解巢狀，還有謂詞推進和物化檢視查詢重寫也是查詢轉換中不可或缺的部分。

shell基礎學習總結(二) (r3筆記第72天)

-->關於shell程式設計之檔案比較 可以使用如下的選項來做檔案的比較。有了這些選項，檔案的比較來說都是遊刃有餘。

關於奇怪的並行程序分析(二) (r6筆記第46天)

前幾天的並行問題自己分析了下，也算有了一些進展，但是目前還沒有找到讓人信服的理由，有些讀者也比較關心這個問題，所以第二篇中會把自己的分析過程寫出來，第三篇中應該會對這個問題做一個了結。

從Java的型別轉換看MySQL和Oracle中的隱式轉換(二)(r6筆記第68天)

說起資料型別轉換，在開發中如此，在資料庫中也是如此，之前簡單對比過MySQL和Oracle的資料型別轉換情況，可以參見MySQL和Oracle中的隱式轉換 http://blog.itpub.net/23718752/viewspace-1787973/

system表空間不足的問題分析(二) (r8筆記第5天)

今天收到一條不太起眼的報警郵件，大體內容是某個表空間的空間有些緊張了。大體內容如下：

增量資料丟失的原因分析(二)(r8筆記第76天)

今天處理的一個問題比較繞，花費了我不少的時間來分析，當然最後發現是拜拜忙碌一場空,還是有一些歷史原因。

Oracle中的PGA監控報警分析二(r12筆記第87天)

今天又收到了一條報警的資訊，看起來很常規，但是後面的故事如果你做了分析就會發現其實本身並不平常，我覺得我得出手了。之前的分析可以參考 Oracle中的PGA監控報警分析(r11筆記第96天)

檢視並行程序的一些簡單資訊(r3筆記第17天)

在使用並行的時候，總能看到程序中出現一些ora_p這樣的程序。有時候檢視問題的時候只看到並行程序在執行，卻沒有思路去查詢倒底是哪些session在幹些什麼，下面簡單分析一下。怎麼去對映系統級的程序和資料庫級的並行

關於分頁查詢的優化思路(r3筆記第7天)

目前在生產環境中有一個sql語句執行時間長達7分鐘，而且執行頻率極高。 其中PROC_INST中有將近6千萬的資料。其中STEP_INST是一個物化檢視，裡面還有5千多條資料。

關於session leak的問題分析(r3筆記第13天)

在生產環境中，作為dba需要對系統的負載有一個很清晰的認識。能夠在很快的時間內能夠發現系統潛在的問題，並且及時定位問題，高效的響應和處理問題。

使用strace分析exp的奇怪問題(r3筆記第41天)

exp算是一個經典的資料匯出工具了。對於小數量的表來說，個人還是比較鍾愛exp。畢竟expdp還需要配置directory而且還在服務端。exp在資料量小的情況下速度還是很理想的。

由一條日誌警告所做的調優分析(r3筆記第40天)

這個案例發生有段時間了，但是今天無意中看到當時的郵件，感覺還是收益匪淺，看來還是細節決定成敗啊。從一些日誌或trace 檔案中的警告資訊中我們可以發掘出潛在的問題。

外部表簡單總結(r3筆記第51天)

對於外部表的使用而言，可能是既陌生又熟悉的感覺，說陌生可能自己真正的使用機會要少一些，而熟悉可能是大家比較常用的通過外部表來檢視資料庫日誌,其實外部表還有更豐富的內容。

跨網路拷貝檔案的簡單實踐(r3筆記第67天)

在實際的專案中可能要訪問生產環境是需要各種安全驗證和設定的，畢竟客戶的資料是最寶貴的資源。一般來說，客戶會把一部分訪問的許可權開放出來。這樣在系統出現問題的時候，能夠更快更高效的處理問題。

關於enq: TX - allocate ITL entry的問題分析(r3筆記第66天）

今天發現系統在下午1點左右的時候負載比較高,就抓取了一個最新的awr報告. Snap Id

shell的圖形化實現簡單示例(r3筆記第70天)

shell指令碼一直以來就給人呆板枯燥的感覺。如果來點圖形的感覺可能大家對shell的感覺就會多加分。其實在linux中已經有人做了不少的工作，目前使用比較多的是dialog，還有很多衍生的版本，比如kdialog,gdialog,zenit

簡單實用的sql小技巧(第二篇)(r3筆記第86天)

ASCII和CHR 在平時的工作中，可能會在sql或者pl/sql塊中嵌入特殊字元，比如空格，回車之類。這個時候可以使用ascii和chr來做字元和ascii碼的轉換。

關於long型別的轉換(r3筆記第84天)

在oracle中對於long型別的處理時很糾結的。最開始引入這個資料型別的時候是對原有資料型別的補充，但是後面發現還是碰到了一些問題，使用Lob型別代替了。但是long型別從相容性上來說還得支援，而且從資料庫的資料字典

關於檢視檔案的幾個小命令(r3筆記第6天)

關於檢視檔案磁碟空間的情況，有時候df -k, df -h的時候老是顯示錯行。 一般的顯示效果如下,這樣看起來不是很清楚。