| 表 |
- 表中的一行代表了一组值之间的一种联系。一个表就是这种联系的一个集合。数学上，元组（tuple）只是一组值得序列（或列表），在n个值之间的一种联系可用一个n元组表示，就是一个有n个值得元组，对应于表中的一行
- 关系模型中：关系用来指代表，元组用来指代行，属性指代表中的列。
- 对于关系的每个属性，都存在一个允许取值的集合，称为该属性的域。所有关系的所有属性的域都是原子的（automic），即不可再分单元
|
| 空值、缺失值 |
空（null）:表示值未知或不存在 缺失：值存在 |
| 数据库模式 （database schema）
|
数据库的逻辑设计；关于数据库和表的布局及特性的信息。 |
| 数据库实例 （database instance） |
给定时刻数据库中数据的一个快照在关系模型中使用相同的属性将不同关系的元组联系起来 |
| 超键 |
一个或多个属性的集合，这些属性的集合可以在一个关系中唯一地标识一个元组 |
| MySQL的优点 |
- 使用简单
- 开源免费
- 扩展性“好”，在一定阶段扩展性好
- 社区活跃
- 性能可以满足互联网存储和性能需求，离不开硬件支持
|
| MySQL存在的问题 |
- 优化器对复杂SQL支持不好
- 对SQL标准支持不好
- 大规模集群方案不成熟，主要指中间件
- ID生成器，全局自增ID
- 异步逻辑复制，数据安全性问题
- Online DDL
- HA方案不完善
- 备份和恢复方案还是比较复杂，需要依赖外部组件
- 展现给用户信息过少，排查问题困难
- 众多分支，让人难以选择
|
| DBMS类别 |
- 一类为基于共享文件系统的DBMS。包括Access和FileMaker,用于桌面用途，通常不用于高端或更关键的应用
- 另一类为基于客户机-服务器的DBMS。包括MySQL、Oracle等数据库。客户机-服务器应用分为两个不同的部分，服务器部分是负责所有数据访问和处理的一个软，称为数据库服务器上的计算机。与数据文件打交道的只有服务器软件。关于数据、数据添加、删除和数据更新的所有请求都有服务器软件来完成。这些请求或更改来自运行客户机软件的计算机。客户机是与用户打交道的软件。
|
| |
|
| 数据库开发规范 |
数据库开发规范定义：开发规范是针对内部开发的一系列建议或规则, 由DBA制定(如果有DBA的话)。
开发规范本身也包含几部分：基本命名和约束规范，字段设计规范，索引规范，使用规范。 |
| 规范存在意义 |
- 保证线上数据库schema规范
- 减少出问题概率
- 方便自动化管理
- 规范需要长期坚持，对开发和DBA是一个双赢的事情
- 基本命名和约束规范
- 表字符集选择 UTF8 ，如果需要存储 emoj 表情，需要使用
|
| UTF8mb4 (MySQL 5.5.3以后支持) |
- 存储引擎使用InnoDB
- 变长字符串尽量使用varchar varbinary
- 不在数据库中存储图片、文件等
- 单表数据量控制在1亿以下
- 库名、表名、字段名不使用保留字
- 库名、表名、字段名、索引名使用小写字母，以下划线分割 ，需要见名知意
- 库表名不要设计过长，尽可能用最少的字符表达出表的用途
|
| 字段规范 |
- 所有字段均定义为NOT NULL ，除非你真的想存Null
- 字段类型在满足需求条件下越小越好，使用UNSIGNED存储非负整数 ，实际使用时候存储负数场景不多
- 使用TIMESTAMP存储时间
- 使用varchar存储变长字符串 ，当然要注意varchar(M)里的M指的是字符数不是字节数；使
- UNSIGNED INT存储IPv4 地址而不是CHAR(15) ，这种方式只能存储IPv4，存储不了IPv6
- 使用DECIMAL存储精确浮点数，用float有的时候会有问题
- 少用blob text
|
| 关于为什么定义不使用Null的原因: |
1. 浪费存储空间，因为InnoDB需要有额外一个字节存储
2. 表内默认值Null过多会影响优化器选择执行计划 |
| 索引规范 |
- 单个索引字段数不超过5，单表索引数量不超过5，索引设计遵循B+ Tree索引最左前缀匹配原则
- 选择区分度高的列作为索引
- 建立的索引能覆盖80%主要的查询，不求全，解决问题的主要矛盾
- DML和order by和group by字段要建立合适的索引
- 避免索引的隐式转换
- 避免冗余索引
- 关于索引规范，一定要记住索引这个东西是一把双刃剑，在加速读
- 的同时也引入了很多额外的写入和锁，降低写入能力，这也是为什
- 么要控制索引数原因。
|
| SQL类规范 |
- 尽量不使用存储过程、触发器、函数等
- 避免使用大表的JOIN，MySQL优化器对join优化策略过于简单
- 避免在数据库中进行数学运算和其他大量计算任务
- SQL合并，主要是指的DML时候多个value合并，减少和数据库交互
- 合理的分页，尤其大分页
- UPDATE、DELETE语句不使用LIMIT ，容易造成主从不一致
|
| 运维规范主要内容 |
- SQL审核，DDL审核和操作时间，尤其是OnlineDDL
- 高危操作检查，Drop前做好数据备份
- 权限控制和审计
- 日志分析，主要是指的MySQL慢日志和错误日志
- 高可用方案
- 数据备份方案
|
| 目前备份方式的几个纬度： |
- 全量备份 VS 增量备份
- 热备 VS 冷备
- 物理备份 VS 逻辑备份
延时备份
- 全量binlog备份
- 建议方式：
- 热备＋物理备份
- 核心业务：延时备份＋逻辑备份
- 全量binlog备份
|
| 主从延时问题 |
- 原因：一般都会做读写分离，其实从库压力反而比主库大／从库读写压力大非常容易导致延时。
解决方案：
- 首先定位延时瓶颈
- 如果是IO压力，可以通过升级硬件解决，比如替换SSD等
- 如果IO和CPU都不是瓶颈，非常有可能是SQL单线程问题，解决方案可以考虑刚才提到的并行复制方案
- 如果还有问题，可以考虑sharding拆分方案
一个分布式系统做的跟单机系统一样方便，又能扩展，性能又好
分布式系统又必然会面对强一致性所带来的延迟提高的问题，因为网络通信本身比单机内通信代价高很多，这种通信的代价就会直接增加系统单次提交的延迟，延迟提高会导致数据库锁持有时间变长，使得高冲突条件下分布式事务的性能不升反降（具体可了解下Amdahl定律），甚至性能距离单机数据库有明显差距。
努力追求数据库领域的那个圣杯：更快的存取数据，可以按需扩缩以承载更大的访问量和更大的数据量，开发容易，硬件成本低。双11开始和双11结束，我们需要在那之前机器扩容，以及那之后要机器缩容，这些才是DRDS的核心能力。
|