1.存储引擎
show engines;
只有InnoDB 支持事务
两者的对比：
1.1是否支持行级锁 : MyISAM 只有表级锁(table-level locking)，而InnoDB 支持行级锁(row-level locking)和表级锁,默认为行级锁。
1.2是否支持事务和崩溃后的安全恢复： MyISAM 强调的是性能，每次查询具有原子性,其执行速度比InnoDB类型更快，但是不提供事务支持。但是InnoDB 提供事务支持事务，外部键等高级数据库功能。 具有事务(commit)、回滚(rollback)和崩溃修复能力(crash recovery capabilities)的事务安全(transaction-safe (ACID compliant))型表。
1.3是否支持外键： MyISAM不支持，而InnoDB支持。
1.4是否支持MVCC ：仅 InnoDB 支持。应对高并发事务, MVCC比单纯的加锁更高效;MVCC只在 READ COMMITTED 和 REPEATABLE READ 两个隔离级别下工作;MVCC可以使用 乐观(optimistic)锁 和 悲观(pessimistic)锁来实现;各数据库中MVCC实现并不统一。推荐阅读：MySQL-InnoDB-MVCC多版本并发控制
2.表级锁和行级锁
行级锁:开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。
表级锁:开销小，加锁快；不会出现死锁；锁定粒度大，发出锁冲突的概率最高，并发度最低。
3.什么是事务?
事务是逻辑上的一组操作，要么都执行，要么都不执行。
事务的四大特性(ACID)
3.1 原子性（Atomicity）： 事务是最小的执行单位，不允许分割。事务的原子性确保动作要么全部完成，要么完全不起作用；
3.2一致性（Consistency）： 执行事务前后，数据保持一致，多个事务对同一个数据读取的结果是相同的；
3.3隔离性（Isolation）： 并发访问数据库时，一个用户的事务不被其他事务所干扰，各并发事务之间数据库是独立的；
3.4持久性（Durability）： 一个事务被提交之后。它对数据库中数据的改变是持久的，即使数据库发生故障也不应该对其有任何影响。
并发事务带来哪些问题?
脏读（Dirty read）:一个正在做修改操作,另一个进行了读
丢失修改（Lost to modify）:两个事务都修改同一条数据
不可重复读（Unrepeatableread）:一个事务多次读一个数据,另一个事务在多次读之间修改了这条数据,多次读的结果不一致
幻读（Phantom read）:个事务多次读一个数据,另一个事务在多次读之间添加了一条数据,多次读的结果不一致
事务隔离级别有哪些?MySQL的默认隔离级别是?
SQL 标准定义了四个隔离级别：
READ-UNCOMMITTED(读取未提交)：最低的隔离级别,允许读取尚未完成的数据,，可能会导致脏读、幻读或不可重复读。
READ-COMMITTED(读取已提交)：允许读取并发事务已经提交的数据，可以阻止脏读，但是幻读或不可重复读仍有可能发生。
REPEATABLE-READ(可重复读)： 对同一字段的多次读取结果都是一致的，除非数据是被本身事务自己所修改，可以阻止脏读和不可重复读，但幻读仍有可能发生。
SERIALIZABLE(可串行化)： 最高的隔离级别，完全服从ACID的隔离级别。所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。
MySQL InnoDB 存储引擎的默认支持的隔离级别是 REPEATABLE-READ（可重读）。我们可以通过SELECT @@tx_isolation;命令来查看
4.大表优化
当MySQL单表记录数过大时，数据库的CRUD性能会明显下降，一些常见的优化措施如下：
1. 限定数据的范围:务必禁止不带任何限制数据范围条件的查询语句。
2. 读/写分离:经典的数据库拆分方案，主库负责写，从库负责读；
3.垂直分区:根据数据库里面数据表的相关性进行拆分。
垂直拆分的优点： 可以使得列数据变小，在查询时减少读取的Block数，减少I/O次数。此外，垂直分区可以简化表的结构，易于维护。
垂直拆分的缺点： 主键会出现冗余，需要管理冗余列，并会引起Join操作，可以通过在应用层进行Join来解决。此外，垂直分区会让事务变得更加复杂；
4. 水平分区:将一个表的数据,分配到相同多个表中,一般不建议这么做
什么是数据库连接池?为什么需要数据库连接池?
数据库连接本质就是一个 socket 的连接
数据库服务端还要维护一些缓存和用户权限信息之类的 所以占用了一些内存。我们可以把数据库连接池是看做是维护的数据库连接的缓存，
连接池还减少了用户必须等待建立与数据库的连接的时间。
分库分表之后,id 主键如何处理？
生成全局 id 有下面这几种方式：
UUID：不适合作为主键，因为太长了，并且无序不可读，查询效率低。比较适合用于生成唯一的名字的标示比如文件的名字。
数据库自增 id : 两台数据库分别设置不同步长，生成不重复ID的策略来实现高可用。这种方式生成的 id 有序，但是需要独立部署数据库实例，成本高，还会有性能瓶颈。
利用 redis 生成 id : 性能比较好，灵活方便，不依赖于数据库。但是，引入了新的组件造成系统更加复杂，可用性降低，编码更加复杂，增加了系统成本。
Twitter的snowflake算法 ：Github 地址：https://github.com/twitter-archive/snowflake。
美团的Leaf分布式ID生成系统 ：Leaf 是美团开源的分布式ID生成器，能保证全局唯一性、趋势递增、单调递增、信息安全，里面也提到了几种分布式方案的对比，但也需要依赖关系数据库、Zookeeper等中间件。感觉还不错。美团技术团队的一篇文章：https://tech.meituan.com/2017/04/21/mt-leaf.html 。
MySQL 基础架构分析
一 执行流程
连接器： 身份认证和权限相关(登录 MySQL 的时候)。
查询缓存: 执行查询语句的时候，会先查询缓存（MySQL 8.0 版本后移除，因为这个功能不太实用）。
分析器: 没有命中缓存的话，SQL 语句就会经过分析器，分析器说白了就是要先看你的 SQL 语句要干嘛，再检查你的 SQL 语句语法是否正确。
优化器： 按照 MySQL 认为最优的方案去执行。
执行器: 执行语句，然后从存储引擎返回数据。
简单来说 MySQL 主要分为 Server 层和存储引擎层：
Server 层：主要包括连接器、查询缓存、分析器、优化器、执行器等，所有跨存储引擎的功能都在这一层实现，比如存储过程、触发器、视图，函数等，还有一个通用的日志模块 binglog 日志模块。
存储引擎： 主要负责数据的存储和读取，采用可以替换的插件式架构，支持 InnoDB、MyISAM、Memory 等多个存储引擎，其中 InnoDB 引擎有自有的日志模块 redolog 模块。现在最常用的存储引擎是 InnoDB，它从 MySQL 5.5.5 版本开始就被当做默认存储引擎了
二 语句分析
2.1 查询语句
2.2 更新语句
数据库命令规范
所有数据库对象名称必须使用小写字母并用下划线分割
所有数据库对象名称禁止使用 MySQL 保留关键字（如果表名中包含关键字查询时，需要将其用单引号括起来）
数据库对象的命名要能做到见名识意，并且最后不要超过 32 个字符
临时库表必须以 tmp_为前缀并以日期为后缀，备份表必须以 bak_为前缀并以日期 (时间戳) 为后缀
所有存储相同数据的列名和列类型必须一致（一般作为关联列，如果查询时关联列类型不一致会自动进行数据类型隐式转换，会造成列上的索引失效，导致查询效率降低）
数据库基本设计规范
1. 所有表必须使用 Innodb 存储引擎
2. 数据库和表的字符集统一使用 UTF8
如果数据库中有存储 emoji 表情的需要，字符集需要采用 utf8mb4 字符集。
3. 所有表和字段都需要添加注释
4. 尽量控制单表数据量的大小,建议控制在 500 万以内。
5. 谨慎使用 MySQL 分区表
6.尽量做到冷热数据分离,减小表的宽度
7. 禁止在表中建立预留字段
8. 禁止在数据库中存储图片,文件等大的二进制数据
9. 禁止在线上做数据库压力测试
10. 禁止从开发环境,测试环境直接连接生成环境数据库
数据库字段设计规范
1. 优先选择符合存储需要的最小的数据类型
IP地址保存时,可以先通过inet_ntoa保存成整数
2. 避免使用 TEXT,BLOB 数据类型，最常见的 TEXT 类型可以存储 64k 的数据
3. 避免使用 ENUM 类型 修改ENUM类型字段,代价很昂贵
4. 尽可能把所有列定义为 NOT NULL
5. 使用 TIMESTAMP(4 个字节) 或 DATETIME 类型 (8 个字节) 存储时间
6. 同财务相关的金额类数据必须使用 decimal 类型
索引设计规范
1. 限制每张表上的索引数量,建议单张表索引不超过 5 个
2. 禁止给表中的每一列都建立单独的索引
3. 每个 Innodb 表必须有个主键
4. 常见索引列建议
出现在 SELECT、UPDATE、DELETE 语句的 WHERE 从句中的列
包含在 ORDER BY、GROUP BY、DISTINCT 中的字段
并不要将符合 1 和 2 中的字段的列都建立一个索引， 通常将 1、2 中的字段建立联合索引效果更好
多表 join 的关联列
5.如何选择索引列的顺序
区分度最高的放在联合索引的最左侧（区分度=列中不同值的数量/列的总行数）
尽量把字段长度小的列放在联合索引的最左侧（因为字段长度越小，一页能存储的数据量越大，IO 性能也就越好）
使用最频繁的列放到联合索引的左侧（这样可以比较少的建立一些索引）
6.避免建立冗余索引和重复索引（增加了查询优化器生成执行计划的时间）
重复索引示例：primary key(id)、index(id)、unique index(id)
冗余索引示例：index(a,b,c)、index(a,b)、index(a)
数据库 SQL 开发规范
1. 建议使用预编译语句进行数据库操作
2. 避免数据类型的隐式转换
3. 充分利用表上已经存在的索引
4. 数据库设计时，应该要对以后扩展进行考虑
5. 程序连接不同的数据库使用不同的账号，进制跨库查询
6. 禁止使用 SELECT * 必须使用 SELECT <字段列表> 查询
7. 禁止使用不含字段列表的 INSERT 语句
8. 避免使用子查询，可以把子查询优化为 join 操作
9. 避免使用 JOIN 关联太多的表 MySQL 最多允许关联 61 个表，建议不超过 5 个。
10. 减少同数据库的交互次数
11. 对应同一列进行 or 判断时，使用 in 代替 or
12. 禁止使用 order by rand() 进行随机排序
13. WHERE 从句中禁止对列进行函数转换和计算
14. 在明显不会有重复值时使用 UNION ALL 而不是 UNION
15. 拆分复杂的大 SQL 为多个小 SQL
数据库操作行为规范
1. 超 100 万行的批量写 (UPDATE,DELETE,INSERT) 操作,要分批多次进行操作
2. 对于大表使用 pt-online-schema-change 修改表结构
3. 禁止为程序使用的账号赋予 super 权限
4. 对于程序连接数据库账号,遵循权限最小原则
