MySQL架构概览

本文主要是介绍MySQL架构概览，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

开局一张图，剩下全靠编。

单进程多线程的架构

现在主流的架构都已经是单进程多线程了，而另一个大佬Oracle是多进程架构，为什么？

多进程架构每个服务都是独立的进程，隔离比较好，某个会话出现问题，包括内存泄漏等BUG都比较容易解决，而单进程架构下，这种缺陷会被放大。

多线程架构，线程之间通讯的效率直接可以通过内存，通过线程锁实现串行化，其开销是十分小的，这对于大规模并发十分有利。不过这种架构也有其缺陷，线程数量太多，线程调度的开销将十分大，因此这种架构比较适合大并发，但是每个访问都较短的场景。对于海量并发场景，可能并不能比多进程架构有优势。

而现在都是并发有限，所以redis和nginx这种都采用了单进程多线程架构。（nginx更是可以配置worker达到多进程多线程，进一步优化并发）

具体每一层在干啥

• 网络连接层
• server层
  • 连接器、查询缓存、分析器、优化器、执行器
  • 内置函数（如日期、时间、数学和加密函数等）
• 存储引擎层
  • 负责数据的存储和提取
  • 插件式的，支持InnoDB、MyISAM、Memory等多个存储引擎。
• 系统文件层
  • 数据、索引、redo 日志、undo 日志、错误日志、查询记录、慢查询等

连接器

权限是在连接是确定的，后面更改的要到下一次连接才生效。

连接完成后，如果你没有后续的动作，这个连接就处于空闲状态，你可以在show processlist命令中看到它。

客户端如果太长时间没动静，连接器就会自动将它断开。这个时间是由参数wait_timeout控制的，默认值是8小时。

长连接：占内存，甚至导致OOM，MySQL异常重启。
短连接：消耗严重，毕竟连接的过程并不简单。

解决：定期断开长连接。

所有的连接都是这样，不要太短，也不要太长，比如心跳包，或者探针包。一般可以设置30秒没事断开，有事干事，减少了频繁连接消耗，也避免了无用连接占用。

怎么优化连接？提前连接，延后断开。（连接池）

查询缓存

缓存是怎么存的？hash，SQL语句作为key，结果作为value。
这个功能很鸡肋，所以8.0版本去掉了。

为什么？

• key和value都很大。
• 更新会将所有缓存清空，缓存命中率并不高。
• 尽量用业务逻辑解决，重复的查询可以用Redis之类的临时存储。

分析器

词法分析。就是看你写的SQL有没有语法错误

优化器

决定什么？

• 使用哪个索引。
• 多表联查，每个表的先后顺序。

这也是我们在执行计划里面看到的。

执行器

• 权限判断
• 执行：
  • 取满足条件的第一行
  • 循环：满足条件的下一行
  • 将结果集返回给客户端。

引擎扫描行数跟慢查询日志中的rows_examined并不是完全相同的。

半双工

MySQL 客户端与服务端的通信方式是 “ 半双工 ”。

这就代表，服务端不返回，客户端就只能等，直到超时。

然后网络发包是一个个发的，所以这也是为什么尽量不要用select * ，因为要尽量减少返回数据的量。

总结

这篇只是大致看一下架构的总览，不涉及细节，为以后的分析做个铺垫，当我们遇到问题的时候可以按图索骥，分析是哪一步卡了，是哪一步的问题，mysql为什么要这么做，有什么好处。

比如，一个连接连上了，你再改他的权限为什么没效果？

为什么mysql有时候会选择一个更慢的方案？

为什么执行计划看到的和最后执行的还有点不一样？

结语

• 如果有不对的地方欢迎指正。
• 如果有不理解的地方欢迎指出我来加栗子。
• 如果感觉OK可以点赞让更多人看到它。

这篇关于MySQL架构概览的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！