记一次线上mysql慢查询问题

问题: 最近维护的一个项目，线上服务在查询商品详情的时候出现一只在加载中，客服反馈说是要等好久在加载出来。

商品详情出现这种问题，肯定是不行的。为了尽快的先解决线上问题。我自己也先去试了一下接口请求，发现的确是很慢。具体也不清楚原因，之前也没有听说同事说这个有问题。

我处理的步骤：

1.确认接口有没有报错问题，检查线上日志接口是没有任何报错信息。日志信息也很长成。就是接口响应有点慢。

2.由于这个接口主要是商品信息的查询，没有其他的操作业务。我第一次想到的可能是数据库查询慢。所以第一步赶紧看线上的mysql的慢查询日志。通过日志的确可以查询某一段时间内的慢查询，仔细检查会发现看是不是有对应业务的查询慢sql。发现的确有而且不止一条

搂出来一条查询。我去这个慢的有点让人上头了。 我发现这个商品详情里面sql查询大概就有7条，我的天。虽然慢但是还是要优化的，线上问题比较急需要尽快修复。拿到sql 语句通过explain观察的确是有全表扫描的，而且是商品表。目前商品表中大致有500W（没有做分表这类的）。

分析这条sql语句，之前为什么这样写是要查询出来什么数据，看他sql可以看出来 他是想通过商品查询这个商品的组下的所有商品 和自己的信息。通过这个sql其实我大致也知道慢的原因，条件中使用OR拼接导致索引失效，通过屏蔽or条件 查询 没有发现全表扫描 

而且这个type类型列也达到了ref,不在是之前的 ALL了。这样虽然暂时可以解决 但是 如果按照这样修改 查询出来的数据肯定跟之前的是有出于的。因为id =127205的数据没有查询出来。这里我采用的是通过

union 链接查询来优化的，将这个sql优化成两部分。

我们知道一条sql执行的大致流程：

按照图所示其实mysql服务跟我的sql做了很多优化，有时候只是我们写的sql不规范，建表建索引不规范导致，mysql自身的查询优化器无法进行优化。

虽然这次临时的修复了这个慢查询。但是对于mysql的优化。我自己也在这次进行了一些了解。

我们常听说的sql优化，其实我们 能够把控的 只有 数据库表结构 ，SQL 语句和索引 这两块 ，像其他的 硬件层面，mysql服务底层 我们不好去做调整。

所以我们在做的时候，只能按照要求，规范去好表设计，索引创建 等。后面会对sql的优化写一写自己看法。