这是一个电商项目
由于双十一来临，项目订单数据量极具上升。一下子就上升到百万级别的数据了，业务就反映后台订单查询加载很慢。
然后我就去慢日志文件了查看果然发现这条SQL执行时间已经上升到了5秒多，我记得当时才几十毫秒。
于是我就开始把这条SQL复制出来，开始研究怎么优化。
我一般优化的思路（1、检查SQL语法是否有问题（比如用了子查询，或者说大表连小表） 2、是否建立了索引 3、是否索引失效导致全表扫描，4、检查mysql服务磁器盘cpu、5、数据量太大是否需要分库分表）
首先看SQL语句
噗 有点长 可以点击格式->美化SQL 就成这样了 看起来舒服一点
我们先检查SQL语法有没有问题 订单查询 一般首先查的是订单表然后再去链接其他关联表进行查询
检查之后发现没有问题 我们在本地执行一下
咦 发现速度很快 才17ms
原来是我本地数据量太少 ，于是我准备忘订单表批量插入数据
insert into c2m_order (name.....) select name ,... c2m_order
这样每执行一次数据就每次多了两倍 直到我数据库变成了200多万
在执行一次
啊 变成了6秒。。。。。
我们用EXPLAIN 查看一下SQL的执行计划，我们发现订单表type类型为ALL 也就是没有用到索引 扫描了全表
这下我们找到问题了 看看该如何解决 看下面这部分SQL
只有两个条件还有一个分页 ，一个是删除标志 一个是创建时间倒序
我们再看一下这张表的索引结构
我们发现这两个字段都是没有索引的，大家都知道数据库主键是默认会建主键索引
我们把create_date 创建时间换成id 试试
我们发现已经用上了type级别为index 说明已经用上了索引 我们再看看 执行的时间已经变了25ms 大大的减短了时间
可是我们总不能按id排序了业务不允许啊
所以我们给create_date加上索引
我们再看看执行计划和执行时间
新建的那个索引已经用上了
时间也变成了18ms了，大功告成，赶快去正式库加了个索引，立马就解决了问题。