前言
1、索引的使用优化
1、 exists 代替 in
2、对查询进行优化,应尽量避免全表扫描,,首先应考虑再在where和order by涉及列上建立索引
3、应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描,(除非,字段的名称和索引名称相同)
4、应尽量避免在 where 子句中使用!=或<>操作符,否则将引擎放弃使用索引而进行全表扫描。
5、应尽量避免在 where 子句中使用 or 来连接条件,否则将导致引擎放弃使用索引而进行全表扫描,(除非,or的字段两边都是单独索引)
6、应尽量避免在 where 子句中对字段进行表达式操作,这将导致引擎放弃使用索引而进行全表扫描。如:
7、并不是所有的查询索引都有效,当sql中有大量数据重复时候,比如性别,sex。这样数据项其实很少。所以一般没有必要在它上面简历索引。
8、任何点不要使用select * from table ,需要什么返回什么(相当关键,用具体的字段来代替*)
9、其他的请查看 本人博客 索引入门讲解,.索引并不是越多越好,索引固然可以提高相应的 select 的效率,但同时也降低了 insert 及 update 的效率,因为 insert 或 update 时有可能会重建索引,所以怎样建索引需要慎重考虑,视具体情况而定。一个表的索引数最好不要超过6个,若太多则应考虑一些不常使用到的列上建的索引是否有必要。
10、尽量给where条件and使用大量,尽量创建复合索引
1、千万级数据优化
1.1、制作千万级数据
注意:尽量使用nvicate执行,不要使用idea
1.2、数据量造成的影响
解释:表中的字段越多下面的优化越明显,否则即使使用了下面的优化,也可能没有那么明显
1.3、常见分页优化
通过上面的可以观察到 当达到1000万的时候,查询时间到了37s,太可怕了
1.3.1、优化1: 0.23s 简直要飞起来了
原理:
1、先使用覆盖索引index查询 ,我们只查询id索引这一个字段,比select *
或者多个字段快多了,因为只要我们写上这些字段,我们只需要10个,但是从第一条开始到 1000万条其实是都要去扫描的
2、然后再进行索引范围内range查询
id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
1 | PRIMARY | tb_ams_inf_repay_stat | range | PRIMARY | PRIMARY | 8 | NULL | 3258410 | Using where |
2 | SUBQUERY | tb_ams_inf_repay_stat | index | NULL | idx_orgcd_loannum | 216 | NULL | 19753500 | Using index |
#### 1.3.2、优化2: 0.31 jon
id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
1 | PRIMARY | <derived2> | ALL | NULL | NULL | NULL | NULL | 1000020 | NULL |
1 | PRIMARY | a | eq_ref | PRIMARY | PRIMARY | 8 | b.id | 1 | NULL |
2 | DERIVED | tb_ams_inf_repay_stat | index | NULL | idx_orgcd_loannum | 216 | NULL | 19753500 | Using index |
1.4、其他优化
1.4.1、适合带有条件的,id连续的查询
1.3.2、带有条件id不连续的查询,考虑建立索引
id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
1 | PRIMARY | NULL | NULL | NULL | NULL | NULL | NULL | NULL | ~~~~ |
2 | SUBQUERY | tb_ams_inf_repay_stat | ref | idx_orgcd_loannum | idx_orgcd_loannum | 93 | const | 1 | Using where; Using index |