mysql 优化案例01

1.订单交易信息表，按照user_id和create_time等查询比较频繁；增加联合索引 KEY `idx_user_ct` (`user_id`,`create_time`),

2.订单对外的查询接口，按照渠道查询selectByChannelId，修改成分页查询

3.订单批量核销任务： 一次执行太多1000条，造成插入的sql报警。修改为100一批次插入订单任务表

4.订单批量核销任务： 为200个task_id经常查询到1000--2000条数据，有的可能更高；已经调小每批task_id数为50，继续跟进效果。  拆分后使用并行查询

5.删除订单系统老代码变更后，无效的索引

6.订单查询接口，根据dealId查询出主键id，600ms的慢查询提高到100ms以内

• 先通过原始条件查询出所有符合条件的记录的主键ID

• 再通过主键ID小批量并行查询数据

1. 先优化业务代码：

   1. 不该load全量数据的不查询全量数据

   2. 需要查询全量数据的使用分页方式查询

2. 需要查询全量数据场景的，考虑添加缓存

七、根据poiId查询订单

查询性能从700ms，优化到120ms

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

mysql 优化案例

8.减少不必要的查询列，只返回需要的列；能使用覆盖索引的，尽量使用覆盖索引

in 和 exists的区别

in 和 exists的区别: 如果子查询得出的结果集记录较少，主查询中的表较大且又有索引时应该用in, 反之如果外层的主查询记录较少，子查询中的表大，又有索引时使用exists。其实我们区分in和exists主要是造成了驱动顺序的改变(这是性能变化的关键)，如果是exists，那么以外层表为驱动表，先被访问，如果是IN，那么先执行子查询，所以我们会以驱动表的快速返回为目标，那么就会考虑到索引及结果集的关系了 ，另外IN时不对NULL进行处理。
not in 和not exists的区别: 如果查询语句使用了not in 那么内外表都进行全表扫描，没有用到索引；而not extsts 的子查询依然能用到表上的索引。所以无论那个表大，用not exists都比not in要快。

查询接口优化：

• 查询条件含有多个字段时，不要在选择性很低字段上创建索引

  •  可通过创建组合索引来增强低字段选择性和避免选择性很低字段创建索引带来副作用；

  •  尽量减少possible_keys，正确索引会提高sql查询速度，过多索引会增加优化器选择索引的代价，不要滥用索引