在业务快速开发迭代中，其实很多性能的瓶颈在于我们底层的数据库，sql语句的性能，索引创建的时机，间接就决定着我们请求响应时间。
sql之所以要优化是因为有大量的慢查询存在，可以利用show variables like 'slow_query_log'来查看是否开启慢查询，以及慢查询的阈值设置根据自己的业务开发需要而做修改，那慢查询产生的原因有以下几点：
1.两张比较大的表进行 JOIN，但是没有给表的相应字段加索引，这个是最常见的慢sql出现的原因
2.表存在索引，但是查询的条件过多，且字段顺序与索引顺序不一致
这里就要说到联合索引，要满足最左前缀匹配原则，mysql会一直向右匹配直到遇到范围查询(>、<、between、like)就停止匹配，比如a = 1 and b = 2 and c > 3 and d = 4 如果建立(a,b,c,d)顺序的索引，d是用不到索引的，如果建立(a,b,d,c)的索引则都可以用到，a,b,d的顺序可以任意调整；
3.对很多查询结果进行 GROUP BY
Group By 关键字由于涉及到数据的排序，对于数据量特别大的情况，还需要进行外排序。所以，尽量对小数据量进行 Group By 操作；group by 尽量对少的数据量使用 前面加where 过滤后使用,提前规划好数据库设计避免大数据量group by，可以考虑能不能把group by后面的纬度一开始分表存储
下面是在学习工作之中遇到的实际问题
场景1:
在 90 万条的数据表中，大概在 30 个字段左右，字段都是 int 和 char 类型。其中一个字段 name 的值有 a、b、c、d 四种。给 name 创建了普通索引。
SELECT * FROM hotel WHERE name IN('a','b');
此时利用explain关键字进行sql性能分析发现type是ALL，说明进行性能比较差的全表扫描，并没有走索引，Extra是Using where，说明就算用了索引后，还要进行回表操作，可以会造成不必要的IO操作
索引完全没有起到任何作用。如何优化索引？
其实这里并不是因为数据量少而不走索引，而是索引本身建立的不正确，name字段本身的唯一性并不高，我们在理解索引本质之后假设走了索引，并且假设一个极端的情况，90万数据，name字段有0，1两个值，利用索引先要读索引文件，然后利用二分查找或者b+数分叉查找，找到对应的数据磁盘指针，再通过指针读取磁盘上的数据（如果是非聚集索引，还要进行多级索引读取），影响的结果集是45万（二分查找的情况），那在这种情况下，索引查找步骤繁琐，甚至不如全表扫描的速度快。
所以说，当name字段唯一性不高时，in中的数据过多时，将不会走索引。
场景2:
比较经典的例子是在mysql中limit可以实现快速分页，但是如果数据到了几百万时我们的limit必须优化才能有效的合理的实现分页了，否则可能卡死你的服务器。
select * from table limit 0, 10 ,这个是没有问题的，如果select id,name,content from users order by id limit 100000,20，这条语句扫描100020行，但只要20行，问题就出在这里了，首先可以这样优化，如果记录了上次的最大ID
利用select id,name,content from users where id>100073 order by id asc limit 20，扫描20行
再比如 select * from table where name=’f’ order by id limit 300000,10 执行时间是 3.21s 优化后的sql：
select * from (
select id from table
where byname=’f’ order by id limit 300000,10
) a
left join table b on a.id=b.id。执行时间为 0.11s 速度明显提升
这里需要说明的是 我这里用到的字段是 name ,id 需要把这两个字段做复合索引，否则的话效果提升不明显。
当一个数据库表过于庞大，LIMIT offset, length中的offset值过大，则SQL查询语句会非常缓慢，你需增加order by，并且order by字段需要建立索引。
如果使用子查询去优化LIMIT的话，则子查询必须是连续的，某种意义来讲，子查询不应该有where条件，where会过滤数据，使数据失去连续性。
如果你查询的记录比较大，并且数据传输量比较大，比如包含了text类型的field，则可以通过建立子查询。
