|
博主小时辰看到鱼塘挖开小口子放水，水面有各类漂流物。浮萍和树叶总能顺遂通过出水口，而树枝会盖住其他物体通过，偶然还会卡住，必要人工整理。MySQL就是鱼塘，最大并发数和收集带宽就是出水口，用户SQL就是漂流物。
不带分页参数的查询可能影响大量数据的update和delete操纵，都是树枝，我们要把它打散分批处理赏罚，举例声名：
营业描写：更新用户全部已逾期的优惠券为不行用状态。
SQL语句：
- update status=0 FROM `coupon` WHERE expire_date <= #{currentDate} and status=1;
假如大量优惠券必要更新为不行用状态，执行这条SQL也许会堵死其他SQL，分批处理赏罚伪代码如下：
- int pageNo = 1;
- int PAGE_SIZE = 100;
- while(true) {
- List<Integer> batchIdList = queryList('select id FROM `coupon` WHERE expire_date <= #{currentDate} and status = 1 limit #{(pageNo-1) * PAGE_SIZE},#{PAGE_SIZE}');
- if (CollectionUtils.isEmpty(batchIdList)) {
- return;
- }
- update('update status = 0 FROM `coupon` where status = 1 and id in #{batchIdList}')
- pageNo ++;
- }
操纵符<>优化
凡是<>操纵符无法行使索引，举譬喻下，查询金额不为100元的订单：
- select id from orders where amount != 100;
假如金额为100的订单少少，这种数据漫衍严峻不均的环境下，有也许行使索引。鉴于这种不确定性，回收union聚合搜刮功效，改写要领如下：
- (select id from orders where amount > 100)
- union all
- (select id from orders where amount < 100 and amount > 0)
OR优化
在Innodb引擎下or无法行使组合索引，好比：
- select id，product_name from orders where mobile_no = '13421800407' or user_id = 100;
OR无法掷中mobile_no + user_id的组合索引，可回收union，如下所示：
- (select id，product_name from orders where mobile_no = '13421800407')
- union
- (select id，product_name from orders where user_id = 100);
此时id和product_name字段都有索引，查询才最高效。
IN优化
IN得当主表大子表小，EXIST得当主表小子表大。因为查询优化器的不绝进级，许多场景这两者机能差不多一样了。
实行改为join查询，举譬喻下：
- select o.id from orders o left join user u on o.user_id = u.id where u.level = 'VIP';
回收JOIN如下所示：
- select o.id from orders o left join user u on o.user_id = u.id where u.level = 'VIP';
不做列运算
凡是在查询前提列运算会导致索引失效，如下所示：
查询当日订单
- select id from order where date_format(create_time，'%Y-%m-%d') = '2019-07-01';
date_format函数会导致这个查询无法行使索引，改写后：
- select id from order where create_time between '2019-07-01 00:00:00' and '2019-07-01 23:59:59';
停止Select all
假如不查询表中全部的列，停止行使SELECT *，它会举办全表扫描，不能有用操作索引。
Like优化
like用于恍惚查询，举个例子(field已成立索引)：
- SELECT column FROM table WHERE field like '%keyword%';
这个查询未掷中索引，换成下面的写法：
- SELECT column FROM table WHERE field like 'keyword%';
去除了前面的%查询将会掷中索引，可是产物司理必然要前后恍惚匹配呢?全文索引fulltext可以实行一下，但Elasticsearch才是致垣兵器。
Join优化 （编辑：湖南网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
