※ 引述《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