本篇文章给大家带来了关于mysql的相关知识，其中主要介绍了关于索引大幅优化某php应用性能的相关内容，下面一起来看一下，希望对大家有帮助。
起因
前两个月某朋友要做一个项目，本着快速上线推广的目的，直接购买了某公司的源码并让卖家部署上线。看到源码后，我直接对朋友说：算是被小坑了，这个源码质量有点差，用户数起来后可能会有比较严重的性能问题。
做出这样的评价，我是有依据的：
-
作为近乎实时应用，核心代码用PHP编写，通过数据库表记录控制许多场景的并发和重复请求；
立即学习“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占用高是有原因的并且是可能的，但还是想看看为什么这么耗资源。
Magento是一套专业开源的PHP电子商务系统。Magento设计得非常灵活，具有模块化架构体系和丰富的功能。易于与第三方应用系统无缝集成。Magento开源网店系统的特点主要分以下几大类，网站管理促销和工具国际化支持SEO搜索引擎优化结账方式运输快递支付方式客户服务用户帐户目录管理目录浏览产品展示分析和报表Magento 1.6 主要包含以下新特性：•持久性购物 - 为不同的
登录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也能撑得住。
进一步查看代码并结合日志，创建索引和修改部分查询语句，CPU占用率降到6%左右，终于暂时不用担心性能问题了
总结
工程师在开发工程中，不仅要写出“能用”的代码，更要写出“好用”的代码。本例中通过创建两个索引就能大幅提升系统性能，便是让代码从“能用”转到“好用”。
本文提到的性能优化偏运维，代码中的性能优化暂时还未触碰。但一个总体的原则是不会错的：多使用缓存，尽可能的减少慢IO设备的同步读取。
