目录
7，原本可以执行很快的sql语句，执行速度却慢很多，什么原因，怎么解决
2，假如非技术人员在从库中进行过了操作，导致主从不同步怎么做？
2，MySQL 的 redo log 和 binlog 区别？
一，mysql基础原理问题
1，一条mysql语句的执行过程
Server层执行sql的步骤为：
- 客户端请求->连接器（验证用户身份，给与权限）
- 查询缓存（存在缓存则直接返回，不存在则执行后续操作）
- 分析器（对sql进行词法分析和语法分析操作）
- 优化器（主要对执行的sql优化选择最优的执行方案）
- 执行器（执行时会先看用户是否有执行权限，有才去使用这个引擎提供的接口）-> 去引擎层获取据返回（如果开启查询缓存则会缓存查询结果）
2，SQL 和 MySQL 的区别
SQL 是一种编程语言
MySQL 是一种软件，它属于关系型数据库的一种，而关系型数据库都是支持 SQL 的，而非关系型数据库有的支持，有的不支持 SQL
3，MySQL数据库存储过程的优点以及概念
概念：存储过程（Stored Procedure）是一组为了完成特定功能的SQL 语句集，使用存储过程的目的是将常用或复杂的工作预先用 SQL 语句写好并用一个指定名称存储起来，这个过程经编译和优化后存储在数据库服务器中，因此称为存储过程。
优点：增强SQL语言的功能和灵活性，封装性，较快的执行速度，减少网络流量，提高数据库的安全性和数据的完整性。
4，关系型和非关系型数据库的区别？
关系型数据库的优点：
容易理解，因为它采用了关系模型来组织数据。
可以保持数据的一致性。
数据更新的开销比较小。
支持复杂查询（带 where 子句的查询）
非关系型数据库（NOSQL）的优点
无需经过 SQL 层的解析，读写效率高。
基于键值对，读写性能很高，易于扩展
可以支持多种类型数据的存储，如图片，文档等等。
扩展（可分为内存性数据库以及文档型数据库，比如 Redis，MongoDB，HBase 等，
适合场景：数据量大高可用的日志系统/地理位置存储系统）。
5，Mysql是如何保证数据不丢失的
只要redolog 和 binlog 保证持久化磁盘就能确保MySQL异常重启后回复数据
在恢复数据时，redolog 状态为 commit 则说明 binlog 也成功，直接恢复数据；如果 redolog 是 prepare，则需要查询对应的 binlog事务是否成功，决定是回滚还是执行。
6，什么是回表操作
如果不是主键索引的查询，，查询索引以外的字段值，索引节点并没有存储它，所有会通过索引节点存储的主键值再去查询一次。这就是回表操作
7，原本可以执行很快的sql语句，执行速度却慢很多，什么原因，怎么解决
原因
1，MySQL本身被堵住了；系统或者网络资源不够
2，sql语句被堵住了；锁表，行锁，导致存储引擎不执行对应的sql语句
3，索引使用不当，没有走索引
4，表中数据的特点导致，走了索引，但回表次数庞大
解决：
1，考虑采用 force index （强制索引）强行选择一个索引
2，Free Space：页中尚未使用的部分，大小不固定。
3，Page Directory：页中某些记录的相对位置，也就是各个槽对应的记录在页面中的地址偏移量。
4，File Trailer：用于检验页是否完整，占固定大小 8 字节。
8，mysql数据库的优化
- 硬件优化：配置千兆网络；做磁盘阵列；使用大内存，主频高的；
- 操作系统优化：已硬件为基础设置tcp最大连接数；设置最大打开文件数；禁用不必要的服务；安装最小化；权限最小化；
- 软件层面：设置not null，避免null值；尽量减少字段宽度；简述表明，不设太多字段；使用枚举或整数代替字符串类型；指定缓冲区大小；以硬件为基础最大mysql最大连接数与最大并行连接数；
9，Mysql的三层架构
- 客户端（client层）
- 服务端（server层） *连接器(管理连接和权限验证)*分析器(验证sql语句)*优化器(优化语句，规定执行流程)*执行器(取到优化器的计划，跟存储引擎交互)
- 存储引擎（引擎层）*innodb：磁盘 *myisam：磁盘 *memory：内存
二，主从
1，主从不同步如何解决的？
1，server_id是否唯一
2，主库的binlog格式或版本与从库不匹配。
3，主库和从库之间网络问题导致数据传输中断。
4，主库和从库之间的时间不同步。
5，主从复制用户权限设置不当。
6，主库上的数据库结构发生改变，从库未能成功应用。
7，主库出现了数据库级别的错误，如数据库崩溃，导致主从复制中断。,
8，查看线程：io出错-网络连通问题-防火墙打开了-对应IP地址改错-端口关闭；
sql出错-数据库结构不一样
2，假如非技术人员在从库中进行过了操作，导致主从不同步怎么做？
- 查看relay-log日志是否存在
- 是否开启防火墙，端口是否关闭
- 查看系统时间是否更改
- Ping主库ip是否断开网络连接
- 是否更改server_id
3，Mysql 主从的原理是什么？
首先从库产生两个线程io线程与sql线程，io线程向主库请求bin-log日志并放到本地中的relay-log中，主库会产生一个log dump线程给从库io线程传输bin-log；
这时sql线程会把relay-log中的日志转换sql语句在从库中执行。
4，mysql主从复制的三种模式
1.异步复制（Asynchronous replication）
MySQL默认的复制即是异步的，主库在执行完客户端提交的事务后会立即将结果返给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题：主如果crash掉了，此时主上已经提交的事务可能并没有传到从上，如果此时，强行将从提升为主，可能导致新主上的数据不完 整。
- 全同步复制（Fully synchronous replication）
指当主库执行完一个事务，所有的从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完该事务才能返回，所以全同步复制的性能必然会收到严重的影响。
3.半同步复制（Semisynchronous replication）
介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay log中才返回给客户端。相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一定程度的延迟，这个延迟最少是一个TCP/IP往返的时间。所以，半同步复制最好在低延时的网络中使用。
5，半同步复制转为异步复制的情况
1，当半同步复制发生超时（由rpl_semi_sync_master_timeout参数控制，默认为10000ms，即10s），会暂时关闭半同步复制，转而使用异步复制，也就是会自动降为异步工作。
2，当master dump线程发送完一个事务 的所有事件之后，如果在 rpl_semi_sync_master_timeout 内，收到了从库的响应， 则主从又重新恢复为半同步复制。
6，mysql的主从形式
- 一主一从
- 互为主从
- 一主多从
- 多主一从
- 联级复制
7，mysql主从同步延时分析
由于binlog是顺序写，从的IO操作是随机的，不是顺序，另一方面，当主库的并发较高时，产生的DML数量超过slave的SQL thread所能处理的速度，或者当slave中有大型query语句产生了锁等待，那么延时就产生了。
解决方案：
1.业务的持久化层的实现采用分库架构，mysql服务可平行扩展，分散压力。
2.单个库读写分离，一主多从，主写从读，分散压力。这样从库压力比主库高，保护主库。
3.服务的基础架构在业务和mysql之间加入memcache或者redis的cache层。降低mysql的读压力。
4.不同业务的mysql物理上放在不同机器，分散压力。
5.使用比主库更好的硬件设备作为slave，mysql压力小，延迟自然会变小。
6.使用更加强劲的硬件设备
8，mysql如何解决慢查询
如果是刻意的慢查询：
开启慢查询sql：set global slow_query_log = 1/on;
关闭慢查询sql：set global slow_query_log = 0/off;解决非刻意慢查询：
- 创建（下推）索引，使用索引来减少查询时间（合理创建）
- 避免where对字段进行null判断
- 避免where中的表达式操作符和or连接条件，导致的全盘扫描
- 排序字段建立索引，相反对于区分度不大的则不用创建索引
三，日志
1，什么是redo log日志
InnoDB存储引擎的redo log（重做日志），redo log（重做日志）是InnoDB存储引擎独有的，它让MySQL拥有了崩溃恢复能力。
比如MySQL实例挂了或宕机了，重启时，InnoDB存储引擎会使用redo log恢复数据，保证数据的持久性与完整性
2，MySQL 的 redo log 和 binlog 区别？
redo log：InnoDB 存储引擎层方面的日志，所以如果你使用的存储引擎不是 InnoDB 的话，那就根本谈不上 redo log。
bin log: MySQL Server 层记录的日志，所以不管是用的什么存储引擎，只要是 MySQL 都是会有 binlog 的存在，在做 MySQL 主从复制的时候，利用的就是 binlog
3，为什么需要 redo log？
redo log 主要用于 MySQL 异常重启后的一种数据恢复手段，确保了数据的一致性。
其实是为了配合 MySQL 的 WAL 机制。因为 MySQL 进行更新操作，为了能够快速响应，所以采用了异步写回磁盘的技术，写入内存后就返回。但是这样，会存在 crash后 内存数据丢失的隐患，而 redo log 具备 crash safe 的能力。
4，mysql中的redo log
1，redolog 是搭配缓冲池、change buffer 使用的，缓冲池的作用是缓存磁盘上的数据页，减少磁盘的IO；change buffer 的作用是将写操作先存在内存中，等到下次需要读取这些操作涉及到的数据页时，就把数据页加载到缓冲池中，然后在缓冲池中更新；
2，事务的持久性是通过redolog实现的（write ahead log（WAL）），即先写日志再写数据；而因为binlog和redolog两种日志属于不同的组件，所以为了保证数据的一致性，要保证binlog和redolog的一致，所以有了二阶段提交的概念。
5，bin log 日志的三种格式：
Statement格式：基于SQL语句的复制((statement-based replication,SBR))
每一条会修改数据的 SQL 都会记录在 binlog 中
优点：不需要记录每一行的变化，减少了binlog日志量，节约了IO，提高性能。
缺点：由于记录的只是执行语句，为了这些语句能在备库上正确运行，还必须记录每条语句在执行的时候的一些相关信息，以保证所有语句能在备库得到和在主库端执行时候相同的结果。
Row格式：Row：基于行的复制。(row-based replication,RBR)
不记录 SQL 语句上下文相关信息，仅保存哪条记录被修改。
优点：binlog 中可以不记录执行的 SQL 语句的上下文相关的信息，仅需要记录那一条记录被修改成什么了。所以rowlevel的日志内容会非常清楚的记录下每一行数据修改的细节。不会出现某些特定情况下的存储过程、或 function、或trigger的调用和触发无法被正确复制的问题。
缺点:可能会产生大量的日志内容。
Mixed格式：混合模式复制。(mixed-based replication,MBR)
实际上就是 Statement 与 Row 的结合。一般的语句修改使用 statment 格式保存 binlog，如一些函数，statement 无法完成主从复制的操作，则采用 row 格式保存 binlog，MySQL 会根据执行的每一条具体的 SQL 语句来区分对待记录的日志形式。
6，binlog的概念是什么，起到什么作用
- binlog 是归档日志（二进制日志），属于 MySQL Server 层的日志。可以实现主从复制和数据恢复两个作用。
- 当需要恢复数据时，可以取出某个时间范围内的 binlog 进行重放恢复。
7，什么是relay log中继日志
中继日志（relay log）只在主从服务器架构的从服务器上存在。从服务器（slave）为了与主服务器(Master)保持一致，要从主服务器读取二进制日志的内容，并且把读取到的信息写入本地的日志文件中，这个从服务器本地的日志文件就叫中继日志
8，中继日志（relay log）的作用
中继日志用于主从服务器架构中，从服务器用来存放主服务器二进制日志内容的一个中间文件。从服务器通过读取中继日志的内容，来同步主服务器上的操作。
中继日志是连接mastert(主服务器)和slave(从服务器)的信息，它是复制的核心，I/O线程将来自master的binlog存储到中继日志中，中继日志充当缓冲，这样master不必等待slave执行完成就可以发送下一个binlog。
四，事务
1，事务的特性
通过将一组操作组成一个操作单元，执行时，要么全部成功，要么全部失败的单元。
MYSQL中只有INNODB和BDB类型的数据表才能支持事务处理。
原子性：（Autmic）事务必须是原子工作单元，不能被分隔的，事务中的操作要么全部执行，要么全都不执行，不能只完成部分操作。
一致性：（Consistency）事务开始之前，数据库处于一致性的状态；事务结束后，数据库必须仍处于一致性状态。数据库一致性的定义是由用户负责的。例如，在银行转账中，用户可以定义转账前后两个账户金额之和保持不变。
隔离性：（Isolation）一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对并发的其他事务是隔离的，并发执行的各个事务之间不能互相干扰，这些通过锁来实现。
持久性：（Durability）指一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。
五，死锁
锁的概念：当客户端操作表（记录）时，为了保证操作的隔离性（多个客户端操作不能互相影响），通过加锁来处理。
死锁的本质是一种僵持状态，之所以出现死锁，是因为多个线程对资源的强占，你要我的，我也要你的，两人堵在路上谁都不让，所以死锁了。
2089
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
