這篇文章的目的是為了給IBM(r)商業(yè)伙伴提供一些重要的信息，這些信息是關于DB2通用數(shù)據(jù)庫（UDB）在z/OS(r) 環(huán)境下（以下簡稱DB2）DB2(r)數(shù)據(jù)庫性能方面的。本文試圖將來自多方資源的材料進行整合，然后盡量有效地將信息展示出來。本文盡量避免在范圍上過于寬泛，以及過于深入細節(jié)。下面，我將要討論那些最頻繁影響DB2數(shù)據(jù)庫性能的因素。我在這里并不涉及所有可能的條件和所有潛在的考慮，而是只局限于預期的范圍之內(nèi)。我希望這篇文章能夠?qū)B2客戶有一個總體的指導，從而使它們自己的環(huán)境中去獲得DB2數(shù)據(jù)庫的最適宜的性能。這篇文章將從如何在一個特定的安裝中定制數(shù)據(jù)庫的性能開始談起。 這篇文章所涉及的范圍是數(shù)據(jù)庫設計性能。而DB2的性能包括的內(nèi)容比這要多得多，除了數(shù)據(jù)庫的設計之外，實際上還有很多其他的影響因素。例如，程序的編碼邏輯，實際使用的SQL語句，都被劃分在應用程序設計范圍內(nèi)了。影響DB2系統(tǒng)性能的因素包括了例如安裝選項、緩沖池規(guī)模、DB2相關的地址空間的分配優(yōu)先級等。本文的重點在于DB2數(shù)據(jù)庫的設計。但是有些時候，這些影響性能的因素分類之間的界限有些模糊。例如，安裝過程中對緩沖池的規(guī)模，選用緩沖池的數(shù)量進行的配置一般都被認為是系統(tǒng)性能因素。但是，當分配特定的表空間和那些緩沖池的索引的時候，就被認為是數(shù)據(jù)庫設計所要考慮的了。 假設讀者已經(jīng)對z/OS環(huán)境下的DB2有了一些基本的了解。本文的前幾頁討論了一些關于性能治理的基本概念和原則，以便于后面的理解。我的建議在本質(zhì)上有些籠統(tǒng)，我總是避免過于糾纏技術細節(jié)或者語法等方面的問題。想要獲得關于這些問題的具體信息，你可以查看IBM最近發(fā)布的有關安裝在客戶端的DB2的文檔。 這篇文檔主要著眼于z/OS V7環(huán)境下的DB2。雖然在z/OS V8下的DB2已經(jīng)發(fā)布了，并且具有通用性，但是很可能還需要幾個月的時間，IBM 的大多數(shù)客戶才能夠讓他們的產(chǎn)品系統(tǒng)實現(xiàn)DB2 V8 NFM（新功能模式）。這里還有另一個需要考慮的問題：雖然每個新發(fā)布的DB2在正式通用之前，都會在IBM和客戶環(huán)境中進行相當充分的測試，但是客戶仍然很可能對基于前一版本的有關DB2的常見推薦和單憑經(jīng)驗的方法懷有更多的信心，而不是非常認同還沒有發(fā)布，或者是沒有獲得普遍使用的新版本（由于驗證結(jié)論的實際過程的時間長度和深度）。我會在文中提到一些可能會影響數(shù)據(jù)庫設計性能的DB2 V8的新特性。 12345678910下一頁 免責聲明：本文包含的信息并沒有提交給任何正式的IBM測試，并按"AS IS"原則提供。本信息的使用，或者是以上提到的任何技術的實現(xiàn)均由用戶負責，且依靠用戶的個人能力對其進行評估，并將其整合進入客戶特定的操作環(huán)境中。其中的每一項都將在IBM特定的條件下獲得精確的數(shù)值，這里不保證在其他地方會出現(xiàn)同樣或者相似的結(jié)果。當用戶嘗試在各自的環(huán)境下采用上述技術時，需要自己承擔風險。 性能原則和方法學 考慮性能的時機 考慮應用程序和數(shù)據(jù)庫各自不同的性能特征的時間，是在對這些應用程序和數(shù)據(jù)庫進行設計的初始階段，即開發(fā)過程的一開始。對你的DB2應用程序和數(shù)據(jù)庫所需要的資源進行合理評估，將會幫助用戶在開發(fā)過程的早期對設計和實現(xiàn)做出適當?shù)臎Q定。假如你的應用程序訪問數(shù)據(jù)庫的性能直到后來才被說明，那么就要做必需的修改以獲得足夠的響應時間，并處理你的批處理窗口；這將會變得更加困難，并且消耗時間。 關注焦點 當設計性能的時候，將大部分的精力集中在重要的DB2數(shù)據(jù)和程序上是很明智的做法。對應用程序或者事務進行定義是這部分工作中的重點，以下一個或者多個特點是適用的： 它們表現(xiàn)了所有業(yè)務工作量中的大部分 它們有一個很要害的響應時間需求 它們包括了復雜的邏輯和/或數(shù)據(jù)訪問需求 它們訪問大量的數(shù)據(jù) 它們消耗大量的資源 它們直接與客戶進行交互（通過網(wǎng)絡、ATM等），與此相反，應用程序大多面向公司內(nèi)部 數(shù)據(jù)庫設計 數(shù)據(jù)庫設計發(fā)生在以下兩個階段： 數(shù)據(jù)庫邏輯設計 數(shù)據(jù)庫物理設計 數(shù)據(jù)庫的邏輯模型只是所有用戶數(shù)據(jù)需求規(guī)格化的形式表現(xiàn)。這個模型通常是數(shù)據(jù)建模階段的輸出或者是最終結(jié)果。它很少在實際意義上被實現(xiàn)。更何況，在考慮如何在數(shù)據(jù)庫治理系統(tǒng)中實際地組織和存儲數(shù)據(jù)之前，它只是數(shù)據(jù)的一個理想化的視圖。 上一頁1234567下一頁 當考慮到特定數(shù)據(jù)庫對象的體系結(jié)構的時候，邏輯模型才會轉(zhuǎn)化為物理模型。在這一設計階段，才需要考慮到數(shù)據(jù)訪問需求和性能因素的一些細節(jié)。在進行物理設計的過程中，兩個要害的因素是表設計和索引設計。這兩個問題將會在下面進行具體討論。 DB2性能治理的方式 為了確保你的DB2應用程序有足夠的性能，采取積極的態(tài)度總比消極應對有意義得多。在DB2數(shù)據(jù)庫設計的早期階段總結(jié)出性能因素是至關重要的。然后在項目中，努力盡早地確定滿足你的服務級別協(xié)議（SLA）的性能“基線的測量標準，這樣你就可以在首次演示和應用程序變更的時候追蹤性能特點及其發(fā)展趨勢。不斷地監(jiān)測你的DB2系統(tǒng)和應用程序，以便在大多數(shù)的問題成形之前預見到它們。 傳統(tǒng)意義上，許多客戶都是直到應用程序開發(fā)項目的最后階段才開始關心性能問題。但是這樣的等待是毫無益處的。早在描述用戶界面和處理邏輯的階段就去思考數(shù)據(jù)庫設計的性能特點，是比較有好處的。例如，在你的重要的DB2工作（見前面所述）中，創(chuàng)建最好的索引的一個基本的指導就是對SQL語句中的謂詞的考慮。 即使是你開發(fā)出的最初設計是一個有效的設計，但是以下的若干修改仍然是必要的，例如對你的應用程序進行修改，或者數(shù)據(jù)庫以卷的形式增長，或者是限制系統(tǒng)資源。假如現(xiàn)有的應用程序沒有充分的運行，那么通常情況下你都會希望最好能夠在現(xiàn)有的索引上面添加更多的列，或者在表上添加新的索引。不論改變表的設計，或者修改客戶的需求，還是使表非標準化，通常情況下都不是好的選擇。理解DB2性能 單憑經(jīng)驗的方法 單憑經(jīng)驗的方法（又叫做ROT）在進行計劃、監(jiān)測，以及對DB2的性能進行優(yōu)化時是很有用處的。ROT典型地基于以前的經(jīng)驗（例如，長時間的觀測平均水平），或者是基于對比較復雜的公式進行簡化。 上一頁12345678下一頁 記住下面這一點是很重要的，ROT對于粗略的估計有用，但是進行具體分析的時候就不行了。只是因為這些經(jīng)驗出現(xiàn)在某些文章中，就把它們作為性能的精確引證是很危險的。最好的情況下，它們是估計值；在最壞的情況下，它們對于你特定的DB2環(huán)境來說就是無效的。 ROT應該在你的環(huán)境中得到（或者是對其進行調(diào)整，使其適應你的環(huán)境）。它們應該與你的實際經(jīng)驗相聯(lián)系，而不是被盲目接受，這樣你才會對它們的值有信心。從那些在你的非凡環(huán)境之外得到的ROT開始也許會有些幫助。但是當你從你的DB2系統(tǒng)中收集、分析、記錄了合適的數(shù)據(jù)之后，就需要對這些經(jīng)驗值進行校正或者修改。IBM的紅皮書是一本有關ROT的值得閱讀的資源，里面含有許多關于性能監(jiān)測工具的推薦經(jīng)驗。 另一個要考慮的事項就是ROT需要持續(xù)一段時間。隨著硬件技術的發(fā)展，軟件編碼的改進，系統(tǒng)的體系結(jié)構發(fā)生了變化，這使得ROT更加不可靠，甚至是完全錯誤的。隨著時間的發(fā)展，使ROT發(fā)生改變的最大因素恐怕就是最新發(fā)布的DB2自身了。 DB2工作量 磁盤I/O通常是影響響應時間的最大因素，但是，通過查看GETPAGE (GP)需求可以更輕易地看到潛在的性能問題。當監(jiān)測DB2的活動并進行報告分析的時候，GETPAGE的數(shù)量很可能就是顯示DB2整體工作情況的最好的指示器。 大部分的DB2安裝工作可以分為以下幾個較清楚的類別： 事務：這是運行在事務治理器控制之下的程序，例如CICS 和 IMS/TM。SQL通常比較簡單，但是事務卷是很繁重的。事務必須為用戶提供非常及時的響應時間，這樣應用程序才不會被迫等待很長的時間以獲得所需的資源。通常是第一個用戶調(diào)用事務時才會產(chǎn)生讀取索引和數(shù)據(jù)頁的I/O開銷。隨后的用戶可以在緩沖池中訪問部分資源。 上一頁123456789下一頁 查詢：這是通常情況下為決策支持運行的程序。其中的SQL也許十分復雜，但是卷通常要比事務的卷輕松許多。查詢用戶通常需要等待幾分鐘，甚至是幾個小時，具體時間依靠于產(chǎn)生用戶需要的結(jié)果集所查詢的數(shù)據(jù)量。查詢通常會調(diào)用針對整個表的掃描，并且對結(jié)果排序也是此類工作量的另一個常見特點。 批處理和實用工具集：批處理和實用工具集程序需要處理大量的數(shù)據(jù)，并且通常是以順序的方式處理數(shù)據(jù)。在特定的窗口中結(jié)束處理對于這些程序來說是很重要的。多次使用位置正確的COMMIT（提交）語句是這些應用程序具有的一個很重要的特點。批處理和實用工具集通常需要消耗大量的各類資源，進行壓縮的時候，通常可以逐步提高工作量。 標準化 標準化是應用程序進行數(shù)據(jù)實體分析的標準化過程，最終將把數(shù)據(jù)實體轉(zhuǎn)換為一系列經(jīng)過良好設計的結(jié)構體。通常，邏輯數(shù)據(jù)模型的設計目標是正確性、一致性、沒有冗余和簡單化。而且，關系理論原則也需要數(shù)據(jù)庫進行標準化。 還有幾條連續(xù)編號的規(guī)則，被稱為范式，它可以相當具體地定義標準化數(shù)據(jù)。我在這里并不具體討論這些規(guī)則。大多數(shù)的專家都會建議設計者們盡力遵循前三條的規(guī)則，因此這樣的數(shù)據(jù)可被稱為遵循第三范式。 對表進行非標準化的意思是，對一個先前遵守范式的表進行修改，使其違反一條或者多條范式規(guī)則。有時候，由于性能的原因，確實需要進行這個非標準化的過程。有關標準化的更進一步的具體信息，你可以在大多數(shù)的講述關系數(shù)據(jù)庫的書籍中找到。 DB2表空間的類型 在定義DB2數(shù)據(jù)庫的時候，實際的表必須在被成為表空間的DB2對象中進行創(chuàng)建。用戶可以在DB2中定義四種不同類型的表空間，如下所示： 單一：一個單一的表空間可以包含多于一個的DB2表。這個空間由多個頁組成，每個頁都可以包含若干行，它們可能是來自表空間中定義的任何表的數(shù)據(jù)行。 上一頁12345678910下一頁 分段：分段表空間可以包含多于一個的DB2表。這個表空間由多組頁組成，每組頁被稱為一個段。每個段包含來自表空間中定義的某一個表的若干行。 分區(qū)：分區(qū)表空間只可以包含一個表。這個空間根據(jù)分區(qū)索引的要害值范圍被劃分成多個區(qū)。每個分區(qū)都作為一個獨立的實體對待，答應SQL和DB2實用工具集的并發(fā)處理。 LOB：LOB表空間只存儲LOB（大對象）數(shù)據(jù)。LOB包括了3個數(shù)據(jù)類型：BLOB（二進制大對象）、CLOB（字符型大對象），以及DBCLOB（雙字節(jié)字符型大對象）。表空間和表設計考慮事項 記錄尺寸和頁尺寸 固定長度的記錄比可變長度的記錄要好，因為處理固定長度記錄的DB2的代碼經(jīng)過了優(yōu)化。假如記錄是固定長度的，那么它就永遠不需要從原來存儲的頁中被移動出來。然而，可變長度的記錄可能增長到不再適合原來頁的長度，因此它也就必須被移動到另一頁。無論何時記錄被順序訪問，都一定會出現(xiàn)一個額外的參考頁。DB2 UDB V8中的一個新特性就是當你不確定未來的數(shù)據(jù)長度增長情況時，答應你根據(jù)需要改變列的尺寸，這樣你就可以不再需要創(chuàng)建可變長度的記錄。 每頁中記錄的數(shù)量也是需要考慮的內(nèi)容。DB2提供了一些有關頁尺寸的選項，例如4 KB, 8 KB, 16 KB和32 KB 。比較好的起點是選擇默認的4KB，非凡是當行的尺寸相對較小，或者是對數(shù)據(jù)的訪問比較隨機的情況下。然而，在一些情況下，也需要考慮較大的頁尺寸。假如表中單個行的長度超過4KB，那么你就需要使用大一些的頁尺寸，因為DB2不支持跨行的記錄。 還有另一種情況是，當固定記錄的總長度比二分之一的頁（4KB）稍大一些的時候，一頁中就只能放置一個記錄。另外一種類似的情況是，固定記錄的總長度略長于三分之一頁、四分之一頁，等。這樣的設計不僅會浪費DASD空間，還會導致很多的DB2操作消耗更多的資源。因此，對于上面描述的記錄而言，你需要考慮使用較大的頁尺寸，這樣就會相對地少浪費一些空間。 上一頁234567891011下一頁 另外一些可能的頁尺寸為8 KB, 16 KB和 32 KB。頁的尺寸并不在創(chuàng)建表（CREATE TABLE）的語句中直接寫明。相反，表中頁的尺寸是由分配給包含這個表的表空間的緩沖池中的頁尺寸決定的。要獲得更具體的信息，你可以參考DB2 SQL 手冊中有關創(chuàng)建表空間（CREATE TABLESPACE）語句的內(nèi)容。 非標準化考慮事項 邏輯數(shù)據(jù)模型是數(shù)據(jù)的一個理想描述。物理數(shù)據(jù)模型則是數(shù)據(jù)在現(xiàn)實世界的實現(xiàn)。標準化只集中在數(shù)據(jù)的內(nèi)涵上面，而不考慮可能訪問數(shù)據(jù)的應用程序的性能需求。數(shù)據(jù)庫設計的充分標準化會帶來性能的挑戰(zhàn)。 有關此類性能問題的一個非經(jīng)常見的例子就是連接操作。通常情況下，標準化過程的結(jié)果是給各個獨立的表賦予相互關聯(lián)的信息。應用程序需要從這些表中訪問數(shù)據(jù)。關系數(shù)據(jù)庫提供了使用SQL語句來從多于一個的表中通過連接多個表去訪問信息的能力。取決于表的數(shù)目和它們各自的尺寸，連接操作可能會消耗非常多的資源和時間。 因為在I/T中有如此多的事情需要考慮，于是出現(xiàn)了一個折中的想法。對那些包含被頻繁訪問列的多個表中的數(shù)據(jù)保存副本，與連接表的性能相比，成本高還是低呢？在邏輯數(shù)據(jù)庫設計過程中，對你的數(shù)據(jù)模型盡量的執(zhí)行標準化，之后再對其進行一定程度的非標準化，也許是進行潛在性能優(yōu)化的一個選項。假如你決定進行非標準化了，要確保從頭到尾地記錄了文檔：對某些細節(jié)的描述、執(zhí)行非標準化步驟之后的推理，等。 設計較大的表 訪問很大的DB2表需要消耗相當多的資源：CPU，內(nèi)存，I/O。當設計大表的時候，用戶需要做的兩件最重要的事情就是： 實現(xiàn)分區(qū) 創(chuàng)建有用的索引 以上兩個問題將在下面進行具體討論。 使用分段或者分區(qū)表空間 上一頁3456789101112下一頁 假如數(shù)據(jù)中包含了LOB，那么用戶就必須創(chuàng)建LOB表空間。對于非LOB的數(shù)據(jù)，通常的選擇是分段或者分區(qū)表空間，具體選擇哪一個在很大程序上取決于你要存儲的數(shù)據(jù)量，同時還需要考慮相關應用程序需求的數(shù)據(jù)訪問類型。不太推薦使用單一的表空間。 分段表空間比單一的表空間具有更多的性能優(yōu)勢，如下所示： 對于包含多于一個表的表空間，當DB2在一個表上獲得鎖定時，那個鎖定不影響其他表分段的訪問。 當DB2掃描一個表時，只訪問與那個表相聯(lián)系的分段。此外，空分段的頁不會被取出。 假如一個表被清除了，不需要執(zhí)行REORG實用工具集，它的分段就立即在COMMIT點上變成可再次使用的狀態(tài)。 假如一個表中的所有行被刪除了（被稱為塊刪除），不需要執(zhí)行REORG實用工具集，所有的分段都立即在COMMIT點上變成可再次使用的狀態(tài)。 塊刪除操作起來更加有效，并且書寫相當少的記錄信息。 COPY（復制）實用工具集不復制由于塊刪除或者表清除所造成的空頁。 當表達到一個特定的尺寸，它們的可治理性和性能都可以通過分區(qū)表空間獲得改善。假如你想獲得這方面的進展，在設計和創(chuàng)建時，以分區(qū)的形式定義表空間是一個明智的做法。分區(qū)表空間的一些潛在優(yōu)勢列舉如下： 并行性：你可以利用三種類型的并行性，它們目前正應用于DB2 UDB。DB2 V3引入了查詢并行性（多個I/O路徑）。DB2 V4則實現(xiàn)了CP并行性（多CP之上的多任務）。DB2 UDB V5更是引入了系統(tǒng)查詢并行機制（多個DB2數(shù)據(jù)共享群之上的多任務）。DB2的發(fā)展進化，顯著提高了DB2應用程序處理分區(qū)表空間的并行處理能力。由于CPU時間的增加，這些查詢所消耗的時間也顯著的減少了。 在數(shù)據(jù)的一部分上工作：分區(qū)表空間答應DB2應用程序一次運行數(shù)據(jù)的一個分區(qū)，因而使其能夠同時運行另外分區(qū)上的另外的工作或者應用程序。以同樣的方式，你可以將塊UPDATE（更新）、DELETE（刪除）或INSERT（插入）操作分解為獨立的工作。除增加了可用性之外，這一技術也為完成這類DB2工作減少消耗的時間提供了可能。 上一頁45678910111213下一頁 更快的訪問被頻繁訪問的數(shù)據(jù)：假如分區(qū)索引能夠?qū)⒏嗟念l繁訪問的行從剩余的表中分離出來，然后將那些數(shù)據(jù)置于一個它自己的，并且應用更高速DASD設備的分區(qū)之內(nèi)。 一般而言，表越大，就越應該將其創(chuàng)建為一個分區(qū)的表。但是也有一些實際例子表明為小表創(chuàng)建分區(qū)表空間是有利的。當查找表用于連接其他大分區(qū)表空間時，通過將查找表分區(qū)，你能夠使并行性在連接中最大化。 當你在連接謂詞中利用分區(qū)方法時，需要考慮一個決定性的因素。被連接在分區(qū)方法上的表應該具有相同的分區(qū)數(shù)，并且應該設定為相同的值。 數(shù)據(jù)壓縮 DB2提供了壓縮表空間或分區(qū)內(nèi)數(shù)據(jù)的功能。通過指定CREATE TABLESPACE（創(chuàng)建表空間）語句中的 COMPRESS YES（壓縮許可）選項，之后在表空間上同時執(zhí)行LOAD或REORG實用工具集，即可完成該功能。數(shù)據(jù)的壓縮是通過用更短的串來替換頻繁出現(xiàn)的字符串實現(xiàn)的。系統(tǒng)還創(chuàng)建了一個字典，包含了原始字節(jié)串和它們的替代串之間的映射信息。 一定數(shù)量的CPU資源被用于在執(zhí)行數(shù)據(jù)存儲對其進行壓縮，之后，當外部存儲設備讀取時，數(shù)據(jù)又被解壓縮。然而，數(shù)據(jù)壓縮也能夠提供性能方面的好處，因為更多的數(shù)據(jù)存儲在更小的空間內(nèi)（在DASD上和緩沖池中）；同未經(jīng)壓縮的數(shù)據(jù)相比，這樣可以產(chǎn)生更少的同時讀取、更小的I/O等。 接下來是當試圖決定是否壓縮一個表空間或分區(qū)時，需要考慮的一些事情： 行的長度：行越長（尤其是在接近頁的尺寸時），壓縮的有效性就越低。DB2的行不能夠跨頁，當一頁上有多于一行的情況時，你也許不能獲得足夠的壓縮。 表的尺寸：對于較大的表，壓縮具有較好的效果。對于很小的表，壓縮字典的大小（8KB到64KB）可能會抵消壓縮節(jié)省下的所有空間。 上一頁567891011121314下一頁 數(shù)據(jù)中的模式：對于一個特定的表空間或分區(qū)，數(shù)據(jù)中重復出現(xiàn)的模式的頻率，決定了壓縮的效果。含有大量重復字符串的數(shù)據(jù)能夠獲得顯著的壓縮效果。 壓縮估計：DB2提供了一個單獨的實用工具集，DSN1COMP，它可以用來測定數(shù)據(jù)壓縮將有怎樣的效果。想獲得有關運行該使用工具的額外信息，請參考DB2實用工具集指南和參考手冊。 處理成本：在壓縮和解壓縮DB2數(shù)據(jù)時，會消耗一些CPU資源。假如你用IBM的同步數(shù)據(jù)壓縮硬件特征，所消耗的CPU資源將比利用DB2軟件仿真程序低得多（當DB2啟動時，這決定了硬件壓縮特征是否可用）。 更好的字典：當用LOAD使用工具集來建立壓縮字典時，DB2用戶用最初載入的n行（n取決于你能夠壓縮的數(shù)據(jù)量）來決定字典的內(nèi)容。REORG采用取樣技術來建立字典。它不僅使用最初載入的n行，還在實用工具執(zhí)行UNLOAD（未載入）階段的剩余時間里繼續(xù)對數(shù)據(jù)行采樣。 通常情況下，我們推薦你在自己的特定環(huán)境下，壓縮那些DB2表空間和分區(qū)，這將會使你的環(huán)境受益；因為在更小的空間內(nèi)存儲更多的數(shù)據(jù)的性能優(yōu)勢，幾乎總是在價值上超過壓縮和解壓縮數(shù)據(jù)所消耗的CPU資源。 載入大表 在處理大批量數(shù)據(jù)時，將數(shù)據(jù)初始載入表中可能會對系統(tǒng)性能產(chǎn)生挑戰(zhàn)。為了在載入過程中實現(xiàn)并行性，你可以手動創(chuàng)建多個LOAD作業(yè)，每個分區(qū)建一個；或者作為另一個選擇，你可以在一個LOAD程序中載入多個分區(qū)。每個分區(qū)都延伸至I/O子系統(tǒng)，這種方式可以更輕易地實現(xiàn)最理想的并行性。 為了使性能最優(yōu)化，在LOAD語句中指定SORTKEYS參數(shù)也很重要。這個參數(shù)指示DB2將索引方法傳遞給內(nèi)存中的分類程序，而不是將要害字寫入或者再次讀取DASD上的排序任務文件。SORTKEYS也能夠?qū)崿F(xiàn)載入和分類之間的交迭，因為分類是作為一個獨立的任務運行的。 上一頁6789101112131415下一頁