mysql

Author: xiaomeng79

02数据存取/1mysql/0目录.md

@@ -6,4 +6,9 @@
 
 3. [数据同步](./3数据同步.md)
 
-4. [日志](./4日志.md)
+4. [日志](./4日志.md)
+
+5. [Innodb和myisam区别](./5Innodb和myisam区别.md)
+
+
+

02数据存取/1mysql/5Innodb和myisam区别.md

@@ -0,0 +1,27 @@
+## Innodb myisam
+
+[Innodb](https://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651961428&idx=1&sn=31a9eb967941d888fbd4bb2112e9602b&chksm=bd2d0d888a5a849e7ebaa7756a8bc1b3d4e2f493f3a76383fc80f7e9ce7657e4ed2f6c01777d&scene=21#wechat_redirect)
+
+- Count(*)
+
+MyISAM会直接存储总行数，InnoDB则不会，需要按行扫描,只有查询全表的总行数，MyISAM才会直接返回结果，当加了where条件后，两种存储引擎的处理方式类似
+
+- 全文索引
+
+MyISAM支持全文索引，InnoDB5.6之前不支持全文索引,不管哪种存储引擎，在数据量大并发量大的情况下,而要使用《[索引外置](https://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651959917&idx=1&sn=8faeae7419a756b0c355af2b30c255df&chksm=bd2d07b18a5a8ea75f16f7e98ea897c7e7f47a0441c64bdaef8445a2100e0bdd2a7de99786c0&scene=21#wechat_redirect)》的架构设计方法
+
+- 事务
+
+MyISAM不支持事务，InnoDB支持事务,事务是选择InnoDB非常诱人的原因之一，它提供了commit，rollback，崩溃修复等能力,在系统异常崩溃时，MyISAM有一定几率造成文件损坏，这是非常烦的。但是，事务也非常耗性能，会影响吞吐量，建议只对一致性要求较高的业务使用复杂事务
+
+- 外键
+
+MyISAM不支持外键，InnoDB支持外键,不管哪种存储引擎，在数据量大并发量大的情况下，都不应该使用外键，而建议由应用程序保证完整性。
+
+- 关于行锁与表锁
+
+MyISAM只支持表锁，InnoDB可以支持行锁,InnoDB：细粒度行锁，在数据量大，并发量高时，性能比较优异
+
+>| 注意: InnoDB的行锁是实现在索引上的，而不是锁在物理行记录上。潜台词是，如果访问没有命中索引，也无法使用行锁，将要退化为表锁
+
+

02数据存取/1mysql/6mysql设计规范.md

@@ -0,0 +1,49 @@
+## Mysql设计规范
+
+[原文](https://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651961030&idx=1&sn=73a04dabca409c1557e752382d777181&chksm=bd2d031a8a5a8a0c6f7b58b79ae8933dfefbd840dfb5d34a5c708ab63e6decbbc1b13533ebc8&scene=21#wechat_redirect)
+
+1. 基础规范
+    - 表存储引擎必须使用InnoDB
+    - 表字符集默认使用utf8，必要时候使用utf8mb4 *(1）通用，无乱码风险，汉字3字节，英文1字节,（2）utf8mb4是utf8的超集，有存储4字节例如表情符号时，使用它*
+    - 禁止使用存储过程，视图，触发器，Event *1）对数据库性能影响较大，互联网业务，能让站点层和服务层干的事情，不要交到数据库层,2）调试，排错，迁移都比较困难，扩展性较差*
+    - 禁止在数据库中存储大文件，例如照片，可以将大文件存储在对象存储系统，数据库中存储路径
+    - 禁止在线上环境做数据库压力测试
+    - 测试，开发，线上数据库环境必须隔离
+2. 命名规范
+    - 库名，表名，列名必须用小写，采用下划线分隔
+    - 库名，表名，列名必须见名知义，长度不要超过32字符
+    - 库备份必须以bak为前缀，以日期为后缀
+    - 从库必须以-s为后缀
+    - 备库必须以-ss为后缀
+3. 表设计规范
+    - 单实例表个数必须控制在2000个以内
+    - 单表分表个数必须控制在1024个以内
+    - 表必须有主键，推荐使用UNSIGNED整数为主键 *1)删除无主键的表，如果是row模式的主从架构，从库会挂住,2)B+聚簇索引*
+    - 禁止使用外键，如果要保证完整性，应由应用程式实现 *外键使得表之间相互耦合，影响update/delete等SQL性能，有可能造成死锁，高并发情况下容易成为数据库瓶颈*
+    - 建议将大字段，访问频度低的字段拆分到单独的表中存储，分离冷热数据
+4. 列设计规范
+    - 根据业务区分使用tinyint/int/bigint，分别会占用1/4/8字节
+    - 根据业务区分使用char/varchar *1）字段长度固定，或者长度近似的业务场景，适合使用char，能够减少碎片，查询性能高,2）字段长度相差较大，或者更新较少的业务场景，适合使用varchar，能够减少空间*
+    - 根据业务区分使用datetime/timestamp *前者占用5个字节，后者占用4个字节，存储年使用YEAR，存储日期使用DATE，存储时间使用datetime*
+    - 必须把字段定义为NOT NULL并设默认值 *NULL的列使用索引，索引统计，值都更加复杂，MySQL更难优化,2）NULL需要更多的存储空间,3）NULL只能采用IS NULL或者IS NOT NULL，而在=/!=/in/not in时有大坑*
+    - 使用INT UNSIGNED存储IPv4，不要用char(15)
+    - 使用varchar(20)存储手机号，不要使用整数 *1）牵扯到国家代号，可能出现+/-/()等字符，例如+86,2）手机号不会用来做数学运算,3）varchar可以模糊查询，例如like ‘138%’*
+    - 使用TINYINT来代替ENUM *ENUM增加新值要进行DDL操作*
+5. 索引规范
+    - 唯一索引使用uniq_[字段名]来命名
+    - 非唯一索引使用idx_[字段名]来命名
+    - 单张表索引数量建议控制在5个以内 *太多索引会影响写性能,异常复杂的查询需求，可以选择ES*
+    - 组合索引字段数不建议超过5个 
+    - 不建议在频繁更新的字段上建立索引
+    - 非必要不要进行JOIN查询，如果要进行JOIN查询，被JOIN的字段必须类型相同，并建立索引
+    - 理解组合索引最左前缀原则，避免重复建设索引，如果建立了(a,b,c)，相当于建立了(a), (a,b), (a,b,c)
+6. SQL规范
+    - 禁止使用select *，只获取必要字段 *1）select *会增加cpu/io/内存/带宽的消耗,3）指定字段查询，在表结构变更时，能保证对应用程序无影响*
+    - insert必须指定字段，禁止使用insert into T values()
+    - 隐式类型转换会使索引失效，导致全表扫描
+    - 禁止在where条件列使用函数或者表达式 *导致不能命中索引，全表扫描*
+    - 禁止负向查询以及%开头的模糊查询 *致不能命中索引，全表扫描*
+    - 禁止大表JOIN和子查询
+    - 同一个字段上的OR必须改写问IN，IN的值必须少于50个
+    - 应用程序必须捕获SQL异常 *方便定位线上问题*
+    

02数据存取/1mysql/7数据库垂直拆分.md

@@ -0,0 +1,50 @@
+## 数据库垂直拆分
+
+### 分库分表
+把一个很大的库（表）的数据分到几个库（表）中，每个库（表）的结构都相同
+
+### mysql的分区表
+所有数据还在一个表中，但物理存储根据一定的规则放在不同的文件中。这个是mysql支持的功能，业务rd代码无需改动。
+
+为什么使用的少?
+1. 分区表，分区键设计不太灵活，如果不走分区键，很容易出现全表锁
+2. 一旦数据量并发量上来，如果在分区表实施关联，就是一个灾难
+3. 自己分库分表，自己掌控业务场景与访问模式，可控
+
+### 垂直切分的依据是什么
+1. 将长度较短，访问频率较高的属性尽量放在一个表里，这个表暂且称为主表
+2. 将字段较长，访问频率较低的属性尽量放在一个表里，这个表暂且称为扩展表
+3. 如果1和2都满足,经常一起访问的属性，也可以放在一个表里
+
+### 数据量大
+数据量并发量比较大时，数据库的上层都会有一个服务层。需要注意的是，当应用方需要同时访问主表和扩展表中的属性时，服务层不要使用join来连表访问，而应该分两次进行查询
+
+原因:
+1. join更消损耗数据库性能
+2. join会让base表和ext表耦合在一起（必须在一个数据库实例上），不利于数据量大时拆分到不同的数据库实例上（机器上）。毕竟减少数据量，提升性能才是垂直拆分的初衷
+
+### 为什么要这么这么拆分
+为何要将字段短，访问频率高的属性放到一个表内？为何这么垂直拆分可以提升性能？因为：
+1. 数据库有自己的内存buffer，会将磁盘上的数据load到内存buffer里（暂且理解为进程内缓存吧）
+2. **内存buffer缓存数据是以row为单位的**
+3. 在内存有限的情况下，在数据库内存buffer里**缓存短row，就能缓存更多的数据**
+4. 在数据库内存buffer里缓存访问频率高的row，就能提升缓存命中率，减少磁盘的访问
+   
+### 总结
+1. 水平拆分和垂直拆分都是降低数据量大小，提升数据库性能的常见手段
+2. 流量大，数据量大时，数据访问要有service层，并且service层不要通过join来获取主表和扩展表的属性
+3. 垂直拆分的依据，尽量把长度较短，访问频率较高的属性放在主表里
+
+### 高并发在线表结构变更
+1. 新表+触发器+迁移数据+rename  
+2. 拓展表,但是不要join,高并发下,上层提供服务层,进行数据聚合
+3. 
+
+不可选方案:
+1. alter table *需要锁表,服务不可用*
+2. 通过增加表的方式扩展，通过外键join来查询 *大数据高并发情况下，join性能较差*
+3. 通过增加表的方式扩展，通过视图来对外 *同上*
+
+### mysql常见的水平切分方式有哪些？
+- 分库分表
+- 分区表

02数据存取/1mysql/8DB主从一致性架构优化.md

@@ -0,0 +1,30 @@
+## DB主从一致性架构优化
+
+[原文](https://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651959442&idx=1&sn=feb8ff75385d8031386e120ef3535329&scene=21#wechat_redirect)
+### 为什么需要优化
+从库单进程执行reloy-log,和通讯网络,由于主从延时导致读取到旧数据
+
+### 怎么优化
+
+1. 半同步复制
+    - 系统先对DB-master进行了一个写操作，写主库
+    - 等主从同步完成，写主库的请求才返回
+    - 读从库，读到最新的数据
+优点：利用数据库原生功能，比较简单 缺点：主库的写请求时延会增长，吞吐量会降低
+
+2. 强制读主库
+优点：“一致性”上不需要进行系统改造 缺点：只能通过cache来提升系统的读性能，这里要进行系统改造
+
+3. 数据库中间件
+    - 所有的读写都走数据库中间件，通常情况下，写请求路由到主库，读请求路由到从库
+    - 记录所有路由到写库的key，在经验主从同步时间窗口内（假设是500ms），如果有读请求访问中间件，此时有可能从库还是旧数据，就把这个key上的读请求路由到主库
+    - 经验主从同步时间过完后，对应key的读请求继续路由到从库
+优点：能保证绝对一致   缺点：数据库中间件的成本比较高
+
+4. 缓存记录写key法
+    - 将某个库上的某个key要发生写操作，记录在cache里，并设置“经验主从同步时间”的cache超时时间，例如500ms
+    - 修改数据库
+优点：相对数据库中间件，成本较低   缺点：为了保证“一致性”，引入了一个cache组件，并且读写数据库时都多了一步cache操作
+
+
+    

16架构/000常见设计.md

@@ -0,0 +1,3 @@
+## 常见设计
+
+1. [商品SKU设计](https://blog.csdn.net/wwwdc1012/article/details/71774280/)