PHP工程师必学的3个数据建模技巧

文章配图，仅供参考

　　第一个技巧其实特简单：别用“万能类型”糊弄。我见过有人把所有字符串字段都设成varchar(255)，理由是“反正能存”。结果呢？去年做订单系统的时候，有个字段叫“优惠类型”，本来只有“满减”“折扣”“免单”三种值，结果被塞了“满减-限时”“折扣-新用户”这种带后缀的字符串——长度从3字节飙到20字节，索引效率直接拉胯。更离谱的是，后来业务要按类型统计，SQL里得用LEFT(字段,2)截取，索引直接失效，慢查询日志堆了俩G。开发还跟我犟：“你优化下索引不就行了？”我反手把建表语句甩他脸上：“varchar(255)的索引能小？你当MySQL是神仙？”

　　第二个技巧更反常识：别盲目追求“规范化”。有回做用户系统，我按教科书搞了六张表——用户基础表、地址表、标签表、权限表…结果查询个用户详情要联五张表，PHP代码里嵌了三层循环。运维半夜给我打电话：“你写的SQL把CPU干到100%了！”我爬起来一看，好家伙，一个用户有五个地址、三个标签，联表查询直接生成了15条中间记录，MySQL的临时表都撑爆了。后来咬着牙把地址和标签拍扁成JSON存到用户表里，查询时间从三秒掉到二十毫秒——开发还吐槽：“这不就是反规范化吗？”我怼他：“规范化是给数据库省空间，不是给业务添堵的！你见过哪个用户会同时改五个地址？”

　　第三个技巧最容易被忽略：主键不是摆设。之前接手个老项目，表的主键是自增ID，但业务上根本不用它查询——所有操作都靠“业务编号”字段，比如订单号、用户编号。结果呢？查询得先扫主键索引，再通过业务编号关联，慢得离谱。我提议把业务编号设成主键，开发直接摇头：“自增ID多方便，业务编号可能重复怎么办？”我当场翻出业务文档：“订单号是UUID，用户编号是手机号+随机码，重复概率比中彩票还低！”改完主键后，查询直接走业务编号的聚簇索引，速度快了五倍——不过运维后来跟我抱怨：“备份恢复的时候得先处理业务编号的唯一性，麻烦死了。”我耸耸肩：“麻烦总比慢查询好，大不了我写个脚本帮你处理。”

　　窗外天黑了，屏幕上的行数还在跳。我突然想起上个月跟架构师吵架的事——他说数据建模要“高内聚低耦合”，我怼他：“你倒是说说，怎么在PHP里实现？是让开发写二十层中间表，还是直接拍扁成JSON？”他沉默了三秒，说：“那你说怎么办？”我指了指屏幕上的慢查询日志：“先保证查询能跑快，再谈设计模式。”

　　其实这些技巧说白了就是“优胜劣汰”：字段类型选最合适的，不是最通用的；表结构按查询需求设计，不是按理论规范；主键用业务上最常用的，不是最省事的。我原以为这些是常识，结果看了不少项目的建表语句，发现能全做对的PHP工程师，十个里顶多三个——剩下的不是用varchar(255)存布尔值，就是用自增ID当业务主键，慢查询爆出来的时候还怪数据库不行。

　　下一步我打算把这几个技巧写成脚本，新项目建表的时候自动检查字段类型和主键设计——不过领导说“先保证业务上线”，所以可能得等挺久。至于现在，要是再遇到用varchar(255)存状态码的开发，我直接把他的键盘抢过来自己改建表语句——慢查询爆出来的那一刻，谁爱背锅谁背，反正我不背。

（编辑：站长网）

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