起因：在工作中常常要用到mysql，平常只是对数据库crud，并没有认真的了解过她，sql语句也只是会一些最基本的，和常用的，一些不常用的都要去网上百度，即决定学习一下mysql，来了解她，虽然开发很多都是黑盒，但追本溯源总是我们想要的。
1.线上数据备份恢复策略略实施
1.1.备份流程的设计
- 备份工具
- 备份方式
1、考虑数据量：做备份工具的选型
-
数据量较小的情况下：mysqldump逻辑备份，导出的是SQL
-
如果我们数据量非常大：xtrabackup
2、考虑我们的时间点补偿 -
从上一个全量备份时点到现在这个阶段的数据
-
Binlog：statement，row，mixed
3、做我们的备份⽅方案
- 全量备份 crontab -e （cron语法）定时执行备份脚本，时间选择在业务量小的时点（记录我们的备份的position）
- 增量：binlog（statement和mixed模式，我们的SQL都是线性且可执行的）
- statement和mixed的增量适用于正常情况下数据库无法打开使用或数据文件损坏
- row特别适合单表数据异常恢复
- 一定要确保线上不会出现直接执行的SQL
1.2.数据恢复流程
案例1：statement，mixed
student（id,score）：4点100行数据，第二天8点的时候更新一条score，所有人score全变成90
- mysqldump：可以去到⽂文件⾥里里找到student表把insert全部拿出来
- xtrabackup：先要恢复到⼀一个新数据库
- 把4-8点间所有涉及这个student表的DML除select外，还最后我出错的这个SQL外，所有SQL全部拿出来
- 按照这个顺序：4点student所有数据执行->执行Binlog里的SQL
案例例2：row
- 找到position，通过mysqlbinlog导出变更的数据，只能用代码去调整他的记录变更为恢复的SQL
- 如果数据库不可用需要恢复
文件转移到新数据库：物理备份如果数据文件无法启动
如果数据文件无法启动
mysqldump全量量+row模式下的增量量（调整起来就⾮非常费劲）
在备份的基础上，如果条件允许⼀定要做主从HA
- 主机：row
- 从机：statement
1.3. statement模式下数据恢复
自己drop database一次，并通过binlog进行恢复 恢复的过程也记录进binlog了 是否需要记录？
2.MySQL索引优化
- SQL及索引：⾼高质量量的SQL，避免索引失效
- 数据库表结构：范式，⾄至少要符合3NF
- 系统配置MySQL，Linux
- 硬件
2.1.Explain执行计划分析
explain的用法
explain select * from employee where age=40 and name='张飞'
explain的作用
- 查看表的读取顺序
- 读取操作类型
- 哪些索引可用
- 表之间关联
- 每张表有哪些索引被优化器执行
type
- system
- const
- eq_ref
- ref
- range
- index
- ALL
查询的效果从上到下越来越差
2.2.索引命中策略分析
- 最左匹配原则
- 在索引字段上加入函数：不走索引
- is null/is not null：不走索引
- 覆盖索引：key-value都在索引⾥里里，如果select columns直接使用的是索引列就直接使用覆盖索引
- 只要索引条件和or挨着：就用不上
- != / <> ：是否能应用索引
2.3.索引分析总结
优势：
1、提高查询速度
2、表连接的时候，加速连接
3、保证数据唯一：唯一索引
劣势
1、修改和增加数据时会提升开销
2、索引还会占⽤用物理理空间
3、在进行大量量的insert或update、delete时，速度会变慢
适合建立索引
1、数据差异化较大
2、频繁查询的列，where条件里经常用到的
3、常用的表关联字段
4、查询中统计或分组的字段
不适合的
1、记录值特别少
2、值变化特别小，重复率高
3、经常增删改的表
2.4.数据库出现问题后如何死而不僵
1mysql> show processlist;
2mysql> kill pid;
不要以为每天把功能完成了就行了，这种思想是要不得的，互勉~！
网友评论