【MYSQL】MYSQL 的学习教程（八）之 12 种慢 SQL 查询原因

日常开发中，我们经常会遇到数据库慢查询。那么导致数据慢查询都有哪些常见的原因呢？今天就跟大家聊聊导致 MySQL 慢查询的 12 个常见原因，以及对应的解决方法：

  • SQL 没加索引
  • SQL 索引失效
  • limit 深分页问题
  • 单表数据量太大
  • join 或者子查询过多
  • in元素过多
  • 数据库在刷脏页
  • order by 文件排序
  • 拿不到锁
  • delete + in 子查询不走索引
  • group by 使用临时表
  • 系统硬件或网络资源

1. SQL 没加索引

很多时候，我们的慢查询，都是因为没有加索引。如果没有加索引的话，会导致全表扫描的。因此，应考虑在 where 的条件列，建立索引，尽量避免全表扫描

2. SQL 索引失效

【MYSQL】MYSQL 的学习教程（四）之索引失效场景

有时候我们明明加了索引了，但是索引却不生效。在哪些场景，索引会不生效呢？主要有以下十大经典场景：

  1. 查询条件包含 or，可能导致索引失效
  2. 隐式的类型转换，索引失效
  3. like 通配符 “%” 在关键词前面导致索引失效
  4. 在索引列上使用 MYSQL 的内置函数，索引失效
  5. 对索引列运算（如，+、-、*、/），索引失效
  6. 索引字段上使用负向查询（NOT、!=、<>、NOT IN、NOT LIKE）时，可能会导致索引失效
  7. 索引字段可以为 null，使用 is null， is not null，可能导致索引失效
  8. 违反了索引的最左匹配原则（联合索引，查询时的条件列不是联合索引中的第一个列，索引失效）
  9. 左连接查询或者右连接查询查询关联的字段编码格式不一样，可能导致索引失效
  10. MYSQL 估计使用全表扫描要比使用索引快,则不使用索引

3. limit 深分页问题

3.1 limit 深分页为什么会变慢

limit深分页为什么会导致 SQL 变慢呢？假设我们有表结构如下：

CREATE TABLE account (id int(11) NOT NULL AUTO_INCREMENT COMMENT '主键Id',name varchar(255) DEFAULT NULL COMMENT '账户名',balance int(11) DEFAULT NULL COMMENT '余额',create_time datetime NOT NULL COMMENT '创建时间',update_time datetime NOT NULL ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',PRIMARY KEY (id),KEY idx_name (name),KEY idx_create_time (create_time) //索引
) ENGINE=InnoDB AUTO_INCREMENT=1570068 DEFAULT CHARSET=utf8 ROW_FORMAT=REDUNDANT COMMENT='账户表';

执行如下 SQL：

select id,name,balance from account where create_time> '2020-09-19' limit 100000,10;

这个SQL的执行流程：

  1. 通过普通二级索引树 idx_create_time，过滤 create_time 条件，找到满足条件的主键 id
  2. 通过主键 id，回到 id 主键索引树，找到满足记录的行，然后取出需要展示的列（回表过程）
  3. 扫描满足条件的 100010 行，然后扔掉前 100000 行，返回结果

如下图：

在这里插入图片描述

limit 深分页，导致 SQL 变慢原因有两个：

  • limit 语句会先扫描 offset+ n 行，然后再丢弃掉前 offset 行，返回后 n 行数据。也就是说 limit 100000,10，就会扫描100010行，而 limit 0,10，只扫描10行
  • limit 100000,10 扫描更多的行数，也意味着回表更多的次数

3.2 如何优化深分页问题

我们可以通过减少回表次数来优化。一般有：标签记录法、延迟关联法

3.2.1 标签记录法

标签记录法：标记一下上次查询到哪一条了，下次再来查的时候，从该条开始往下扫描

假设上一次记录到 100000，则 SQL 可以修改为：

select  id,name,balance FROM account where id > 100000 limit 10;

这样的话，后面无论翻多少页，性能都会不错的，因为命中了 id 主键索引。但是这种方式有局限性：需要一种类似连续自增的字段

3.2.2 延迟关联法

延迟关联法：把条件转移到主键索引树，然后减少回表

select  acct1.id,acct1.name,acct1.balance FROM account acct1 INNER JOIN (SELECT a.id FROM account a WHERE a.create_time > '2020-09-19' limit 100000, 10) AS acct2 on acct1.id= acct2.id;

优化思路：先通过 idx_create_time 二级索引树查询到满足条件的主键 ID，再与原表通过主键 ID 内连接，这样后面直接走了主键索引了，同时也减少了回表

4. 单表数据量太大

4.1 单表数据量太大为什么会变慢？

一个表的数据量达到好几千万或者上亿时，加索引的效果没那么明显啦。性能之所以会变差，是因为维护索引的 B+ 树结构层级变得更高了，查询一条数据时，需要经历的磁盘IO变多，因此查询性能变慢

4.2 一棵 B+ 树可以存多少数据量

【MYSQL】MYSQL 的学习教程（五）之 MySQL 索引底层：B+ 树详解
一棵高度为 3 的 B+ 树，能存放 1170 *1170 *16 =21902400，也就是说，可以存放两千万左右的记录。B+ 树高度一般为 1-3 层，已经满足千万级别的数据存储

如果 B+ 树想存储更多的数据，那树结构层级就会更高，查询一条数据时，需要经历的磁盘IO变多，因此查询性能变慢

4.3 如何解决单表数据量太大，查询变慢的问题

一般超过千万级别，我们可以考虑分库分表了

分库分表可能导致的问题：

  • 事务问题
  • 跨库问题
  • 排序问题
  • 分页问题
  • 分布式ID

在评估是否分库分表前，先考虑下是否可以把部分历史数据归档，如果可以的话，先不要急着分库分表。如果真的要分库分表，综合考虑和评估方案。比如可以考虑垂直、水平分库分表。水平分库分表策略的话，range范围、hash取模、range+hash取模混合等等

5. join 或者子查询过多

一般来说，不建议使用子查询，可以把子查询改成 join 来优化

而数据库有个规范约定就是：尽量不要有超过3个以上的表连接

MySQL中，join的执行算法，分别是：Index Nested-Loop Join、Block Nested-Loop Join

  • Index Nested-Loop Join（索引嵌套循环连接）：这个 join 算法，跟我们写程序时的嵌套查询类似，并且可以用上被驱动表的索引
  • Block Nested-Loop Join（缓存块嵌套循环连接）：被驱动表上没有可用的索引，它会先把驱动表的数据读入线程内存join_buffer 中，再扫描被驱动表，把被驱动表的每一行取出来，跟 join_buffer 中的数据做对比，满足join条件的，作为结果集的一部分返回

join 过多的问题：

  1. 过多的表连接，会大大增加 SQL 复杂度
  2. 如果可以使用被驱动表的索引那还好，并且使用小表来做驱动表，查询效率更佳。如果被驱动表没有可用的索引，join是在 join_buffer 内存做的，如果匹配的数据量比较小或者 join_buffer 设置的比较大，速度也不会太慢。但是，如果join的数据量比较大时，mysql 会采用在硬盘上创建临时表的方式进行多张表的关联匹配，这种显然效率就极低，本来磁盘的 IO 就不快，还要关联

一般情况下，如果业务需要的话，关联 2~3 个表是可以接受的，但是关联的字段需要加索引哈。如果需要关联更多的表，建议从代码层面进行拆分，在业务层先查询一张表的数据，然后以关联字段作为条件查询关联表形成 map，然后在业务层进行数据的拼装

6. in元素过多

如果使用了 in，即使后面的条件加了索引，还是要注意in后面的元素不要过多哈。in 元素一般建议不要超过500个，如果超过了，建议分组，每次500一组进行哈

如果我们对in的条件不做任何限制的话，该查询语句一次性可能会查询出非常多的数据，很容易导致接口超时。尤其有时候，我们是用的子查询，in后面的子查询，你都不知道数量有多少那种，更容易采坑。如下这种子查询：

select * from user where user_id in (select author_id from artilce where type = 1);

正例是，分批进行，每批500个：

select user_id,name from user where user_id in (1,2,3...500);

7. 数据库在刷脏页

7.1 什么是脏页

当内存数据页跟磁盘数据页内容不一致的时候，我们称这个内存页为**“脏页”。内存数据写入到磁盘后，内存和磁盘上的数据页的内容就一致了，称为“干净页”**。一般有更新 SQL 才可能会导致脏页

7.2 一条更新语句是如何执行的？

以下的这个更新SQL，如何执行的呢？

update t set c=c+1 where id=666;
  1. 对于这条更新SQL，执行器会先找引擎取 id = 666 这一行。如果这行所在的数据页本来就在内存中的话，就直接返回给执行器。如果不在内存，就去磁盘读入内存，再返回
  2. 执行器拿到引擎给的行数据后，给这一行 C 的值加一，得到新的一行数据，再调用引擎接口写入这行新数据
  3. 引擎将这行新数据更新到内存中，同时将这个更新操作记录到 redo log 里面，但是此时 redo log 是处于 prepare 状态的哈
  4. 执行器生成这个操作的 binlog，并把 binlog 写入磁盘
  5. 执行器调用引擎的提交事务接口，引擎把刚刚写入的 redo log 改成提交（commit）状态，更新完成

如下图：

在这里插入图片描述

InnoDB 在处理更新语句的时候，只做了写日志这一个磁盘操作。这个日志叫作 redo log（重做日志）。平时更新 SQL 执行得很快，其实是因为它只是在写内存和 redo log 日志，等到空闲的时候，才把 redo log 日志里的数据同步到磁盘中

redo log 日志不是在磁盘嘛？那为什么不慢？其实是因为写 redo log 的过程是顺序写磁盘的。磁盘顺序写会减少寻道等待时间，速度比随机写要快很多的。

7.3 为什么会出现脏页呢？

更新 SQL 只是在写内存和 redo log 日志，等到空闲的时候，才把 redo log 日志里的数据同步到磁盘中。这时内存数据页跟磁盘数据页内容不一致，就出现脏页

7.4 什么时候会刷脏页（flush）？

InnoDB 存储引擎的 redo log 大小是固定，且是环型写入的，如下图：

在这里插入图片描述

那什么时候会刷脏页？有几种场景：

  1. redo log 写满了，要刷脏页。这种情况要尽量避免的。因为出现这种情况时，整个系统就不能再接受更新啦，即所有的更新都必须堵住
  2. 内存不够了，需要新的内存页，就要淘汰一些数据页，这时候会刷脏页

InnoDB 用缓冲池（buffer pool）管理内存,而当要读入的数据页没有在内存的时候，就必须到缓冲池中申请一个数据页。这时候只能把最久不使用的数据页从内存中淘汰掉：如果要淘汰的是一个干净页，就直接释放出来复用；但如果是脏页呢，就必须将脏页先刷到磁盘，变成干净页后才能复用

  1. MySQL 认为系统空闲的时候，也会刷一些脏页
  2. MySQL 正常关闭时，会把内存的脏页都 flush 到磁盘上

7.5 为什么刷脏页会导致 SQL 变慢呢？

  1. redo log 写满了，要刷脏页，这时候会导致系统所有的更新堵住，写性能都跌为0了，肯定慢呀。一般要杜绝出现这个情况。
  2. 一个查询要淘汰的脏页个数太多，一样会导致查询的响应时间明显变长

8. order by 文件排序

order by 就一定会导致慢查询吗？不是这样的哈，因为 order by 平时用得多，并且数据量一上来，还是走文件排序的话，很容易有慢SQL的

8.1 order by 的 Using filesort 文件排序

平时经常需要用到 order by ，主要就是用来给某些字段排序的。比如以下 SQL:

select name,age,city from staff where city = '深圳' order by age limit 10;

查看 explain 执行计划的时候，可以看到 Extra 这一列，有一个 Using filesort，它表示用到文件排序

8.2 order by文件排序效率为什么较低

order by 用到文件排序时，为什么查询效率会相对低呢？

在这里插入图片描述

order by 排序，分为全字段排序、rowid排序。它是拿 max_length_for_sort_data 和结果行数据长度对比，如果结果行数据长度超过 max_length_for_sort_data 这个值，就会走 rowid 排序，相反，则走全字段排序

8.2.1 rowid 排序

rowid 排序，一般需要回表去找满足条件的数据，所以效率会慢一点。以下这个 SQL，使用 rowid 排序，执行过程是这样：

select name,age,city from staff where city = '深圳' order by age limit 10;
  1. MySQL 为对应的线程初始化 sort_buffer，放入需要排序的 age 字段，以及主键 id
  2. 从索引树 idx_city， 找到第一个满足 city='深圳’ 条件的主键 id，也就是图中的 id=9
  3. 到主键 id索引树拿到 id=9 的这一行数据， 取 age 和主键 id 的值，存到 sort_buffer
  4. 从索引树 idx_city 拿到下一个记录的主键 id，即图中的 id=13
  5. 重复步骤 3、4 直到 city 的值不等于深圳为止
  6. 前面 5 步已经查找到了所有 city 为深圳的数据，在 sort_buffer 中，将所有数据根据 age 进行排序
  7. 遍历排序结果，取前 10 行，并按照 id 的值回到原表中，取出 city、name 和 age 三个字段返回给客户端

在这里插入图片描述

8.2.2 全字段排序

同样的 SQL，如果是走全字段排序是这样的：

  1. MySQL 为对应的线程初始化 sort_buffer，放入需要查询的 name、age、city 字段
  2. 从索引树 idx_city， 找到第一个满足 city='深圳’ 条件的主键 id，也就是图中的 id=9
  3. 到 主键id索引树 拿到 id=9 的这一行数据， 取 name、age、city 三个字段的值，存到 sort_buffer
  4. 从 索引树idx_city 拿到下一个记录的主键 id，即图中的 id=13
  5. 重复步骤 3、4 直到 city 的值不等于深圳为止
  6. 前面 5 步已经查找到了所有 city 为深圳的数据，在 sort_buffer 中，将所有数据根据 age 进行排序
  7. 按照排序结果取前 10 行返回给客户端

在这里插入图片描述

sort_buffer 的大小是由一个参数控制的：sort_buffer_size

  • 如果要排序的数据小于 sort_buffer_size，排序在 sort_buffer 内存中完成
  • 如果要排序的数据大于 sort_buffer_size，则借助磁盘文件来进行排序

借助磁盘文件排序的话，效率就更慢一点。因为先把数据放入 sort_buffer，当快要满时。会排一下序，然后把 sort_buffer 中的数据，放到临时磁盘文件，等到所有满足条件数据都查完排完，再用归并算法把磁盘的临时排好序的小文件，合并成一个有序的大文件

8.3 如何优化 order by 的文件排序

order by 使用文件排序，效率会低一点。我们怎么优化呢

  • 因为数据是无序的，所以就需要排序。如果数据本身是有序的，那就不会再用到文件排序啦。而索引数据本身是有序的，我们通过建立索引来优化 order by 语句
  • 可以通过调整 max_length_for_sort_data、sort_buffer_size 等参数优化

9. 拿不到锁

有时候，我们查询一条很简单的 SQL，但是却等待很长的时间，不见结果返回。一般这种时候就是表被锁住了，或者要查询的某一行或者几行被锁住了。我们只能慢慢等待锁被释放

这时候，我们可以用 show processlist 命令，看看当前语句处于什么状态哈

10. delete + in 子查询不走索引

当 delete 遇到 in 子查询时，即使有索引，也是不走索引的。而对应的 select + in 子查询，却可以走索引

实际执行的时候，MySQL 对 select in 子查询做了优化，把子查询改成 join 的方式，所以可以走索引。但是很遗憾，对于 delete in 子查询，MySQL 却没有对它做这个优化

11. group by 使用临时表

group by 一般用于分组统计，它表达的逻辑就是根据一定的规则，进行分组

假设有表结构：

CREATE TABLE `staff` (`id` bigint(11) NOT NULL AUTO_INCREMENT COMMENT '主键id',`id_card` varchar(20) NOT NULL COMMENT '身份证号码',`name` varchar(64) NOT NULL COMMENT '姓名',`age` int(4) NOT NULL COMMENT '年龄',`city` varchar(64) NOT NULL COMMENT '城市',PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=15 DEFAULT CHARSET=utf8 COMMENT='员工表';

我们查看一下这个SQL的执行计划：

explain select city ,count(*) as num from staff group by city;

在这里插入图片描述

  • Extra 这个字段的 Using temporary 表示在执行分组的时候使用了临时表
  • Extra 这个字段的 Using filesort 表示使用了文件排序

group by 是怎么使用到临时表和排序了呢？我们来看下这个SQL的执行流程：

  1. 创建内存临时表，表里有两个字段 city 和 num；
  2. 全表扫描 staff 的记录，依次取出 city = ‘X’ 的记录
    • 判断临时表中是否有为 city='X '的行，没有就插入一个记录 (X,1);
    • 如果临时表中有 city=‘X’ 的行，就将X这一行的 num 值加 1；
  3. 遍历完成后，再根据字段 city 做排序，得到结果集返回给客户端

这个流程的执行图如下：

在这里插入图片描述

临时表的排序是怎样的呢？

就是把需要排序的字段，放到 sort buffer，排完就返回。在这里注意一点哈，排序分全字段排序和 rowid 排序

  • 如果是全字段排序，需要查询返回的字段，都放入sort buffer，根据排序字段排完，直接返回
  • 如果是 rowid 排序，只是需要排序的字段放入sort buffer，然后多一次回表操作，再返回

11.2 group by 可能会慢在哪里？

因为它既用到临时表，又默认用到排序。有时候还可能用到磁盘临时表

  • 如果执行过程中，会发现内存临时表大小到达了上限（控制这个上限的参数就是tmp_table_size），会把内存临时表转成磁盘临时表。
  • 如果数据量很大，很可能这个查询需要的磁盘临时表，就会占用大量的磁盘空间

11.3 如何优化 group by 呢？

从哪些方向去优化呢？

  • 方向1：既然它默认会排序，我们不给它排是不是就行啦。
  • 方向2：既然临时表是影响 group by 性能的因素，我们是不是可以不用临时表？

执行 group by 语句为什么需要临时表呢？group by 的语义逻辑，就是统计不同的值出现的个数。如果这个这些值一开始就是有序的，我们是不是直接往下扫描统计就好了，就不用临时表来记录并统计结果啦?

可以有这些优化方案：

  1. group by 后面的字段加索引
  2. order by null 不用排序
  3. 尽量只使用内存临时表
  4. 使用 SQL_BIG_RESULT（直接用磁盘临时表。不需要从内存临时表转到磁盘临时表，这个过程很耗时）

12. 系统硬件或网络资源

  • 如果数据库服务器内存、硬件资源，或者网络资源配置不是很好，就会慢一些哈。这时候可以升级配置。这就好比你的计算机有时候很卡，你可以加个内存条什么的一个道理
  • 如果数据库压力本身很大，比如高并发场景下，大量请求到数据库来，数据库服务器CPU占用很高或者IO利用率很高，这种情况下所有语句的执行都有可能变慢的哈

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.mzph.cn/news/580288.shtml

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

【React】echarts-for-react 的使用

【React】echarts-for-react 的使用

文章目录 echarts-for-react &#xff1a;一个简单的 Apache echarts 的 React 封装配置项手册&#xff1a;https://echarts.apache.org/zh/option.html#title 安装依赖 $ npm install --save echarts-for-react# echarts 是 echarts-for-react的对等依赖,您可以使用自己的版本…
阅读更多...
手机无人直播：解放直播的新方式

手机无人直播：解放直播的新方式

现如今&#xff0c;随着科技的迅猛发展&#xff0c;手机已经成为我们生活中不可或缺的一部分。除了通讯、娱乐等功能外&#xff0c;手机还能够通过直播功能将我们的生活实时分享给他人。而针对传统的直播方式&#xff0c;使用手机进行无人直播成为了一种全新的选择。 手机无人…
阅读更多...
springboot中使用阿里云oss

springboot中使用阿里云oss

一、什么是OSS&#xff1f; 「OSS」的英文全称是Object Storage Service&#xff0c;翻译成中文就是「对象存储服务」&#xff0c;官方一点解释就是对象存储是一种使用HTTP API存储和检索非结构化数据和元数据对象的工具。 白话文解释就是将系统所要用的文件上传到云硬盘上&a…
阅读更多...
2023年入职/转行网络安全，该如何规划？

2023年入职/转行网络安全，该如何规划？

前言 前段时间&#xff0c;知名机构麦可思研究院发布了 《2022年中国本科生就业报告》&#xff0c;其中详细列出近五年的本科绿牌专业&#xff0c;其中&#xff0c;信息安全位列第一。 网络安全前景 对于网络安全的发展与就业前景&#xff0c;想必无需我多言&#xff0c;作为…
阅读更多...
网站服务器被入侵，如何排查，该如何预防入侵呢？

网站服务器被入侵，如何排查，该如何预防入侵呢？

在我们日常使用服务器的过程中&#xff0c;当公司的网站服务器被黑客入侵时&#xff0c;导致整个网站以及业务系统瘫痪&#xff0c;将会给企业带来无法估量的损失。作为服务器的维护人员应当在第一时间做好安全响应&#xff0c;对入侵问题做到及时处理&#xff0c;以最快的时间…
阅读更多...
Transfer Learning（迁移学习）

Transfer Learning（迁移学习）

1. 什么是迁移学习 迁移学习(Transfer Learning)是一种机器学习方法&#xff0c;就是把为任务 A 开发的模型作为初始点&#xff0c;重新使用在为任务 B 开发模型的过程中。迁移学习是通过从已学习的相关任务中转移知识来改进学习的新任务&#xff0c;虽然大多数机器学习算法都…
阅读更多...
如何使用ArcGIS Pro将Excel表转换为SHP文件

如何使用ArcGIS Pro将Excel表转换为SHP文件

有的时候我们得到的数据是一张张的Excel表格&#xff0c;如果想要在ArcGIS Pro中进行分析或者制图则需要先转换为SHP格式&#xff0c;这里为大家介绍一下转换方法&#xff0c;希望能对你有所帮助。 数据来源 本教程所使用的数据是从水经微图中下载的POI数据&#xff0c;除了P…
阅读更多...
关于mmcv和mmdet安装

关于mmcv和mmdet安装

open-mmlab的系列深度学习开源框架还是备受关注的&#xff0c;但是相关框架的安装也容易出现问题&#xff0c;导致在环境这一步就让人却步&#xff0c;我也在使用过程中碰到了很多问题。特别是随着框架的升级&#xff0c;硬件的升级等&#xff0c;使环境安装可以获取的选择变得…
阅读更多...
模式识别与机器学习-判别式分类器

模式识别与机器学习-判别式分类器

模式识别与机器学习-判别式分类器 生成式模型和判别式模型的区别线性判别函数多分类情况多分类情况1多分类情况2多分类情况3 例题 广义线性判别函数实例 分段线性判别函数Fisher线性判别感知机算法例&#xff1a;感知机多类别分类 谨以此博客作为学习期间的记录 生成式模型和判…
阅读更多...
SpringBoot 3.2.0 结合Redisson接入Redis

SpringBoot 3.2.0 结合Redisson接入Redis

依赖版本 JDK 17 Spring Boot 3.2.0 Redisson 3.25.0 工程源码&#xff1a;Gitee 集成Redis步骤 导入依赖 <properties><redisson.version>3.25.0</redisson.version> </properties> <dependencies><dependency><groupId>org.pr…
阅读更多...
【Python】requests库在CTFWeb题中的应用

【Python】requests库在CTFWeb题中的应用

目录 ①Bugku-GET ②Bugku-POST ③实验吧-天下武功唯快不破 ④Bugku-速度要快 ⑤Bugku-秋名山车神 ⑥Bugku-cookies ①Bugku-GET import requestsresprequests.get(urlhttp://114.67.175.224:12922/,params{what:flag}) print(resp.text)//或者 //resprequests.get(urlht…
阅读更多...
【操作系统】探究文件系统奥秘：创建proc文件系统的解密与实战

【操作系统】探究文件系统奥秘：创建proc文件系统的解密与实战

​&#x1f308;个人主页&#xff1a;Sarapines Programmer&#x1f525; 系列专栏&#xff1a;Linux专栏&#xff1a;《探秘Linux | 操作系统解密》⏰诗赋清音&#xff1a;月悬苍穹泛清辉&#xff0c;梦随星河徜徉辉。情牵天际云千层&#xff0c;志立乘风意自飞。 ​ 目录 &a…
阅读更多...
亚马逊美国站ASTM F2613儿童折叠椅和凳子强制性安全标准

亚马逊美国站ASTM F2613儿童折叠椅和凳子强制性安全标准

ASTM F2613折叠椅和凳子安全标准 美国消费品安全委员会&#xff08;CPSC&#xff09;发布的ASTM F2613儿童折叠椅和凳子的强制性安全标准&#xff0c;已于2020年7月6日生效&#xff0c;并被纳入联邦法规《16 CFR 1232儿童折叠椅和凳子安全标准》。 亚马逊要求在美国站上架的儿…
阅读更多...
C语言——字符函数和字符串函数（三）【strtok，strerror，perror】

C语言——字符函数和字符串函数（三）【strtok，strerror，perror】

&#x1f4dd;前言&#xff1a; 上一篇文章C语言——字符函数和字符串函数&#xff08;二&#xff09;对字符函数和字符串函数strstr&#xff0c;strcmp和strncmp进行了一定的讲解 这篇文章主要讲解以下函数的用法: 1&#xff0c;strtok 2&#xff0c;strerror 3&#xff0c;pe…
阅读更多...
Linux下的文本编辑Vi/Vim

Linux下的文本编辑Vi/Vim

编辑文件 文本编辑器有很多&#xff0c;比如图形模式的gedit、OpenOffice 等&#xff0c;文本模式下的编辑器有vi、vim&#xff08;vi的增强 版本&#xff09;等。vi和vim是我们在Linux中最常用的编辑器。 gedit 类似于Windows下的记事本&#xff0c;很方便的去修改文本。 Op…
阅读更多...
深入了解云原生：定义与特征解析

深入了解云原生：定义与特征解析

文章目录 一、云原生概述1.1 什么是云原生1.2 云原生组成要素1.3 补充资料 二、云原生的目标2.1 云原生关键目标2.2 云原生特性 三、云原生应用 VS 传统单体应用参考资料 一、云原生概述 1.1 什么是云原生 (1)云原生定义 云原生(Cloud Native) 是一种软件架构和开发方法论&a…
阅读更多...
山西电力市场日前价格预测【2023-12-27】

山西电力市场日前价格预测【2023-12-27】

日前价格预测 预测说明&#xff1a; 如上图所示&#xff0c;预测明日&#xff08;2023-12-27&#xff09;山西电力市场全天平均日前电价为737.42元/MWh。其中&#xff0c;最高日前电价为1500.00元/MWh&#xff0c;预计出现在08:00~08:30。最低日前电价为313.03元/MWh&#xff…
阅读更多...
Qt Creator可视化交互界面exe快速入门3

Qt Creator可视化交互界面exe快速入门3

上一期介绍的通过Qt Creator的组件直接拖拽的方式完成了一个界面&#xff0c;这期介绍按钮的信号交互。 专有名称叫信号与槽 实现方法1&#xff1a; 鼠标右键选择转化为槽就会跳出这样的界面 选择第一个为单击信号。然后就会跳转到代码界面。多了on_pushButton_clicked()。 …
阅读更多...
分页合理化是什么？

分页合理化是什么？

一、前言 只要是干过后台系统的同学应该都做过分页查询吧&#xff0c;前端发送带有页码&#xff08;pageNum&#xff09;和每页显示数量&#xff08;pageSize&#xff09;的请求&#xff0c;后端根据这些参数来提取并返回相应的数据集。在SpringBoot框架中&#xff0c;经常会使…
阅读更多...
以社区为基石，IvorySQL逐步成为中国基础软件开源数据库产业重要一员

以社区为基石，IvorySQL逐步成为中国基础软件开源数据库产业重要一员

编者按&#xff1a;开源数据库技术&#xff0c;作为软件开发领域的一大趋势&#xff0c;正逐渐改变整个软件产业的面貌。在这个充满活力的领域中&#xff0c;瀚高股份的IvorySQL凭借其社区活跃度和影响力&#xff0c;已经成为中国基础软件开源数据库产业的重要一员。随着《2023…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023