PHP工程师必学：3招数据建模提效70%

　　我越来越觉得“PHP工程师必学：3招数据建模提效70%”是错的。

文章配图，仅供参考

　　我原以为只要把EAV结构打散、把冗余字段塞进JSONB、再加一层读写分离的查询路由，就能扛住日均十七个站的促销并发——结果上线第三天，MySQL慢查飙升到每秒二十三次，DBA老张甩给我一张截图，上面写着“SELECT FROM `order_items` WHERE order_id IN (SELECT id FROM orders WHERE status = 'pending')”，后面跟着三个感叹号。他叼着半截烟，说：“你这建模，比菜市场讨价还绕。”

　　那三招确实存在。我三个月前试过。先改表结构，把address从users表里拎出来单建address_book；再搞个“聚合根”层，让OrderService调用UserAddressProxy；最后加个Redis哈希缓存用户最后一次收货地址。跑了两天，QPS涨了12%，但内存泄漏速率从每天300MB变成每天1.1GB。运维小林在凌晨两点发来钉钉语音，背景里是机房空调轰鸣声，他只说了半句：“你那个……缓存Key里嵌了$_SERVER['REQUEST_TIME_FLOAT']对吧？”然后自己挂了。

　　我冷眼看着。不是不想修，是修完发现更糟。你猜怎么着？订单导出Excel时，要合并用户基础信息+地址+发票抬头+优惠券使用记录，一共十九个字段，其中七个来自view，四个来自临时join，两个靠PHP数组merge补全。跑一次导出，MySQL进程list里挂了四十六个Sleep状态连接，最长那个卡了4分17秒。开发组长王磊蹲在工位旁看我调dump，突然伸手关掉我的Xdebug，说：“别调了，你缓存的是字段，不是意图。”

　　他说话时左手无名指上还沾着蓝色圆珠笔油墨——昨天他刚手写了一份《订单查询路径白皮书》，用的是A5横格本，第一页画了五条线，分别标着“下单”“支付回调”“客服后台查单”“财务对账”“BI报表”。每条线末端都歪歪扭扭写着“查不到最新地址”“发票字段拼错两次”“优惠券过期时间漏算TZ”。没有一张ER图，全是箭头和叉号。

　　优胜劣汰这点我认。真认。你看我试的那三招，活下来的只有中间那条：用View封装常用多表关联。但它是被业务按在地上摩擦出来的，不是建模手册教的。上周五我们删掉DTO转换层，把address_book.id直接扔进订单详情API响应体里——前端说字段名不一致要改，我说你先把JS里那行data.shipping_address.full_name改成data.address.full_name，改完测试通过了。他们愣了两秒，问：“原来这个address是关联表，不是JSON？”我说：“是啊，你们三年前就在用它。”

　　有次我在食堂听见隔壁组两个新人聊“数据一致性”。一个说“得靠事务锁”，另一个摇头：“事务锁不住跨库操作，得上Saga。”俩人捧着不锈钢餐盘，米饭上浇着红烧肉汁，旁边桌上放着半瓶没喝完的茉莉花茶，瓶身凝着水珠。我听着差点把筷子掉进汤里。他们不知道，上个月财务部那个对账脚本，跑崩三次，原因都是我们订单表里status字段存的是中文“待支付”，而对账系统期待的是英文pending——没人改表，没人加枚举校验，就靠手动UPDATE修了八百单。对，八百单。不是八百条SQL，是八百个真实客户、八百次客服通话记录、八百份纸质签收单拍照上传。

　　所以现在我不教人建模。我教人查log。查nginx access log里哪个接口平均响应超800毫秒；查laravel.log里出现频次最高的Exception类名；查数据库slow_query_log里排在TOP3的SQL模板——别管它合不合范式，先看哪条SQL实际堵死了整个队列。上周我把这个习惯教给实习生，他当天就抓出一个用Carbon::now()->subDays(30)作where条件却没加date索引的查询。他问我：“这个算数据建模问题吗？”我说不算，算人没看清EXPLAIN输出里的type=ALL。

　　我桌上还压着那份被划掉一半的《三招速成指南》打印稿，右下角写着“2024.02.19初稿”，墨迹有点洇。左边咖啡渍还没干透，右边贴着便签，上面是我自己写的：“别信‘提效70%’，信MySQL的processlist里sleep超60s的连接数。”

　　这事我也可能就运气好。上个月换库前没测出JSONB字段在WHERE里用LIKE的性能断崖，纯属因为那天运维刚好请假，备份脚本没跑全。下次可能就不止断崖了。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!