参宿yolo
中国矿业大学
获得徽章 1
#青训营笔记创作活动# 1，22 day8
如何定位并分析慢查询：
1. 慢查询日志分析(默认不开启)。slow_query_log_file 可以查看日志位置。
2. 使用explain 查看分析SQL的执行计划。 在语句前加 explain
其实最主要的是第二步，接下来还可以用show profiles来查看耗时，Optimizer Trace来查看优化器的实际执行。
慢查询案例：
1. 隐式转换导致索引失效。(123被隐式转换为'123' 实际索引字段的数据类型为字符串)
2. 联合索引下没有遵循最左匹配原则。(也有特殊情况)
3. 深分页问题，简单讲就是要获得从id为10000到10010的数据，采用了获取前10010条再丢弃掉前10000行。(扫描行数多，回表次数更多)。 可以使用标签记录法(where限制范围)和延迟关联法(使用内连接，先找到满足条件的主键id,原表再通过主键Id内连接，走主键索引)
4.in中元素过多。将in包含的数值，一条条去查询获取元组数的，因此这个计算过程(代价计算)会比较的慢。 一般in中元素最好不要超过200个。
5.order by 走文件排序。排序的数据大于sort_buffer_size时，借助磁盘文件来进行排序。先把数据放入sort_buffer，当快要满时。会排一下序，然后把sort_buffer中的数据，放到临时磁盘文件。查完后再再用归并算法把磁盘的临时排好序的小文件，合并成一个有序的大文件。 ord by 本身用来排序，索引数据本身是有序的，我们通过建立索引来优化order by语句。(尽量不用ord by?) 或者调整max_length_for_sort_data、sort_buffer_size
6. 由于数据量问题，优化器认为走索引反而会慢，导致索引失效。
7.左右链接时的关联字段的编码格式不一样
8.group by 使用临时表。既用到临时表，又默认用到排序。有时候还可能用到磁盘临时表。 优化：可以关闭默认排序(order by null)，group by后的字段加索引。
9.delete + in不走索引。
如何定位并分析慢查询：
1. 慢查询日志分析(默认不开启)。slow_query_log_file 可以查看日志位置。
2. 使用explain 查看分析SQL的执行计划。 在语句前加 explain
其实最主要的是第二步，接下来还可以用show profiles来查看耗时，Optimizer Trace来查看优化器的实际执行。
慢查询案例：
1. 隐式转换导致索引失效。(123被隐式转换为'123' 实际索引字段的数据类型为字符串)
2. 联合索引下没有遵循最左匹配原则。(也有特殊情况)
3. 深分页问题，简单讲就是要获得从id为10000到10010的数据，采用了获取前10010条再丢弃掉前10000行。(扫描行数多，回表次数更多)。 可以使用标签记录法(where限制范围)和延迟关联法(使用内连接，先找到满足条件的主键id,原表再通过主键Id内连接，走主键索引)
4.in中元素过多。将in包含的数值，一条条去查询获取元组数的，因此这个计算过程(代价计算)会比较的慢。 一般in中元素最好不要超过200个。
5.order by 走文件排序。排序的数据大于sort_buffer_size时，借助磁盘文件来进行排序。先把数据放入sort_buffer，当快要满时。会排一下序，然后把sort_buffer中的数据，放到临时磁盘文件。查完后再再用归并算法把磁盘的临时排好序的小文件，合并成一个有序的大文件。 ord by 本身用来排序，索引数据本身是有序的，我们通过建立索引来优化order by语句。(尽量不用ord by?) 或者调整max_length_for_sort_data、sort_buffer_size
6. 由于数据量问题，优化器认为走索引反而会慢，导致索引失效。
7.左右链接时的关联字段的编码格式不一样
8.group by 使用临时表。既用到临时表，又默认用到排序。有时候还可能用到磁盘临时表。 优化：可以关闭默认排序(order by null)，group by后的字段加索引。
9.delete + in不走索引。
展开
评论
点赞
#青训营笔记创作活动# 1.21 day7
无论是读操作还是写操作，在SQL执行前都会做这些：
1. 获取一个数据库连接对象，首先尝试从连接池中获取连接，如果没有空闲连接的话，检查当前是否达到最大连接数，如果没有，则建立新连接；如果达到，则等待空闲连接。 建立新连接的过程需要经过3次握手等。
查询SQL的执行：
● 将SQL发送给SQL接口，SQL接口会对SQL语句进行哈希处理。
● ②SQL接口在缓存中根据哈希值检索数据，如果缓存中有则直接返回数据。
● ③缓存中未命中时会将SQL交给解析器，解析器会判断SQL语句是否正确：
● 错误：抛出1064错误码及相关的语法错误信息。
● 正确：将SQL语句交给优化器处理，进入第④步。
● ④优化器根据SQL制定出不同的执行方案，并择选出最优的执行计划。
● ⑤工作线程根据执行计划，调用存储引擎所提供的API获取数据。
● ⑥存储引擎根据API调用方的操作，去磁盘中检索数据（索引、表数据....）。
● ⑦发生磁盘IO后，对于磁盘中符合要求的数据逐条返回给SQL接口。
● ⑧SQL接口会对所有的结果集进行处理（剔除列、合并数据....）并返回。
其中读与写最大的区别在于写操作会有更多的日志记录。
无论是读操作还是写操作，在SQL执行前都会做这些：
1. 获取一个数据库连接对象，首先尝试从连接池中获取连接，如果没有空闲连接的话，检查当前是否达到最大连接数，如果没有，则建立新连接；如果达到，则等待空闲连接。 建立新连接的过程需要经过3次握手等。
查询SQL的执行：
● 将SQL发送给SQL接口，SQL接口会对SQL语句进行哈希处理。
● ②SQL接口在缓存中根据哈希值检索数据，如果缓存中有则直接返回数据。
● ③缓存中未命中时会将SQL交给解析器，解析器会判断SQL语句是否正确：
● 错误：抛出1064错误码及相关的语法错误信息。
● 正确：将SQL语句交给优化器处理，进入第④步。
● ④优化器根据SQL制定出不同的执行方案，并择选出最优的执行计划。
● ⑤工作线程根据执行计划，调用存储引擎所提供的API获取数据。
● ⑥存储引擎根据API调用方的操作，去磁盘中检索数据（索引、表数据....）。
● ⑦发生磁盘IO后，对于磁盘中符合要求的数据逐条返回给SQL接口。
● ⑧SQL接口会对所有的结果集进行处理（剔除列、合并数据....）并返回。
其中读与写最大的区别在于写操作会有更多的日志记录。
展开
评论
点赞
#青训营笔记创作活动# day6 Mysql分为网络连接层、系统服务层、存储引擎层、以及文件系统层。
MySQL的连接一般都是基于TCP/IP协议建立网络连接。当一个客户端尝试与MySQL建立连接时，MySQL内部都会派发一条线程负责处理该客户端接下来的所有工作。 数据库连接建立成功之后，MySQL与客户端之间会蚕蛹半双工的通讯机制工作。
也正因如此，所有的客户端连接都需要一条线程去维护，线程资源十分的珍贵。因此出现了连接池。连接的创建涉及到创建线程，分配栈空间等一系列动作，因此连接断开后不会立即销毁线程，而是会先放入到一个缓存连接池当中。这样就能在下次新连接到来时，省去了创建线程、分配栈空间等一系列动作。将数据库创建出的连接对象放入到一个池中，一旦出现新的访问请求会复用这些连接，一方面提升了性能，第二方面还节省了一定程度上的资源开销。
网络连接层：建立MySQL与客户端的连接。
系统服务层：MySQL的核心功能，如客户端Sql请求解析，语义分析、查询优化、缓存以及所有的内置函数（例如：日期、时间、统计、加密函数...），所有跨引擎的功能都在这一层实现，譬如存储过程、触发器和视图等一系列服务。
存储引擎层：
负责具体的数据操作以及执行工作，存储引擎是MySQL数据库中与磁盘文件打交道的子系统，不同的引擎底层访问文件的机制也存在些许细微差异，引擎也不仅仅只负责数据的管理，也会负责库表管理、索引管理等，MySQL中所有与磁盘打交道的工作，最终都会交给存储引擎来完成。
文件系统层：
是MySQL数据库的基础，本质上就是基于机器物理磁盘的一个文件系统，其中包含了配置文件、库表结构文件、数据文件、索引文件、日志文件等各类MySQL运行时所需的文件，这一层的功能比较简单，也就是与上层的存储引擎做交互，负责数据的最终存储与持久化工作。
MySQL的连接一般都是基于TCP/IP协议建立网络连接。当一个客户端尝试与MySQL建立连接时，MySQL内部都会派发一条线程负责处理该客户端接下来的所有工作。 数据库连接建立成功之后，MySQL与客户端之间会蚕蛹半双工的通讯机制工作。
也正因如此，所有的客户端连接都需要一条线程去维护，线程资源十分的珍贵。因此出现了连接池。连接的创建涉及到创建线程，分配栈空间等一系列动作，因此连接断开后不会立即销毁线程，而是会先放入到一个缓存连接池当中。这样就能在下次新连接到来时，省去了创建线程、分配栈空间等一系列动作。将数据库创建出的连接对象放入到一个池中，一旦出现新的访问请求会复用这些连接，一方面提升了性能，第二方面还节省了一定程度上的资源开销。
网络连接层：建立MySQL与客户端的连接。
系统服务层：MySQL的核心功能，如客户端Sql请求解析，语义分析、查询优化、缓存以及所有的内置函数（例如：日期、时间、统计、加密函数...），所有跨引擎的功能都在这一层实现，譬如存储过程、触发器和视图等一系列服务。
存储引擎层：
负责具体的数据操作以及执行工作，存储引擎是MySQL数据库中与磁盘文件打交道的子系统，不同的引擎底层访问文件的机制也存在些许细微差异，引擎也不仅仅只负责数据的管理，也会负责库表管理、索引管理等，MySQL中所有与磁盘打交道的工作，最终都会交给存储引擎来完成。
文件系统层：
是MySQL数据库的基础，本质上就是基于机器物理磁盘的一个文件系统，其中包含了配置文件、库表结构文件、数据文件、索引文件、日志文件等各类MySQL运行时所需的文件，这一层的功能比较简单，也就是与上层的存储引擎做交互，负责数据的最终存储与持久化工作。
展开
评论
点赞
#第五届青训营阅读打卡# day5 从电路交换-报文交换-到分组交换。分别解决了：一个通信线路占用问题;报文交换没有限制大小时的延迟问题
评论
点赞
#青训营笔记创作活动# day4 TCP为什么慢：为了满足可靠性，TCP设计了各种重传机制，拥塞控制机制，流量控制机制，乱序重排机制，分段机制，连接机制等等，这些都是耗时的操作。
UDP为什么快：基本上没有上述机制，即使丢包，也不会重传。(就是这么任性)
为什么UDP有的时候会比TCP快：TCP在传输数据时是将一个数据包分成多个数据包(分段机制)，这样即使丢包也不需要全部重传，只要重传丢失的包即可。
UDP虽然是无连接的，没有重传机制，但在很多使用场景下，一般还是会在应用层上做一些重传机制(KCP,QUIC等)。但UDP在传输数据时是将整个数据包进行传输，没有分段机制，一旦发生丢包，就需要将整个数据包重新传递。
UDP为什么快：基本上没有上述机制，即使丢包，也不会重传。(就是这么任性)
为什么UDP有的时候会比TCP快：TCP在传输数据时是将一个数据包分成多个数据包(分段机制)，这样即使丢包也不需要全部重传，只要重传丢失的包即可。
UDP虽然是无连接的，没有重传机制，但在很多使用场景下，一般还是会在应用层上做一些重传机制(KCP,QUIC等)。但UDP在传输数据时是将整个数据包进行传输，没有分段机制，一旦发生丢包，就需要将整个数据包重新传递。
展开
评论
1
赞了这篇文章
赞了这篇文章
赞了这篇文章
#青训营笔记创作活动# day3 http协议下，客户端不发送请求，服务端就不会主动响应。对于需要服务器主动推送数据到客户端的场景不友好；websocket协议的建立实际上在TCP三次握手后的第一次http请求中携带一些升级协议的请求头，服务端根据请求头中的base64码根据公开的算法解码成字符串，发送给客户端，客户端将base64码用公开的算吗解码后得到的字符串与服务端发来的字符串一致，则协议升为websocket。
websocket为了解决TCP”双全工“下可能产生的粘包问题，使用 数据头（内含payload长度） + payload data 的数据格式来传输。
websocket继承了TCP双全工的优点，解决了粘包问题，适用于需要服务器和客户端（浏览器）频繁交互的大部分场景。比如网页/小程序游戏，网页聊天室，以及一些类似飞书这样的网页协同办公软件。
websocket为了解决TCP”双全工“下可能产生的粘包问题，使用 数据头（内含payload长度） + payload data 的数据格式来传输。
websocket继承了TCP双全工的优点，解决了粘包问题，适用于需要服务器和客户端（浏览器）频繁交互的大部分场景。比如网页/小程序游戏，网页聊天室，以及一些类似飞书这样的网页协同办公软件。
展开
评论
1
赞了这篇文章
#青训营笔记创作活动# day2 看完之后总结一下： 是通过广播，向DHCP服务器要ip地址。关于offer阶段为何可以是单播，貌似是服务端通过DHCP协议字段“chaddr”(客户端填入)获得mac地址，服务器端给客户端分配的IP地址则填充在“yiaddr”(Your IP Address)中，有了客户端的IP、MAC地址，就可以完成整个IP报文的封装，将DHCP Offer发给客户端了。还要好好学习计网的知识呀
展开
评论
1
#青训营笔记创作活动# day2 最近在做驾驶舱的项目的时候发现自己sql能力不够呀 看完这篇文章后对mysql的索引有了一定的认识，还顺便学习了B树。
评论
1