语句如下，其中shop_id建立了索引，扫描行数712127行：
select
id,
material_id,
cnt,
stock_cnt,
status,
type,
gmt_deadline,
sale_type,
gmt_gen
from
stock_count t
where
t.shop_id = '330547’
and t.brand_id = '100148’
and t.status in (0, 2)
and t.is_init = 0
and t.type in (2, 1, 3)
and t.sale_type in (0, 1)
order by
id desc
LIMIT
0, 1
第一：找出哪条慢。 每一次查询肯定有一个单独的io，你在单独的对象上增加时间戳，然后结束时打印出它的耗时。 第二：优化。sql语句是不是固定不变的？如果是，能不能写成存储过程或者预编译？这一类做法可以减少数据库解析sql语句的时间。 第三：检查是否是数据连接池问题。数据连接池默认有最大连接数限制。 你一次执行50条，如果你的最大连接数是10，那你一次只能执行10条，其它的都在排队，等于说你的50条并没有真正的并行。
@Gitforxuyang 1.这个统计时间是mysql服务器统计出来的，不是js后端代码统计出来的，也就是说，和连接数没关系，这纯粹就是sql在mysql服务器的执行起始时间到sql结束时间。2.做成存储过程或者预编译可能会带来速度提升，但是我现在最想知道这条sql慢的原因，为啥单独执行就非常快
1. shop_id 应该是唯一的吧，如果是唯一的，为什么还扫描了70W行数据？说明你的索引没用？
2. 如果shop_id 不唯一，能否给其他具有较大离散度的字段建索引。
3.楼上有人说用存储过程，个人觉得：sql编译也用不了这么长的时间，改为存储过程可能优化效果不明显。。个人猜测。
4.总数据量有多少？
5.把explain 分析的结果贴出来看看。。
顺便问下怎么会有这种sql呢： 以 id 字段做 GROUP BY，而输出字段中非 id 字段 （material_id, cnt, stock_cnt, status, type, gmt_deadline, sale_type, gmt_gen） 是直接输出而非聚合函数处理结果？
又是一个被mysql荼毒的mysqler ……
