不知道过了一个月还来不来得及帮上原 po... 若想法是「DB 好肥，不想装」，建议可以研究一下 sqlite 这个「资料库」就只是一个档案而已，不用另外跑一套系统起来 Unix 系（Linux/Mac/BSD...）的作业系统装 PHP 通常预设包含 sqlite 用 Windows 可能要研究一下，像 xampp 就要另外处理 （ https://stackoverflow.com/questions/61086512 ） 程式范例 // database.sq3 是你的 DB 档案，不存在的话会自动被建立 // 另，这年头建议尽量用 PDO，必要的时候才用 mysqli 之类针对特定 DB 设计的介面 $pdo = new PDO("sqlite:/path/to/database.sq3"); // 跑两句 SQL，一句开 table，一句写资料进 table // 因为是范例所以简单写，线上程式务必用 prepared statement，不然会碰到 https://xkcd.tw/327 $pdo->exec("CREATE TABLE test_table (id INTEGER PRIMARY KEY AUTOINCREMENT, value TEXT)"); $pdo->exec("INSERT INTO test_table (name) VALUES ('The string')"); 速度跟直接读写档案差不多，但是能变的花样多很多，资料被写坏掉的机会低很多 : 比起档案存取，感觉用像是mysqli之类的函数频繁地存取这些小而简易的状态值有如「用大炮打小鸟」 : 似乎没什麽必要，而且感觉效能也不会有所变好（甚至可能变得更差也说不定… ） 效能不是感觉出来的，是测出来的... 可以参考别人的 benchmark 当成想像的起点 不过大家用要面对的问题或机器大小（a.k.a 口袋深度）都不一样 可以试看看自己写效能测试，然後思考效能测试跟现实环境可能有哪些差距，然後再来评估 例如说这里简单写了一个 sqlite 跟直接写档案的比较 https://gist.github.com/CQD/745793eea05e86925a646184ac6f70db 但这个比较也不一定会符合你的程式的实际效能 例如说，修改上面的测试，不在回圈里面 new PDO 而是重复使用 $pdo 的话，写入/读取的速度会变成十倍快 然後我的电脑跟你的机器测出来的速度也很可能不一样 什麽是大炮什麽是小鸟要看你实际系统规格，以及需要面对的流量压力，以及你想花多少钱 即时读写档案没碰到问题的话，表示你要处理的流量压力就不大，适合走的路跟大流量就会不一样 : 所以各位对於「存取这种小量简单但可能会有多人同时存取相同即时状态值应该用什麽方式存取」有什麽看法？ : 除了用File、Database外，还有其他更好的存取方式吗? 「很多人同时读写」会让「资料一致」很难做，处理这件事情的基础就是上 OS 的时候会讲到的 locking https://ntust-csie-islab.github.io/106-OS-homework1/B10415021/ 自己读写档案就是自己要面对这种问题 如果读写量很少，或是存取速度超级快，出事的机会很低 如果存取量很大，或硬碟有点不太行却又没死透，这题就会变成写很难写的 OS 作业（写对还没分数） 而且最讨厌的不是那种每次都坏掉的，而是那种在线上戳很多次才会坏掉一次的，自己手戳很难重现 （例如三十个人同时看我的上线状态，其中 29 个人看到上线，一个人看到离线） （或偶而就是有人的上线状态被其他人的上线状态盖掉） 那些敢自称资料库的东西通常在相关的事情上面下了不少苦功 https://zh.wikipedia.org/zh-tw/ACID 所以用资料库的话，虽然效能不一定能保障，但是资料不会烂掉这件事情是远比自己写档案有保障的 处理效能问题通常是以下三种方向 - 把资料放在读写很快的地方 - 把工作打散到多个硬体装置上 - 资料结构，演算法，或论文里面写的神秘数学公式 第一点的意义是：如果能用 SSD 就往 SSD 丢，如果能写进记忆体就写进记忆体 如果现在的架构已经开始碰到资料一致性的问题，然後你口袋又有钱可以花在这上面 那买颗 SSD 来存资料就满有可能让问题缓解甚至消失，不一定需要改 code 或者可以考虑在机器上架个 memcache 然後资料都往里面写，SSD 快不过记忆体。 不过记忆体里面的东西只要重开就没了，能否接受要看你的功能规格而定。 如果你真的很有钱，可以考虑 Intel 的 Optane，跟记忆体差不多快的硬碟，根本黑魔法 若走进这条路请务必与版友分享使用心得... 另外也有一些东西是一开始就预设把资料存在记忆体里面 例如上面提到的 memcache，或这几年兴起的 redis 不过靠单台机器的硬体效能提升来解终究有极限 会不会踩到极限就看这个生意(?)做得多好 如果你的资料太多，没办法全部塞进比较快的硬碟/记忆体里面，只能塞一部分进去 那这种招数就叫 cache。然後就要开始考虑 cache 跟主资料怎麽同步，cache 什麽时候过期... 功能比较完整的资料库也会做类似的事情，例如 MySQL 就会把常用资料放到记忆体里面。 所以大的资料库在推上服务之前会先「热机」，用 query 让机器把常用资料先载入好 照我们家 DBA 的说法，有没有热过效能差满多的... 当然也可以把 MySQL 的资料库开在 SSD 甚至 Optane 上面。 第二点大部分人应该不会想自己写程式处理 实务上的例子有 DB 的 cluster 或读写分离机制 另外 no-sql DB 也有不少是为了这点做努力 Hadoop 也是在帮你做这件事 光是确保「不同装置上读到的资料一致」就是一屁股痛 第三点大部分人应该还是不会想自己写程式处理 不过有个值得一提的例子，有些资料库的 index 实作概念上就是个 B+ tree 想要自己土炮的话，这应该是 OS 作业加分题等级能做的出来的东西 我个人是不会拿 PHP 来做这种事情就是了 : 我目前全是用像file_get_contents、file_exists、file_put_contents、fopen等类的函数来操作使用者即时状态值的档案 : 要全改成另一种方式，光改写程式大概就是个大工程了吧… 你现在知道什麽叫做 legacy code 跟 refactor 也知道为什麽会有人说「东西没坏就不想修」了 -- https://xkcd.tw/ 这里翻译某个关於浪漫、讽刺、数学、以及语言的漫画 --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 114.47.6.197 (台湾) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/PHP/M.1616315184.A.7B0.html 突然觉得这堆东西好像可以拿来当面试题目... ※ 编辑: GALINE (60.248.122.206 台湾), 04/29/2021 18:57:57