不是 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 言语干出功用瓶颈的场景仍是占少量，夸大点能够说几乎没有哈哈，或许是我资格尚浅，不过话又说回来，我们的阅历和我的应该也差不多。最终期望我们能够在数据库层面多花一些功夫，而不是纠结于这门言语究竟行不可了，假如数据库都不可了，那么换什么言语都是白瞎，愿这一点我们能有相应的一致。本次的共享内容就到这儿完毕了，期望对我们能有所启示。

感谢我们阅览，个人观念仅供参考，欢迎在谈论区宣布不同观念。

欢迎重视、共享、点赞、保藏、在看，我是微信大众号「码农先森」作者。