旅游网网站建设的管理口碑营销的前提及好处有哪些
web/
2025/10/2 5:48:46/
文章来源:
旅游网网站建设的管理,口碑营销的前提及好处有哪些,贵阳网站建设q.479185700惠,台州网站建设惠店科技Mysql的面试突击1
Mysql的体系结构是什么样子的#xff08;查询语句怎么进行执行的#xff09;
mysql的架构#xff1a;单进程多线程的架构模式 CLient ----- Server架构 Mysql的链接方式有没有性能优化的点 2个点
查询缓存(Query Cache)
MySQL 内部自带了一个缓存模…Mysql的面试突击1
Mysql的体系结构是什么样子的查询语句怎么进行执行的
mysql的架构单进程多线程的架构模式 CLient ----- Server架构 Mysql的链接方式有没有性能优化的点 2个点
查询缓存(Query Cache)
MySQL 内部自带了一个缓存模块。默认是关闭的。主要是因为 MySQL 自带的缓存的应用场景有限第一个是它要求 SQL 语句必须一模一样。第二个是表里面任何一条数据发生变化的时候这张表所有缓存都会失效。
在 MySQL 5.8 中查询缓存已经被移除了。
3、语法解析和预处理(Parser Preprocessor)
下一步我们要做什么呢
假如随便执行一个字符串 fkdljasklf 服务器报了一个 1064 的错
[Err] 1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘fkdljasklf’ at line 1
服务器是怎么知道我输入的内容是错误的
或者当我输入了一个语法完全正确的 SQL但是表名不存在它是怎么发现的
这个就是 MySQL 的 Parser 解析器和 Preprocessor 预处理模块。
这一步主要做的事情是对 SQL 语句进行词法和语法分析和语义的解析。
词法解析
词法分析就是把一个完整的 SQL 语句打碎成一个个的单词。
比如一个简单的 SQL 语句
select name from user where id 1;
它会打碎成 8 个符号记录每个符号是什么类型从哪里开始到哪里结束。
语法解析
第二步就是语法分析语法分析会对 SQL 做一些语法检查比如单引号有没有闭合然后根据 MySQL
定义的语法规则根据 SQL 语句生成一个数据结构。这个数据结构我们把它叫做解析树。 预处理器Preprocessor
语义解析
如果表名错误会在预处理器处理时报错。
它会检查生成的解析树解决解析器无法解析的语义。比如它会检查表和列名是否存在检查名字和别名保证没有歧义。
4、查询优化Query Optimizer与查询执行计划
什么优化器
问题一条 SQL 语句是不是只有一种执行方式或者说数据库最终执行的 SQL 是不是就是我们发送 的 SQL
这个答案是否定的。一条 SQL 语句是可以有很多种执行方式的。但是如果有这么多种执行方式这些执行方式怎么得到的最终选择哪一种去执行根据什么判断标准去选择
这个就是 MySQL 的查询优化器的模块Optimizer。
查询优化器的目的就是根据解析树生成不同的执行计划然后选择一种最优的执行计划MySQL 里面使用的是基于开销cost的优化器那种执行计划开销最小就用哪种。
使用如下命令查看查询的开销show status like Last_query_cost; --代表需要随机读取几个 4K 的数据页才能完成查找。 如果我们想知道优化器是怎么工作的它生成了几种执行计划每种执行计划的 cost 是多少应该怎么做
优化器是怎么得到执行计划的
https://dev.mysql.com/doc/internals/en/optimizer-tracing.html
首先我们要启用优化器的追踪默认是关闭的
SHOW VARIABLES LIKE optimizer_trace; set optimizer_traceenabledon; 注意开启这开关是会消耗性能的因为它要把优化分析的结果写到表里面所以不要轻易开启或者查看完之后关闭它改成 off。
接着我们执行一个 SQL 语句优化器会生成执行计划
select t.tcid from teacher t,teacher_contact tc where t.tcid tc.tcid; 这个时候优化器分析的过程已经记录到系统表里面了我们可以查询
select * from information_schema.optimizer_trace\G expanded_query 是优化后的 SQL 语句。
considered_execution_plans 里面列出了所有的执行计划。 记得关掉它 set optimizer_traceenabledoff; • SHOW VARIABLES LIKE optimizer_trace; 优化器可以做什么
MySQL 的优化器能处理哪些优化类型呢
比如
1、当我们对多张表进行关联查询的时候以哪个表的数据作为基准表。 2、select * from user where a1 and b2 and c3如果 c3 的结果有 100 条b2 的结果有 200 条 a1 的结果有 300 条你觉得会先执行哪个过滤 3、如果条件里面存在一些恒等或者恒不等的等式是不是可以移除。 4、查询数据是不是能直接从索引里面取到值。 5、count()、min()、max()比如是不是能从索引里面直接取到值。 6、其他。优化器得到的结果
优化器最终会把解析树变成一个查询执行计划查询执行计划是一个数据结构。
当然这个执行计划是不是一定是最优的执行计划呢不一定因为 MySQL 也有可能覆盖不到所有的执行计划。
MySQL 提供了一个执行计划的工具。我们在 SQL 语句前面加上 EXPLAIN就可以看到执行计划的信息。
EXPLAIN select name from user where id1; MySQL 体系结构总结知其然知其所以然
架构分层
总体上我们可以把 MySQL 分成三层。 模块详解 1.Connector用来支持各种语言和 SQL 的交互比如 PHPPythonJava 的 JDBC
**2.Management Serveices Utilities系统管理和控制工具包括备份恢复、MySQL 复制、集群等等 **
**3.Connection Pool连接池管理需要缓冲的资源包括用户密码权限线程等等 **
**4.SQL Interface用来接收用户的 SQL 命令返回用户需要的查询结果 **
**5.Parser用来解析 SQL 语句 **
**6.Optimizer查询优化器 **
**7.Cache and Buffer查询缓存除了行记录的缓存之外还有表缓存Key 缓存权限缓存等等。 **
**8.Pluggable Storage Engines插件式存储引擎它提供 API 给服务层使用跟具体的文件打交道。 **
Bin log
1.bin Log: 数据恢复 主从复制
MySQL Server 层也有一个日志文件叫做 binlog它可以被所有的存储引擎使用。
bin log 以事件的形式记录了所有的 DDL 和 DML 语句因为它记录的是操作而不是数据值属于逻辑日志可以用来做主从复制和数据恢复。、 数据恢复区别于Redo Log的崩溃恢复数据恢复是基于业务数据的比如删库跑路而崩溃恢复是断电重启的
什么是预读
磁盘读写并不是按需读取而是按页读取一次至少读一页数据一般是4K但是Mysql的数据页是16K如果未来要读取的数据就在页中就能够省去后续的磁盘IO提高效率。
也可以调整 什么是Buffer Pool
内存缓冲区 CPU高速缓冲区
缓存表数据与索引数据把磁盘上的数据加载到缓冲池避免每次访问都进行磁盘IO起到加速访问的作用。
Buffer Pool的内存淘汰策略
冷热分区的LRU策略
LRU链表会被拆分成为两部分一部分为热数据一部分为冷数据。冷数据占比 3/8热数据5/8。 数据页第一次加载进来放在LRU链表的什么地方
放在冷数据区域的头部
冷数据区域的缓存页什么时候放入热数据区域
MySQL设定了一个规则在 innodb_old_blocks_time 参数中默认值为1000也就是1000毫秒。
意味着只有把数据页加载进缓存里在经过1s之后再次对此缓存页进行访问才会将缓存页放到LRU链表热数据区域的头部。
为什么是1秒
因为通过预读机制和全表扫描加载进来的数据页通常是1秒内就加载了很多然后对他们访问一下这些都是1秒内完成他们会存放在冷数据区域等待刷盘清空基本上不太会有机会放入到热数据区域除非在1秒后还有人访问说明后续可能还会有人访问才会放入热数据区域的头部。
Redo Log跟Buffer Pool的关系
崩溃恢复 基本保障 系统自动做的 InnoDB 引入了一个日志文件叫做 redo log重做日志我们把所有对内存数据的修改操作写入日志文件如果服务器出问题了我们就从这个日志文件里面读取数据恢复数据——用它来实现事务的持久性。 redo log 有什么特点 1.记录修改后的值属于物理日志 2.redo log 的大小是固定的前面的内容会被覆盖所以不能用于数据回滚/数据恢复。 3.redo log 是 InnoDB 存储引擎实现的并不是所有存储引擎都有。 Mysql的数据恢复怎么做
数据恢复删库跑路了 我能够去将你的数据进行恢复
备份每天2点 备份今天的所有数据库的数据 防止丢失 bin Log 二进制的日志文件 DDL dmL
解析Bin Log 专门的工具
9点 删库跑路 drop table 首先 应该做得就是 把数据备份恢复出来 2点之前的
2点 - 9点之间的数据 bin Log 重新执行一遍 10分钟
查看存储引擎
查看数据库表的存储引擎show table status from training;[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-YQ3dOuH3-1691369882176)(C:\Users\root\AppData\Roaming\Typora\typora-user-images\image-20210531170347359.png)]
在 MySQL 里面我们创建的每一张表都可以指定它的存储引擎它不是一个数据库只能使用一个存储引擎。而且创建表之后还可以修改存储引擎。
数据库存放数据的路径show variables like datadir; 每个数据库有一个自己文件夹以 trainning 数据库为例。任何一个存储引擎都有一个 frm 文件这个是表结构定义文件。[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-naNqGGQR-1691369882177)(C:\Users\root\AppData\Roaming\Typora\typora-user-images\image-20210531170359538.png)]
我们在数据库中建了三张表使用了不同的存储引擎。不同的存储引擎存放数据的方式不一样产生的文件也不一样。存储引擎比较
常见存储引擎
在 MySQL 5.5 版本之前默认的存储引擎是 MyISAM它是 MySQL 自带的5.5.5 版本之后默认的存储引擎改成了InnoDB它是第三方公司为MySQL开发的。为什么要改呢最主要的原因还是InnoDB支持事务支持行级别的锁对于业务一致性要求高的场景来说更适合。数据库支持的存储引擎
我们可以用这个命令查看数据库对存储引擎的支持情况SHOW ENGINES ; 其中有存储引擎的描述和对事务、XA 协议和 Savepoints 的支持官网对于存储引擎的介绍https://dev.mysql.com/doc/refman/5.7/en/storage-engines.htmlMyISAM3个文件
These tables have a small footprint. Table-level locking limits the performance in read/write workloads, so it is often used in read-only or read-mostly workloads in Web and data warehousing configurations.应用范围比较小。表级锁定限制了读/写的性能因此在 Web 和数据仓库配置中它通常用于只读或以读为主的工作。
特点
支持表级别的锁插入和更新会锁表。不支持事务。拥有较高的插入insert和查询select速度。存储了表的行数count 速度更快。适合只读之类的数据分析的项目。
InnoDB2 个文件
The default storage engine in MySQL 5.7. InnoDB is a transaction-safe (ACID compliant) storage engine for MySQL that has commit, rollback, and crash-recovery capabilities to protect user data. InnoDB row-level locking (without escalation to coarser granularity locks) and Oracle-style consistent nonlocking reads increase multi-user concurrency and performance. InnoDB stores user data in clustered indexes to reduce I/O for common queries based on primary keys. To maintain data integrity, InnoDB also supports FOREIGN KEY referential-integrity constraints.mysql 5.7 中的默认存储引擎。InnoDB 是一个事务安全与 ACID 兼容的 MySQL 存储引擎它具有提交、回滚和崩溃恢复功能来保护用户数据。InnoDB 行级锁不升级为更粗粒度的锁和 Oracle风格的一致非锁读提高了多用户并发性和性能。InnoDB 将用户数据存储在聚集索引中以减少基于 主键的常见查询的 I/O。为了保持数据完整性InnoDB 还支持外键引用完整性约束。特点
支持事务支持外键因此数据的完整性、一致性更高。支持行级别的锁和表级别的锁。支持读写并发写不阻塞读。特殊的索引存放方式可以减少 IO提升查询效率。适合经常更新的表存在并发读写或者有事务处理的业务系统。
Memory1个文件
Stores all data in RAM, for fast access in environments that require quick lookups of non-critical data. This engine was formerly known as the HEAP engine. Its use cases are decreasing; InnoDB with its buffer pool memory area provides a general-purpose and durable way to keep most or all data in memory, and NDBCLUSTER provides fast key-value lookups for huge distributed data sets.将所有数据存储在 RAM 中以便在需要快速查找非关键数据的环境中快速访问。这个引擎以前被称为堆引擎。其使用案例正在减少InnoDB 及其缓冲池内存区域提供了一种通用、持久的方法来 将大部分或所有数据保存在内存中而 ndbcluster 为大型分布式数据集提供了快速的键值查找。特点
把数据放在内存里面读写的速度很快但是数据库重启或者崩溃数据会全部消失。只适合 做临时表。默认使用哈希索引。 将表中的数据存储到内存中。CSV3个文件
Its tables are really text files with comma-separated values. CSV tables let you import or dump data in CSV format, to exchange data with scripts and applications that read and write that same format. Because CSV tables are not indexed, you typically keep the data in InnoDB tables during normal operation, and only use CSV tables during the import or export stage.
它的表实际上是带有逗号分隔值的文本文件。csv 表允许以 csv 格式导入或转储数据以便与读写相同格式的脚本和应用程序交换数据。因为 csv 表没有索引所以通常在正常操作期间将数据保存在 innodb 表中并且只在导入或导出阶段使用 csv 表。
特点
不允许空行不支持索引。格式通用可以直接编辑适合在不同数据库之间导入导出。
Archive2 个文件
These compact, unindexed tables are intended for storing and retrieving large amounts of seldom-referenced historical, archived, or security audit information.
这些紧凑的未索引表用于存储和检索大量很少引用的历史、存档或安全审计信息。
特点
不支持索引不支持 update delete。
6、执行引擎Query Execution Engine返回结果
执行引擎它利用存储引擎提供了相应的 API 来完成对存储引擎的操作。最后把数据返回给客户端即使没有结果也要返回。
一条更新语句的执行流程
跟 redo log 不一样它的文件内容是可以追加的没有固定大小限制。
有了这两个日志之后我们来看一下一条更新语句是怎么执行的 例如一条语句update teacher set name‘老严’ where name ‘666’
1、先查询到这条数据如果有缓存也会用到缓存。
2、把 name 改成老严然后调用引擎的 API 接口写入这一行数据到内存同时记录 redo log。这时 redo log 进入 prepare 状态然后告诉执行器执行完成了可以随时提交。
3、执行器收到通知后记录 binlog然后调用存储引擎接口设置 redo log 为 commit 状态。
4、更新完成。
问题为什么redo Log要用两阶段提交XA呢
举例
如果我们执行的是把 name 改成老严如果写完 redo log还没有写 bin log 的时候MySQL 重启了。
因为 redo log 可以恢复数据所以写入磁盘的是老严。但是 bin log 里面没有记录这个逻辑日志所以这时候用 binlog 去恢复数据或者同步到从库就会出现数据不一致的情况。
所以在写两个日志的情况下binlog 就充当了一个事务的协调者。通知 InnoDB 来执行 prepare 或commit 或者 rollback。
简单地来说这里有两个写日志的操作类似于分布式事务不用两阶段提交就不能保证都成功或者都失败。
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/web/85455.shtml
如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!