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