Skip to content

Commit 48a8bef

Browse files
committed
mysql强化
1 parent 6c9332f commit 48a8bef

File tree

1 file changed

+15
-5
lines changed

1 file changed

+15
-5
lines changed

MD/数据库-MySQL.md

Lines changed: 15 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -5,8 +5,8 @@
55
2. InnoDB支持外键
66
3. InnoDB有行级锁,MyISAM是表级锁
77

8-
因为MyISAM相对简单所以在效率上要优于InnoDB。如果系统读多,写少,对原子性要求低。那么MyISAM最好的选择。
9-
如果系统读少,写多的时候,尤其是并发写入高的时候,还需要事务安全性。InnoDB就是首选了
8+
MyISAM相对简单所以在效率上要优于InnoDB。如果系统插入和查询操作多,不需要事务外键。选择MyISAM
9+
如果需要频繁的更新、删除操作,或者需要事务、外键、行级锁的时候。选择InnoDB
1010

1111
### [数据库性能优化](https://www.zhihu.com/question/19719997)
1212
1. 优化SQL语句和索引,在where/group by/order by中用到的字段建立索引,索引字段越小越好,复合索引简历的顺序
@@ -53,6 +53,7 @@
5353

5454
主要使用[B+树](https://www.jianshu.com/p/3a1377883742)来构建索引,为什么不用二叉树是因为B+树是多叉的,可以减少树的高度,还有事索引本身较大,不会全部存储在内存中,会以索引文件的形式存储在磁盘上,然后是因为[局部性原理](https://www.cnblogs.com/xyxxs/p/4440187.html),数据库系统巧妙利用了磁盘预读原理,将一个节点的大小设为等于一个页,这样每个节点只需要一次I/O就可以完全载入,(由于节点中有若干个数组,所以地址连续)。而红黑树这种结构,深度更深。由于逻辑上很近的节点(父子)物理上可能很远,无法利用局部性
5555

56+
在InnoDB里,每个页默认16KB,假设索引的是8B的long型数据,每个key后有个页号4B,还有6B的其他数据(参考《MySQL技术内幕:InnoDB存储引擎》P193的页面数据),那么每个页的扇出系数为16KB/(8B+4B+6B)≈1000,即每个页可以索引1000个key。在高度h=3时,s=1000^3=10亿!!也就是说,InnoDB通过三次索引页的I/O,即可索引10亿的key。通常来说,索引树的高度在2~4。
5657
#### 分析
5758
好处:
5859

@@ -72,11 +73,20 @@
7273
2. 离散度大(不同的数据多)的列使用索引才有查询效率提升
7374
3. 索引字段越小越好,因为数据库按页存储的,如果每次查询IO读取的页越少查询效率越高
7475

75-
## 分库分表
76-
水平分库、表:为了解决单标数据量过大问题。所以将固定的ID hash之后mod,取若0~N个值,然后将数据划分到不同表中,需要在写入与查询的时候进行ID的路由与统计
76+
## 分区分库分表
77+
分区:把一张表的数据分成N个区块,在逻辑上看最终只是一张表,但底层是由N个物理区块组成的,通过将不同数据按一定规则放到不同的区块中提升表的查询效率。
7778

78-
垂直分库、表:为了解决表的宽度问题,同时还能分别优化每张单表的处理能力。所以将表结构根据数据的活跃度拆分成多个表,把不常用的字段单独放到一个表、把大字段单独放到一个表、把经常使用的字段放到一个表
79+
水平分表:为了解决单标数据量过大(数据量达到千万级别)问题。所以将固定的ID hash之后mod,取若0~N个值,然后将数据划分到不同表中,需要在写入与查询的时候进行ID的路由与统计
7980

81+
垂直分表:为了解决表的宽度问题,同时还能分别优化每张单表的处理能力。所以将表结构根据数据的活跃度拆分成多个表,把不常用的字段单独放到一个表、把大字段单独放到一个表、把经常使用的字段放到一个表
82+
83+
分库:面对高并发的读写访问,当数据库无法承载写操作压力时,不管如何扩展slave服务器,此时都没有意义了。因此数据库进行拆分,从而提高数据库写入能力,这就是分库。
84+
85+
问题:
86+
87+
1. 事务问题。在执行分库之后,由于数据存储到了不同的库上,数据库事务管理出现了困难。如果依赖数据库本身的分布式事务管理功能去执行事务,将付出高昂的性能代价;如果由应用程序去协助控制,形成程序逻辑上的事务,又会造成编程方面的负担。
88+
2. 跨库跨表的join问题。在执行了分库分表之后,难以避免会将原本逻辑关联性很强的数据划分到不同的表、不同的库上,我们无法join位于不同分库的表,也无法join分表粒度不同的表,结果原本一次查询能够完成的业务,可能需要多次查询才能完成。
89+
3. 额外的数据管理负担和数据运算压力。额外的数据管理负担,最显而易见的就是数据的定位问题和数据的增删改查的重复执行问题,这些都可以通过应用程序解决,但必然引起额外的逻辑运算。
8090
### 缓存
8191
对于很多的数据库系统都能够缓存执行计划,对于完全相同的sql, 可以使用已经已经存在的执行计划,从而跳过解析和生成执行计划的过程。MYSQL提供了更为高级的查询结果缓存功能,对于完全相同的SQL (字符串完全相同且大小写敏感) 可以执行返回查询结果
8292

0 commit comments

Comments
 (0)