1，SQL自身的優化：調優，並行處理
2，stage的拆分與合並：實踐測試為准
如多個JOIN的stage雙方都為大數量(幾百萬一般大於200w)則考慮合並。如大表但JOIN的數據不大就不用合並。
如一個stage中的兩個表都為大表且關聯很慢時考慮拆分為兩個stage作Join（select后數據不大：小於40w）
3，選用合理的stage: 像sort,之類的盡量少用，在數據庫里完成
4，大數據量(上千萬)上述方法都優化不明顯后 可考慮采用直接INSERT 語句 使用Oracle后台處理，而非DS資源抽取插入。
DataStage Job優化指導原則之一：算法的優化。
任何程序的優化，第一點首先都是算法的優化。當然這一點並不僅僅局限於計算機程序的優化，實際生活中也處處可以體現這一點。條條大路通羅馬，完成任何一件事，也同樣有很多種方法。而方法當然有優有劣，有低效有高效。所以想提高完成任何一件事的效率，首先就是做事方法的優化。體現在計算機程序中，也就是算法的優化。也只有算法的優化，才可能使做事的效率有十倍、百倍，甚至上萬倍的提升。
但是是在實際的Job開發過程中，絕大部分人都會忽略這一點。原因很簡單，絕大部分人都認為Job開發是一種很低級的工作，最常用的Stage可能也就不到10種，熟練使用了這10種Stage不怕Job開發不好。的確，Job實際開發過程中，也許只會用到不超過10種Stage。最重要的無外乎ORACLE Stage、Lookup Stage、Join Stage、Transformer Stage等。但是，如何在適合的場景使用合適的Stage，如何平衡DataStage與數據庫的負載均衡，如何確定與哪些表做關聯，以及與這些表關聯的順序怎樣才是最做優的等等，都是需要考慮的問題。開發一個JOB完成需求的功能並不難，難的是如何以更少的資源消耗，更有效率的完成需求指定的功能。
DataStage Job優化指導原則之二：盡量減少DS需要處理的數據量。
這一點，簡單來說，主要指兩點。一是盡量減少從數據庫抽取至DS臨時緩沖區的數據量（包括數據記錄條數和數據字節數）；二是盡量避免在DS內部處理過程中，產生一些不必要的數據處理。
但是說起來容易，做起來難！隨便打開一個JOB，80%的可能都會存在上述說的一個或兩個問題。
首先對於第一點，經常發現JOB從數據源抽取了幾十萬甚至上百萬的數據至DS，緊跟着跟一個小表（20W以內數據量）做內關聯，關聯之后的數據，可能只有從數據源抽取數據的三分之一甚至十分之一。那為什么不考慮將這兩張表的內關聯使用SQL在數據庫中完成呢？這樣做明顯可以減少從源表抽取數據的數據量，減少了數據抽取至DS的時間，減少了DS服務器臨時緩沖區空間的使用。
其次對於第二點，很典型的一個就是對Remove Duplicate Stage的使用。個人認為，所有凡是使用到這個Stage的Job都應該去認真仔細的檢查一下，到底是不是真的有必要使用該Stage來完成數據的去重。首先該Stage的效率相當低下不說，重復的數據從何而來呢？是從源表抽取的時候，源表有數據重復？還是在Job處理過程中，通過關聯導致數據重復？不管是哪一種重復，都應當從源頭上避免將重復的數據抽取至DS中做處理。
DataStage Job優化指導原則之三：盡量減少使用的Stage數量。
在DS8.5中，Job運行時，會將每一個Stage對應生成一個線程或進程去處理。當大批量高並發的運行Job時，系統需要處理的線程或進程太多。
DataStage Job優化指導原則之四：盡量平衡DS服務器與數據庫服務器的處理負擔。
兩張表或多張表關聯時，是在DS服務器中完成呢，還是在數據庫服務器中完成呢，這就需要根據DS服務器和數據庫服務器的性能進行平衡。另外對於一些太復雜的多表關聯，也可拆分，以便將數據抽取至DS中進行關聯運算。
DataStage Job優化指導原則之五：充分發揮各Stage的長處。
每一種Stage都有其存在的合理性，否則IBM的工程師們何必大費周章的為DS開發如此多的Stage呢？
但是是不是所有的Stage都物盡其用了呢？實際也許未必。例如有多少人使用過Lookup Stage和一張小表做內關聯呢？咦！Lookup Stage還能實現內關聯？對，他真的可以！Lookup Stage能像Join Stage關聯時那樣，當關聯的右表有重復時，關聯出多條數據來呢？Lookup Stage真的可以！
DataStage Job優化指導原則之六：盡量使用更高效的Stage以及盡量減少低效Stage的使用。
當然這一點要看具體實現的功能。比如Lookup Stage和Join Stage應該使用哪個呢？因為Lookup Stage會將右表全部裝入內存，所以在處理效率上要比Join Stage快的多。但是當關聯的右表為大表時，將整張表的數據放入內存可能會占用大量的內存空間，甚至會導致內存不夠用而Job運行失敗。何為大表，何為小表呢，這就是一個經驗值，不是一成不變的。當服務器的內存足夠大時，1000W的數據量放入內存，也只是占據了內存空間的九牛一毛時，1000W的表也是小表。我們項目組使用的臨界值是100W，右表超過100W的，盡量使用Join Stage。
另外像上面提到的Remove Duplicate Stage，就是一個相當低效的Stage，應當減少類似低效Stage的使用。