※ 引述《jl844032 (湖藍者)》之銘言： : 如題 : 想請問版上大德們 : 一個PHP想要從MYSQL拉資料後 再用PHP做運算比較好 : 還是在MYSQL做完運算後 傳回來PHP比較好 這個問題是個大哉問啊... : 關於效能方面 哪個方式會比較好? 我有兩組答案，一組是業界的，一組是學界的... 不管是哪一種，談「效率」的時候前提都是假設在「資料量夠大」，所以下面就 不再提醒資料量的問題了，都是以資料量夠大為前提... ======================================================================= 學界的比較簡單，用 MySQL 算「整體」上會比較省資源，而且考慮到傳輸數據也 是成本，用 MySQL 算比較省資源通常都是對的。 反例是 MySQL 內建的函式沒辦法快速處理時，拉到 PHP 端計算可能會比較快。 ======================================================================= 業界的答案就很複雜了，要列出不同的情境... 對於只用過 MySQL MyISAM 的人，答案 100% 是 PHP 比較好，因為 query 如果 跑很久的話，會導致 table 卡住無法寫入... ======================================================================= 接下來是會用 InnoDB 的人，又要再分成公司的狀態... 如果公司 Programmer 比較強勢，那麼 Programmer 會希望事情不要在 PHP 端計 算，會壓榨管資料庫的人要把資料庫弄強... 會出現的用語：「這個是資料庫不夠力的問題」。 如果是管資料庫的人比較強勢，那麼會壓榨 Programmer 把計算丟到 PHP 端。 會出現的用語：「這個不應該歸資料庫計算」。 ======================================================================= 最後是講比較美好的情況：這個問題是依照商業邏輯而決定怎麼做比較好。 我們知道在資料庫端算完再丟出來對整體的資源是最省的，但我們也知道資料庫 是最難以擴充的部份 (相較於 PHP 端)。 在知道這個前提下，針對不同的商業需求來決定要怎麼處理。 不過這有個大前提，現在幾乎都應該用 InnoDB 了啦，不用 InnoDB 受限太多... 對於 Web 應用來說，為了要壓力頁面產生時間，有很多東西會在 MySQL 上反正 規化，然後用 trigger 更新；或是反正規化後用 transaction 確保資料的一致 性。 而對於報表來說，反正每天用離峰時間慢慢跑就好：第一是因為離峰時間，本來 就有多出來的計算資源可以用，第二是報表類的東西不需要即時計算，慢慢跑完 就好，去正規化之類的事情能省就省... ======================================================================= 這是我的想法啦，不能接受的人還蠻多的 XDDD --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 210.242.135.97