事务ACID是什么
Mysql事务的四大特性是指
原子性（Atomicity）： 事务是不可分割的最小工作单元，整个操作要么全部成功，要么全部失败，一般就是通过commit和rollback来控制。
一致性（Consistency）:数据库总能从一个一致性的状态转换到另一个一致性的状态，只要有任何一方发生异常就不会成功提交事务。
隔离性（Isolation）: 一个事务相对于另一个事务是隔离的，一个事务所做的修改是在最终提交以前，对其他事务是不可见的。
持久性（Durability）:一旦事务提交，则其所做的修改就会永久保存到数据库中。此时即使系统崩溃，修改的数据也不会丢失。
解析脏读、不可重复读、幻读
脏读: 事务中的数据修改即使没有提交，其他事务也能看见，事务可以读到未提交的数据称为脏读。（A事务修改了数据单没有提交，但B事务却读到了数据，这就称为脏读）
不可重复读: 同个事务前后多次读取，不能读到相同的数据内容，中间另一个事务也操作了该同一数据。（A事务第一次读取数据xx，之后B事务对数据xx进行了修改，A事务再次读取数据时并不能读到数据xx，这就称为不可重复读）
幻读：当某个事务在读取某个范围内的记录时，另外一个事务又在该范围内插入了新的记录，当之前的事务再次读取该范围的记录时，发现两次不一样，产生幻读。
幻读和不可重复读的区别是：前者是一个范围，后者是本身，从总的结果来看, 两者都表现为两次读取的结果不一致
事务的隔离级别由低到高列举
事务的隔离级别越高，事务越安全，同时并发能力越差。
Read Uncommitted(未提交读，读取未提交内容)
事务中的修改即使没有提交，其他事务也能看见，事务可以读到未提交的数据称为脏读，也存在不可重复读、幻读问题。
Read Committed(提交读，读取提交内容)
一个事务开始后只能看见已经提交的事务所做的修改，在事务中执行两次同样的查询可能得到不一样的结果，也叫做不可重复读(前后多次读取，不能读到相同的数据内容)，也存幻读问题。
Repeatable Read(可重复读,mysql默认的事务隔离级别)
解决脏读、不可重复读的问题，存在幻读的问题，使用 MMVC机制，实现可重复读。 幻读问题：MySQL的InnoDB引擎通过MVCC自动帮我们解决,即多版本并发控制。
Serializable(可串行化)
解决脏读、不可重复读、幻读，可保证事务安全，但强制所有事务串行执行，所以并发效率低。
Mysql常见的存储引擎介绍
常见的存储引擎：InnoDB、MyISAM、MEMORY、MERGE、ARCHIVE、CSV...
一般比较常用的有InnoDB、MyISAM
MySQL 5.5以上的版本默认是InnoDB，5.5之前默认存储引擎是MyISAM
Mysql的存储引擎InnoDB&MyISAM区别和选择问题
| 区别项 | InnoDB | MyISAM |
|---|---|---|
| 事务 | 支持 | 不支持 |
| 锁粒度 | 行锁，适合高并发 | 表锁，不适合高并发 |
| 是否默认 | 默认 | 非默认 |
| 支持外键 | 支持外键 | 不支持 |
| 适合场景 | 读写均衡,写大于读场景，需要事务 | 读多写少场景，不需要事务 |
| 全文索引 | 不支持，可以通过插件实现, 更多使用ElasticSearch | 支持全文索引 |
MySQL的功能索引
| 索引名称 | 特点 | 创建语句 |
|---|---|---|
| 普通索引 | 最基本的索引,仅加速查询 | CREATE INDEX idx_name ON table_name(filed_name) |
| 唯一索引 | 加速查询，列值唯一，允许为空；组合索引则列值的组合必须唯一 | CREATE UNIQUE INDEX idx_name ON table_name(filed_name_1,filed_name_2) |
| 主键索引 | 加速查询，列值唯一，一个表只有1个，不允许有空值 | ALTER TABLE table_name ADD PRIMARY KEY ( filed_name ) |
| 组合索引 | 加速查询，多条件组合查询 | CREATE INDEX idx_name ON table_name(filed_name_1,filed_name_2); |
| 覆盖索引 | 索引包含所需要的值，不需要“回表”查询，比如查询 两个字段，刚好是 组合索引 的两个字段 | |
| 全文索引 | 对内容进行分词搜索，仅可用于Myisam， 更多用ElasticSearch做搜索 | ALTER TABLE table_name ADD FULLTEXT ( filed_name ) |
对比索引优缺点以及使用注意点
考虑点：结合实际的业务场景，在哪些字段上创建索引，创建什么类型的索引。
索引好处：
快速定位到表的位置，减少服务器扫描的数据；
有些索引存储了实际的值，特定情况下只要使用索引就能完成查询。
索引缺点：
索引会浪费磁盘空间，不要创建非必要的索引；
插入、更新、删除需要维护索引，带来额外的开销；
索引过多，修改表的时候重构索引性能差。
索引优化实践
- 前缀索引，特别是TEXT和BLOG类型的字段，只检索前面几个字符，提高检索速度
- 尽量使用数据量少的索引，索引值过长查询速度会受到影响
- 选择合适的索引列顺序
- 内容变动少，且查询频繁，可以建立多几个索引
- 内容变动频繁，谨慎创建索引
- 根据业务创建适合的索引类型，比如某个字段常用来做查询条件，则为这个字段建立索引提高查询速度
- 组合索引选择业务查询最相关的字段
数据库查询指令的执行顺序
- from 从哪个表查询
- where 初步过滤条件
- group by 过滤后进行分组[重点]
- having对分组后的数据进行二次过滤[重点]
- select 查看哪些结果字段
- order by 按照怎样的顺序进行排序返回[重点]
MySQL中varchar和char的区别
| 对比项 | char(16) | varchar(16) |
|---|---|---|
| 长度特点 | 长度固定，存储字符 | 长度可变，存储字符 |
| 长度不足情况 | 插入的长度小于定义长度时，则用空格填充 | 小于定义长度时，按实际插入长度存储 |
| 性能 | 存取速度比varchar快得多 | 存取速度比char慢得多 |
| 使用场景 | 适合存储很短的,固定长度的字符串,如手机号，MD5值等 | 适合用在长度不固定场景，如收货地址，邮箱地址等 |
MySQL中datetime和timestamp的区别
| 类型 | 占据字节 | 范围 | 时区问题 |
|---|---|---|---|
| datetime | 8 字节 | 1000-01-01 00:00:00到 9999-12-31 23:59:59 | 存储与时区无关，不会发生改变 |
| timestamp | 4 字节 | 1970-01-01 00:00:01 到 2038-01-19 11:14:07 | 存储的是与时区有关，随数据库的时区而发生改变 |
为什么timestamp只能到2038年？
MySQL的timestamp类型是4个字节，最大值是2的31次方减1，结果是2147483647，转换成北京时间就是2038-01-19 11:14:07
针对大数据量sql分页优化思路
现象：千万级别数据，比如数据流水、日志记录等，数据库正常的深度分页会很慢。慢的原因：select * from product limit N,M
MySQL执行此类SQL时需要先扫描到N行，然后再去取M行,N越大,MySQL扫描的记录数越多，SQL的性能就会越差。
优化方式：
1、后端、前端缓存；
2、使用ElasticSearch分页搜索；
3、合理使用 mysql 查询缓存，覆盖索引进行查询分页；
select title,cateory from product limit 1000000,100
4、如果id是自增且不存在中间删除数据，使用子查询优化，定位偏移位置的 id；
select * from oper_log where type='BUY' limit 1000000,100; //5.秒
select id from oper_log where type='BUY' limit 1000000,1; // 0.4秒
select * from oper_log where type='BUY' and id>=(select id from oper_log where type='BUY' limit 1000000,1) limit 100; //0.8秒
