不是 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 语言干出性能瓶颈的场景还是占少数，浮夸点可以说险些没有哈哈，大概是我资历尚浅，不过话又说回来，各人的经历和我的应该也差不多。最后希望各人可以在数据库层面多花一些功夫，而不是纠结于这门语言到底行不行了，如果数据库都不行了，那么换什么语言都是白瞎，愿这一点各人能有相应的共识。本次的分享内容就到这里结束了，希望对各人能有所启发。
感谢各人阅读，个人观点仅供参考，接待在批评区发表差别观点。

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

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。