sql常见优化写法

1、避免select * from，字段太多

2、级联查询的情况下，避免使用大表作为驱动表（会增加查询循环的次数，inner join会自动选择小表作为驱动表）

-- 普通分页查询
SELECT * from table  limit 100000,10; -- 结果显示4.73s


-- 优化之后的分页查询 (前提是该ID为主键)
-- 第一种写法
SELECT a.* FROM table a INNER JOIN (SELECT id FROM table LIMIT 100000,10) b ON a.id = b.id; -- 1.127s

--第二种写法
SELECT a.* from table a where id >=(SELECT id from table limit 100000,1) LIMIT 10;

select goods_id,goods_name from goods where goods_id = (select max(goods_id) from goods);执行子查询时，MYSQL需要创建临时表，查询完毕后再删除这些临时表，所以，子查询的速度会受到一定的影响，这里多了一个创建和销毁临时表的过程。

• 连接查询（JOIN）连接查询不需要建立临时表，因此其速度比子查询快。另外注意：能过滤先过滤，过滤好了再链接

 

总结：

先定位问题，然后再思考优化方案。在不影响已有业务的情况下进行优化，不能影响正常功能的使用。

先考虑后台接口逻辑优化，其次考虑业务逻辑优化。

优化过程中，也需要与前端沟通，了解实际的业务需求，是否可以简化一些逻辑。

1. 代码逻辑优化
   • 避免循环查库操作
   • 避免重复查询；
   • 不要在同一个接口累加非标准的业务逻辑，有必要时增加新的接口满足不同的业务场景，或者通过配置项控制。
   • 与业务逻辑无关的操作采用异步或切aop方式；
   • 高并发接口，字典数据可以使用redis缓存；
   • 获取字典数据接口可以配置 nginx 缓存；
   • 读取次数较高的配置项，可以改为从内存中读取，减少redis压力
2. sql 优化
   • 查询语句添加索引
   • 尽量不要用select * ，只查询需要的字段
   • 尽量不要使用 union、union all，增加冗余字段简化sql
   • 尽量不要多表联查，增加冗余字段简化sql