前一段，我們內部系統的一個重要WEB頁面報表出現一個怪現象，報表數據不穩定，隨時變化，可檢查原始數據並沒有問題，奇怪，這個報表已經使用三年了怎麼纔出現這個問題，而且開發報表的人已經不在搞技術了。只好硬者頭皮看遠程序了，發現這是一個非常複雜的報表，SQL語句也比較複雜，用到多個union語句，爲了能提高顯示速度，使用的一箇中間過渡表，把中間的運算結果放到過渡表中，問題就出現在這個過渡表上，這個表是按照普通表創建的，但起的作用就是存放臨時數據，每次執行報表時都是先刪除數據，在插入數據，然後在篩選比較後在頁面顯示出，這似乎也沒有什麼錯，而且以前一直用的很好，測試也沒問題，爲什麼現在會出現上面的問題呢，研究一段後忽然頓悟到程序實現時沒有考慮到多用戶使用的情況，恰好以前只是一個部門的一個人用這張報表，現在有多個人在用這個報表，問題的確是這樣。找到問題根源只是第一步，如何解決呢，大部人自然會想到採用數據庫鎖，使用數據庫事務隔離級別等技術，由於不太精通JDBC這方面的接口實現，還好互聯網裏蘊藏着無法估量的技術寶藏，有時真感到求人不如求互聯網，當然最高境界是求自己。在網上搜索時無意中發現一篇 關於oracle數據庫臨時表的使用，大受啓發，臨時表就是解決這個問題的救星，臨時表保證每個連接的數據是安全的，獨佔的，互不影響。開始還只是覺得可行但不敢確信一定能解決問題，使用上臨時表後，不僅解決問題還大大提高速度，真是一箭雙鵰，感慨臨時表實現方式的優雅。
解決了這個問題後，我有很多的深思。首先是感謝互聯網，感謝oracle，更要感謝分享知識的人，我寫這篇文章也是希望能幫助遇到此類問題的人提供一個解決思路。另外有感觸程序設計或者說系統設計人員需要更廣博的知識，要把握知識的關鍵點，我以前用過很多次臨時表，但都沒有去關注臨時表的核心價值，需要深刻反省自己。最後就是分析問題的方法，一定要先抓住問題出現的環境，才有利於解決問題。