不是 PHP 不行了，而是 MySQL 数据库扛不住啊

文章不是 PHP 不行了，而是 MySQL 数据库扛不住啊分享给大家，欢迎收藏极客之家，专注分享技术知识

大家好，我是码农先森。

大多数的业务场景下 PHP 还没有达到性能瓶颈，然而 MySQL 数据库就先行驾崩了。但我们总是不分青红皂白，一股脑的把原因归结于是 PHP 语言不行了，每当遇到这种情形我就会感叹到 PHP 的命真苦啊。PHP 作为一门优秀的开源编程语言，在编程语言界一直享有「PHP是世界上最好的语言」的美誉，它让 PHP 靓仔们养了家糊了口过上了小康生活，但一遇到点性能问题就被疯狂的吐槽，它真是干了件吃力不讨好的活。当然我相信这种吐槽是少数的，绝大数的人都还是会秉承理性公正的眼光来看待 PHP 语言，在碰到问题时会仔细分析缘由，找到问题的症结并解决它，让 PHP 绽放属于它自己的光芒。

还记得在之前的工作经历中，使用 ThinkPHP 框架开发公司内部的 ERP 后台系统，很多的情况都是数据库拖慢了用户的访问速度，比如开发的一些财务数据报表，这些接口往往都会聚合了好几张数据表的数据，左连接一张表右连接一张表，动不动还搞个全连接，这能不慢嘛。不仅如此，还有在一个接口里 SQL 语句的查询都嵌套了好几层，各种子查询漫天飞，这样的代码现状简直惨不忍睹，数据量小的时候尚且能用不会影响用户的体验，当数据量上来时接口就经常搞超时，数据库的慢日志都打满了。在我印象中有个最深刻的例子，就是有一个速卖通的产品编辑功能，一个页面需要能同时编辑几十个产品，这就是所谓的批量编辑，而且每个产品的详情数据特别多，还包括很多的图片，每次加载这些数据和图片就半天了，这个功能使用人数最多、使用次数最频繁，同时也是被吐槽的最多的。如果有开发过类似功能的朋友，可能会有比较深刻的感触。

还有一种用脚本跑异步任务的场景，由于有些报表用接口是真的搞不出来了，那就用脚本的方式定时计算。但当时由于我们的数据量比较大，都是上百万千万级别的，单进程跑数据太慢，为了提升效率就直接干上了 PHP 多进程。那时我们还满心欢喜的 Fork 着进程，一启动脚本就是并发几十个进程，结果现实情况就是给我们当头一棒，阿里云 MySQL 数据库监控系接连报警，登上云控制台一看傻眼了，CPU 直接干到 100% 满载运行，搞的 ERP 后台系统都无法正常访问了。还被技术老大当头呵斥你们搞什么飞机，吓得我们赶紧通过 Kill 命令把脚本进程强制杀掉。说到这里可能有些朋友会有些疑惑了，为什么异步脚本会影响到 ERP 后台系统呢？原因是大多数的 PHP 靓仔们都有直接在线上环境修改代码的习惯，当然这种事情在我们这里也不例外了哈哈，甚至有时都变成了常态，感觉就是怎么方便怎么来。所有的业务都是共享一个数据库，这不就影响到 ERP 后台系统了嘛。

通过谈我之前的经历，可以看出并不是 PHP 不行，而是因为没有正确的使用好 PHP 而把数据库搞垮了，单纯的责怪 PHP 语言本身没有任何意义。很多时候性能的瓶颈，往往都是先在数据库层面出现，比如某些查询没有命中索引、子查询嵌套层数过多、长事务造成死锁、并发大量的操作造成负载过高等等。总而言之，在我的经历中把 PHP 语言干出性能瓶颈的场景还是占少数，夸张点可以说几乎没有哈哈，可能是我资历尚浅，不过话又说回来，大家的经历和我的应该也差不多。最后希望大家可以在数据库层面多花一些功夫，而不是纠结于这门语言到底行不行了，如果数据库都不行了，那么换什么语言都是白瞎，愿这一点大家能有相应的共识。本次的分享内容就到这里结束了，希望对大家能有所启发。

感谢大家阅读，个人观点仅供参考，欢迎在评论区发表不同观点。

---

欢迎关注、分享、点赞、收藏、在看，我是微信公众号「码农先森」作者。

版权声明：本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系邮箱：jacktools123@163.com进行投诉反馈，一经查实，立即删除！