Skip to content

Commit 96976eb

Browse files
committed
优化索引sql
1 parent 3d04bb9 commit 96976eb

File tree

1 file changed

+10
-4
lines changed

1 file changed

+10
-4
lines changed

MD/数据库-MySQL.md

Lines changed: 10 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -9,21 +9,27 @@
99
如果系统读少,写多的时候,尤其是并发写入高的时候,还需要事务安全性。InnoDB就是首选了。
1010

1111
### [数据库性能优化](https://www.zhihu.com/question/19719997)
12-
1. 优化SQL语句和索引
12+
1. 优化SQL语句和索引,在where/group by/order by中用到的字段建立索引,索引字段越小越好,复合索引简历的顺序
1313
2. 加缓存,Memcached, Redis
1414
3. 主从复制,读写分离
1515
4. 垂直拆分,其实就是根据你模块的耦合度,将一个大的系统分为多个小的系统,也就是分布式系统
1616
5. 水平切分,针对数据量大的表,这一步最麻烦,最能考验技术水平,要选择一个合理的sharding key,为了有好的查询效率,表结构也要改动,做一定的冗余,应用也要改,sql中尽量带sharding key,将数据定位到限定的表上去查,而不是扫描全部的表;
1717

18-
对于第1点
18+
### [SQL优化](https://www.imooc.com/video/3711)
1919

2020
* 对经常查询的列建立索引,但索引建多了当数据改变时修改索引会增大开销
21-
* 使用精确列名查询而不是*
21+
* 使用精确列名查询而不是*,特别是当数据量大的时候
2222
* 减少[嵌套查询](http://www.cnblogs.com/zhengyun_ustc/p/slowquery3.html),使用Join替代
2323
* 不用NOT IN,因为会使用全表扫描而不是索引;不用IS NULL,NOT IS NULL,因为会使索引、索引统计和值更加复杂,并且需要额外一个字节的存储空间。
2424

2525
问:有个表特别大,字段是姓名、年龄、班级,如果调用`select * from table where name = xxx and age = xxx`该如何通过建立索引的方式优化查询速度?
26-
答:由于mysql查询每次只能使用一个索引,所以虽然这样已经相对不做索引时全表扫描提高了很多效率,但是如果在name、age两列上创建复合索引的话将带来更高的效率。如果我们创建了(name, age, class)的复合索引,那么其实相当于创建了(name, age, class)、(name, age)、(name)三个索引,这被称为最佳左前缀特性。因此我们在创建复合索引时应该将最常用作限制条件的列放在最左边,依次递减。
26+
答:由于mysql查询每次只能使用一个索引,如果在name、age两列上创建复合索引的话将带来更高的效率。如果我们创建了(name, age, class)的复合索引,那么其实相当于创建了(name, age, class)、(name, age)、(name)三个索引,这被称为最佳左前缀特性。因此我们在创建复合索引时应该将最常用作限制条件的列放在最左边,依次递减。其次还要考虑该列的数据离散程度,如果有很多不同的值的话建议放在左边。
27+
28+
问:max(xxx)如何用索引优化?
29+
答:在xxx列上建立索引,因为索引是B+树顺序排列的,锁在下次查询的时候就会使用索引来查询到最大的值是哪个
30+
31+
问:如何对分页进行优化?
32+
答:`SELECT * FROM big_table LIMIT 1000000,20`这条语句会查询出1000020条的所有数据然后丢弃掉前1000000条,可以改进成`SELECT a.* FROM big_table a, (select id from big_table where id >= 1000000 LIMIT 0,20) b where a.id=b.id`是用过滤条件将不需要查询的数据直接去除
2733

2834
## 事务隔离级别
2935
1. 原子性(Atomicity):事务作为一个整体被执行 ,要么全部执行,要么全部不执行;

0 commit comments

Comments
 (0)