起因
前两个月某朋友要做一个项目，本着快速上线推广的目的，直接购买了某公司的源码并让卖家部署上线。看到源码后，我直接对朋友说：算是被小坑了，这个源码质量有点差，用户数起来后可能会有比较严重的性能问题。
做出这样的评价，我是有依据的：
- 作为近乎实时应用，核心代码用PHP编写，通过数据库表记录控制许多场景的并发和重复请求；
- PHP开发不是问题，但对方工程师似乎不知道有CLI模式，而是通过计划任务(crontab)达到程序不停运转，于是乎浩浩荡荡几十条
curl计划任务每分钟执行； - 代码中有不少 class1.php， class1-1.php这样复制备份的文件，一眼看过去很难知晓其存在目的；
- 存在不少for循环读取数据库的代码，命名规则混乱。
当然，能赚钱的代码才是好代码(对方就通过这些代码赚钱了)，我也没多去纠结。最初的想法是，4核8G的配置，跑1万个客户应该很难，跑5000就可以了。
转折
就在这周，忽然频繁接到 阿里云 的报警短信和邮件，说CPU占用过高。心想市场推广很顺利，用户大增吗？一问朋友，才不到300个用户！
这时才意识到，这套代码实际表现比我想想中的更差，有严重的性能问题。按照这个资源消耗速度，升级硬件是无底洞，性能优化才是正途。
性能优化
拿到代码两个月了，闲暇时间偶尔会看一下，已经大体知道其结构和主要功能。现在出现了严重性能问题，是时候尝试做一些性能优化了。
鉴于几十个计划任务不停运行，其不断驱动系统运转，因此计划任务的相关功能是最先被了解的。根据自己的理解，首先暂停了二十多个已经不需要的计划任务。暂停无用计划任务后，系统总体CPU使用率下降到了60%多，烦人的提醒短信和邮件终于消停了。等待了一天，朋友也没有反馈有功能受影响，说明思路和出手点都正确。
但是200多个用户就这么消耗资源，一定还有什么地方不对劲。今天有空又登录服务器，执行top命令，发现MySQL进程一直占据200%多的CPU资源。看过源码的我知道MySQL占用高是有原因的并且是可能的，但还是想看看为什么这么耗资源。
登录MySQL服务器，查看是否开启了slow log：show variables like '%slow%';，发现开启了慢查询日志：
接着查看日志，查到某条sql语句一直出现在日志中：
可以看到，执行这条sql语句扫描了38万多行记录。语句涉及到的两张表一张有600多条记录，另一张4万多条记录，相当于全表扫描了4万多的表好几次，怪不得特别慢。
接着检查两张表的索引，除了自增id作为主键外，没有创建其他索引。使用explain执行语句，显示没有使用任何索引：
接下来，在两张表上分别就查询条件的uid、session_id列上创建索引。索引创建完成后，肉眼可见的CPU占用率和系统负载都降下来了。再次使用explain执行查询语句，索引信息已经用上了，扫描行数大大减少：
经过上面的优化，目前应用的总体CPU占用率在5%左右，MySQL的CPU占用率大约为15%，系统负载从4降到了0.3。终于暂时不用担心性能问题了，即使服务器配置降到1核CPU也能撑得住。
2021.11.06更新：进一步查看代码并结合日志，创建索引和修改部分查询语句，CPU占用率降到6%左右，终于暂时不用担心性能问题了
总结
工程师在开发工程中，不仅要写出“能用”的代码，更要写出“好用”的代码。本例中通过创建两个索引就能大幅提升系统性能，便是让代码从“能用”转到“好用”。
本文提到的性能优化偏运维，代码中的性能优化暂时还未触碰。但一个总体的原则是不会错的：多使用缓存，尽可能的减少慢IO设备的同步读取。
参考
1. 记一次C++程序优化经历