Mysql-实战
2022-05-29 17:05:38 2 举报AI智能生成
登录查看完整内容
为你推荐
查看更多
MYSQL全知识脑图，偏实战向
作者其他创作
大纲/内容
原子性
一致性
读未提交
读已提交
可重复读
串行化读
隔离性
持久性
基本特性
运行时间较久
操作数据较多
基本定义
数据多，大量阻塞和锁超时
事务回滚需要更多的时间
执行较久，主从架构延迟增高
影响&风险
避免一次处理太多数据，分批处理
SELECT操作请移出事务，一般不需要放进去
解决方案
大事务
关于事务
体系架构
第一范式
第二范式
第三范式
外框
范式化设计
优点
缺点
三范式
反范式化设计
表设计
枚举类型
已知业务小型数，比如年龄
tinyint
已知业务大型数
int
主键自增
bigint
整数型
只占用必要的空间
为啥一般都设置255
使用的是字符长度而不是字节长度
varchar
定长，一般存储固定类型字段，如身份证，MD5
char
字符串
跟时区无关，当系统字段使用，比如创建时间、修改时间
datetime
时间戳，用来存储业务数据，比如下单时间、付款时间
timestamp
yyyy-MM-dd
date
hh:mm:ss
time
时间型
字段类型设计
易理解
可读性强
尽量不要缩写
相同业务统一前缀
命名设计
数据库设计
不要在索引列使用函数、表达式
不要会用不等于和not in
不要在字符串左边使用%模糊查询
不要
关于前缀索引
既要
经常用的优先
区分度高的优先
长度小的优先
关于联合索引
又要
关于覆盖索引
还要
b+树
就是我们写程序的hashMap，你想想你能用map干啥，mysql就能干啥
hash
索引
测试过程中发现页面或者功能慢-查sql
慢查询日志
接入监控-prometheus/druid监控
慢sql
要分批处理，不能一下子全部整上去，每次处理隔个1秒考虑下主从复制
大数据修改-dml
不要改，可以建新表，然后同步，后面直接切到新表
大表结构修改-ddl
left join + rightid is null
关于not in和!=
整一个汇总表，使用unionall 汇总表和count业务表
主键索引包含完整数据，所以整一个小的索引，count索引
大表count
sql
微服务
单库压力太大
分库
垂直分表
按分区键范围，1-100，101-200
按分区键的hash，然后对总分区表数取模
搞一个映射表，先查映射表
水平分表
REDIS
全局唯一ID
分表
分库分表
性能优化
数据量超千万
表数据文件超过10G
条件&定义
很难在短时间过滤出数据
DDL引起的问题
风险
主键
跨分区数据查询统计
时间点的选择
归档的手法
历史数据归档
关于大表
数量
频率
CPU
web应用并发高，业务逻辑简单，选数量
内存
传统盘
便宜、快速、危险
0 N
从库
高速读、简单、安全
1 2
安全、成本适中
5 N+1
贵、高速、安全
10 2N
主库
RAID盘
SSD
NAS
磁盘
宽带
质量
网络IO
硬件环境
操作系统
存储引擎
最大并发连接数
缓存池大小
可以通过调节参数优化
过多的反范式设计(超多列)
过度范式化设计(拆分过细关联太多)
不要使用物理外键约束(逻辑外键程序控制)
scheme
SQL优化
优秀的设计
关于性能
ACID
RedoLog&UndoLog
事务性
共享锁
独占锁
行级锁
并发性较高
存储引擎实现
锁特性
特性
文件小，IO低
sql有函数，会出现主从不一致
直接记录sql语句
statement
数据传输安全
主从复制效率更高
文件大，io高
记录修改信息
row
mixed
binlog
relaylog
服务器层
innodb-undo-log
innodb-redo-log
存储引擎层
mysql日志
架构图
MMM
MHA
高可用架构
Mysql实战
0 条评论
回复 删除
下一页
