MySQL数据库知识点整合

事务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秒