慢查询日志中的 Lock_time 从哪里来？

小阳人
小阳人 2023-05-24 09:11:35 63636
分类专栏： 资讯
经常关注慢查询日志的读者，和 Lock_time 应该算是老相识了，大家对这位老相识了解有多少呢？

研究 Lock_time 之前，我对它的了解，仅限于它表示锁等待时间。至于它包含哪些锁等待时间、怎么计算得到的，我并不清楚。

所以，我一直有个困惑：为什么有些 SQL 执行时间很长，Lock_time 却很小（例如：0.001 秒）?

今天我们就一起来看看，Lock_time 包含哪些锁等待时间、以及是怎么计算得到的？

本文基于 MySQL 8.0.32 源码，存储引擎为 InnoDB。

目录

  • 1. 整体介绍

  • 2. 表锁等待时间

  • 3. 行锁等待时间

  • 4. 累计时间

  • 5. lock_time

  • 6. 总结

 

正文

1. 整体介绍

Lock_time 由两部分相加得到：

  • 表锁等待时间，如果 SQL 中包含多个表，则是多个表锁等待时间之和。

  • 行锁等待时间，如果 SQL 执行过程中需要对多条记录加锁，则是多个行锁等待时间之和。

对 InnoDB 来说，DML、DQL 对记录进行增删改查操作时，如需加锁，都是加行级别的共享锁、排他锁，而不加表级别的共享锁、排他锁。

共享锁又称作 S 锁，排他锁又称作 X 锁。

那么，InnoDB 有表级别的共享锁、排他锁吗？

别说，还真有！

不过，不常有！

只有执行 LOCK TABLES ... [READ | WRITE]，并且系统变量 innodb_table_locks = 1、auto_commit = 0，InnoDB 才会加表级别的共享锁、排他锁。

从代码注释和官方文档对 innodb_table_locks 的介绍来看，执行存储过程和触发器时，InnoDB 也可能会加表级别的共享锁、排他锁，我们就不展开介绍了。

如果 InnoDB 加了表级别的共享锁、排他锁，Lock_time 包含表锁等待时间，我们比较好理解。

如果我们执行 DML、DQL，InnoDB 没有加表级别的共享锁、排他锁，Lock_time 里还包含表锁等待时间吗？

这个问题，就得看用什么标准了：

  • 严格来说，Lock_time 就不包含表锁等待时间了。

  • 不严格来说，Lock_time 还是包含表锁等待时间的（InnoDB 采用了这个标准）。

接下来，我们通过源码，进入表锁、行锁等待时间的实现逻辑，来一睹芳容。

2. 表锁等待时间

我们先来看一下表锁等待时间实现逻辑的堆栈：

| > mysql_execute_command(THD*, bool) sql/sql_parse.cc:4688
| + > Sql_cmd_dml::execute(THD*) sql/sql_select.cc:574
| + - > lock_tables(...) sql/sql_base.cc:6899
| + - x > mysql_lock_tables(...) sql/lock.cc:337
| + - x = > lock_external(THD*, TABLE**, unsigned int) sql/lock.cc:393
| + - x = | > handler::ha_external_lock(THD*, int) sql/handler.cc:7841
| + - x = | + > ha_innobase::external_lock(THD*, int) storage/innobase/handler/ha_innodb.cc:18869

Sql_cmd_dml::execute() 调用 lock_tables() 对多个表加锁。

// sql/sql_base.cc
bool lock_tables(THD *thd, Table_ref *tables, uint count, uint flags) {
  ...
  if (!thd->locked_tables_mode) {
    ...
    if (!(thd->lock =
          mysql_lock_tables(thd, start, (uint)(ptr - start), flags)))
      return true;
    ...
  }
  ...
}

lock_tables() 调用 mysql_lock_tables() 对多个表加锁。

// sql/lock.cc
MYSQL_LOCK *mysql_lock_tables(THD *thd, TABLE **tables, size_t count,
                              uint flags) {
  ...
  // 记录开始时间
  ulonglong lock_start_usec = my_micro_time();
  ...
  if (sql_lock->table_count &&
      lock_external(thd, sql_lock->table, sql_lock->table_count)) {
    /* Clear the lock type of all lock data to avoid reusage. */
    reset_lock_data_and_free(&sql_lock);
    goto end;
  }
  ...
  // lock_external() 执行完成之后
  // 当前时间减去开始时间
  // 就是表锁等待时间
  ulonglong lock_end_usec = my_micro_time();
  thd->inc_lock_usec(lock_end_usec - lock_start_usec);
  ...
}

mysql_lock_tables() 调用 lock_external() 之前，先把当前时间记录下来，作为表锁等待的开始时间。

然后调用 lock_external() 对多个表加锁。

最后，调用 thd->inc_lock_usec() 把表锁等待时间累加到 server 层线程对象（thd）的 m_lock_usec 属性中。

// sql/lock.cc
static int lock_external(THD *thd, TABLE **tables, uint count) {
  ...
  // 循环 SQL 中的表
  for (i = 1; i <= count; i++, tables++) {
    assert((*tables)->reginfo.lock_type >= TL_READ);
    // 默认锁类型为写锁
    // 对应到 InnoDB 的锁类型就是排他锁（X）
    lock_type = F_WRLCK; /* Lock exclusive */
    // 如果以只读方式打开表的数据文件（.ibd）或者
    // lock_type 大于等于 TL_READ(2) 并且
    // lock_type 小于等于 TL_READ_NO_INSERT(5)
    // 则说明是只读操作，加读锁
    // 对应到 InnoDB 的锁类型就是共享锁（S）
    if ((*tables)->db_stat & HA_READ_ONLY ||
        ((*tables)->reginfo.lock_type >= TL_READ &&
         (*tables)->reginfo.lock_type <= TL_READ_NO_INSERT))
      lock_type = F_RDLCK;
    if ((error = (*tables)->file->ha_external_lock(thd, lock_type))) {
      // ha_external_lock() 返回非 0 值
      // 说明执行 ha_external_lock() 方法出现了错误
      // 这里处理善后工作
      ...
      return error;
    } else {
      (*tables)->db_stat &= ~HA_BLOCK_LOCK;
      (*tables)->current_lock = lock_type;
    }
  }
  return 0;
}

lock_external() 会迭代 SQL 中的表，每迭代一个表，都调用 ha_external_lock() 对表进行加锁。

// sql/handler.cc
int handler::ha_external_lock(THD *thd, int lock_type) {
  ...
  MYSQL_TABLE_LOCK_WAIT(PSI_TABLE_EXTERNAL_LOCK, lock_type,
    { error = external_lock(thd, lock_type); })
  ...
}

handler::ha_external_lock() 调用表对应存储引擎的 external_lock() 方法。

对 InnoDB 来说，调用的是 ha_innobase::external_lock()，这个方法的代码比较多，算是个大杂烩，可以分为三类：

  • 加表级别的共享锁、排他锁。

  • 把当前迭代表所属表空间的脏页，同步刷新到磁盘。

  • 一些初始化逻辑（执行快，花费时间极少）。

ha_innobase::external_lock() 的执行时间会计入表锁等待时间，因为其中可能包含同步刷脏页操作、执行一些初始化逻辑花费的时间，所以，表锁等待时间并不纯粹。

对需要加表锁的 SQL 来说，表锁等待时间包含两部分：

  • 加表级别的共享锁、排他锁的等待时间。

  • 执行一些初始化逻辑花费的时间。

如果是 FLUSH TABLES ... WITH READ LOCK 语句，表锁等待时间还包含：把其中涉及的表所属表空间的脏页同步刷新到磁盘所花费的时间。

对不需要加表锁的 SQL 来说，表锁等待时间就是执行 ha_innobase::external_lock() 中一些初始化逻辑花费的时间。

我们来看看 ha_innobase::external_lock() 主要包含哪些代码逻辑，对这部分细节不感兴趣的读者，可以跳过这个小节。

这个小节的代码都来自于 ha_innobase::external_lock()，文件路径 storage/innobase/handler/ha_innodb.cc。

update_thd(thd);

以上代码，创建 InnoDB 的事务对象（trx_t），保存到 server 层的用户线程对象（thd）中。

// lock_type == F_WRLCK，意味着需要加写锁
// 这里用于表示需要记录 binlog
if (lock_type == F_WRLCK &&
    // 表示不支持 STATEMENT 格式的 binlog
    // table_flags() 方法会判断事务隔离级别
    !(table_flags() & HA_BINLOG_STMT_CAPABLE) &&
    // 系统变量 binlog_format = STATEMENT
    // 表示用户需要记录 STATEMENT 格式的 binlog
    thd_binlog_format(thd) == BINLOG_FORMAT_STMT &&
    // 表示需要为当前连接指定的数据库记录 binlog
    // use <db> 或者连接数据库时指定了数据库
    thd_binlog_filter_ok(thd) &&
    // 表示当前执行的 SQL 会产生 ROW 格式的 binlog
    thd_sqlcom_can_generate_row_events(thd)) {
  bool skip = false;
  ...
  if (!skip) {
    ...
    return HA_ERR_LOGGING_IMPOSSIBLE;
  }
}

上面代码的判断条件有点多，我们用一句话来概括一下代码逻辑：

事务隔离级别为 READ_UNCOMMITTED、READ_COMMITTED 时，如果 SQL 会产生 ROW 格式的 binlog，而用户设置系统变量 binlog_format 的值为 STATEMENT，要求记录 STATEMENT 格式的 binlog，ha_innobase::external_lock() 会返回 HA_ERR_LOGGING_IMPOSSIBLE，因为 MySQL 无法处理这样矛盾的场景。

if (lock_type == F_WRLCK) {
  /* If this is a SELECT, then it is in UPDATE TABLE ...
  or SELECT ... FOR UPDATE */
  m_prebuilt->select_lock_type = LOCK_X;
  m_stored_select_lock_type = LOCK_X;
}

InnoDB 读取记录时，会根据 m_prebuilt->select_lock_type 的值确定是否加行锁、加共享锁还是排他锁。

lock_type 等于 F_WRLCK，表示 server 层要求加写锁，对应到 InnoDB 的锁类型，就是排他锁，设置加锁类型为 LOCK_X。

if (lock_type == F_RDLCK) {
  ...
  // 如果当前表是数据字典表
  // 或者被标识为不需要加锁（no_read_locking = true)
  // 设置加锁类型为 LOCK_NONE
  if (m_prebuilt->table->is_dd_table || m_prebuilt->no_read_locking) {
    m_prebuilt->select_lock_type = LOCK_NONE;
    m_stored_select_lock_type = LOCK_NONE;
  // 如果事务隔离级别是可串行化
  } else if (trx->isolation_level == TRX_ISO_SERIALIZABLE &&
    // 并且当前 SQL 还没有确定加锁类型
    m_prebuilt->select_lock_type == LOCK_NONE &&
    // 并且当前事务需要手动提交
    thd_test_options(thd, OPTION_NOT_AUTOCOMMIT | OPTION_BEGIN)) {
    // 设置加锁类型为共享锁
    m_prebuilt->select_lock_type = LOCK_S;
    m_stored_select_lock_type = LOCK_S;
  } else {
    // Retain value set earlier for example via store_lock()
    // which is LOCK_S or LOCK_NONE
    ut_ad(m_prebuilt->select_lock_type == LOCK_S ||
          m_prebuilt->select_lock_type == LOCK_NONE);
  }
}

lock_type 等于 F_RDLCK，表示 server 层要求加读锁，对应到 InnoDB 的锁类型，就是共享锁，分两种情况设置 InnoDB 的加锁类型：

  • 对于 ACL 表，m_prebuilt->no_read_locking 会被设置为 true，表示读取记录时不加锁。

  • 如果事务隔离级别是可串行化，并且当前事务需要手动执行 COMMIT 语句提交，以及还没有确定读取该表记录时加什么类型的行锁，设置 InnoDB 加锁类型为共享锁。

ACL 表用于访问权限控制，包含如下这些表：

  • user
  • db
  • tables_priv
  • columns_priv
  • procs_priv
  • proxies_priv
  • role_edges
  • default_roles
  • global_grants
  • password_history

switch (m_prebuilt->table->quiesce) {
  case QUIESCE_START:
    /* Check for FLUSH TABLE t WITH READ LOCK; */
    if (!srv_read_only_mode && sql_command == SQLCOM_FLUSH &&
        lock_type == F_RDLCK) {
      ...
      row_quiesce_table_start(m_prebuilt->table, trx);
      ...
    }
    break;
  ...
}

只有执行  FLUSH TABLES ... WITH READ LOCK 语句时，才会命中代码中的 case 分支。

row_quiesce_table_start() 会调用 buf_LRU_flush_or_remove_pages()，并把当前加表锁的表所属表空间对象传给该方法，表示把该表空间的脏页刷新到磁盘。

3. 行锁等待时间

我们先来看看对一条记录加行锁的等待时间是怎么计算的。

InnoDB 读取一条记录时，如需加行锁，会调用 sel_set_rec_lock() 进行加锁。

如果其它事务持有该记录的行锁，sel_set_rec_lock() 会返回 DB_LOCK_WAIT，row_search_mvcc() 调用 row_mysql_handle_errors() 处理锁等待逻辑。

row_mysql_handle_errors() 调用 lock_wait_suspend_thread()，行锁等待逻辑由这个方法实现。

// storage/innobase/lock/lock0wait.cc
void lock_wait_suspend_thread(que_thr_t *thr) {
  srv_slot_t *slot;
  trx_t *trx;
  // 声明变量，用于保存行锁等待的开始时间
  std::chrono::steady_clock::time_point start_time;
  ...
  if (thr->lock_state == QUE_THR_LOCK_ROW) {
    srv_stats.n_lock_wait_count.inc();
    srv_stats.n_lock_wait_current_count.inc();
    // 设置行锁等待的开始时间
    start_time = std::chrono::steady_clock::now();
  }
  ...
  // 等待行锁
  os_event_wait(slot->event);
  ...
  // 运行到这里，有两种情况：
  // 1. 锁等待超时
  // 2. 已经获取到行锁
  if (thr->lock_state == QUE_THR_LOCK_ROW) {
    // 用当前时间减去行锁等待的开始时间
    // 就是一条记录的行锁等待时间
    const auto diff_time = std::chrono::steady_clock::now() - start_time;
    ...
    /* Record the lock wait time for this thread */
    // 累加线程的行锁等待时间
    // 保存到 mysql_thd 线程中
    // mysql_thd 是 server 层的线程
    thd_set_lock_wait_time(trx->mysql_thd, diff_time);
    ...
  }
  ...
}

从上面代码可以看到，计算一条记录的行锁等待时间，逻辑比较简单：
先保存当前行锁等待的开始时间，获取到行锁或等待行锁超时之后，再用当前时间减去开始时间，就得到了一条记录的行锁等待时间。

4. 累计时间

一滴水的梦想是终有一天能够汇入大海。

表锁、行锁等待时间的归宿是累加起来，最终成为 lock_time，这个过程是通过调用 thd_set_lock_wait_time() 实现的。

// storage/innobase/handler/ha_innodb.cc
void thd_set_lock_wait_time(THD *thd,
                            std::chrono::steady_clock::duration value) {
  if (thd) {
    thd_storage_lock_wait(
        thd,
        std::chrono::duration_cast<std::chrono::microseconds>(value).count());
  }
}

thd_set_lock_wait_time() 调用 thd_storage_lock_wait() 累加表锁、行锁等待时间。

// sql/sql_thd_api.cc
void thd_storage_lock_wait(MYSQL_THD thd, long long value) {
  thd->inc_lock_usec(value);
}

真正干活的是 THD::inc_lock_usec() 方法。

// sql/sql_class.cc
void THD::inc_lock_usec(ulonglong lock_usec) {
  m_lock_usec += lock_usec;
  MYSQL_SET_STATEMENT_LOCK_TIME(m_statement_psi, m_lock_usec);
}

server 层每获取到一个表锁，都会调用 thd_set_lock_wait_time()，累加表锁等待时间。

最终会调用 THD::inc_lock_usec() 把表锁等待时间累加到 server 层的线程对象 thd 的 m_lock_usec 属性中。

InnoDB 每获取到一条记录的行锁，或者行锁等待超时，都会调用 thd_set_lock_wait_time()，累加行锁等待时间。

最终会调用 THD::inc_lock_usec() 把行锁等待时间累加到 server 层的线程对象 thd 的 m_lock_usec 属性中。

5. lock_time

SQL 执行完成之后，dispatch_command() 调用 log_slow_statement() 记录慢查询到文件中。

log_slow_statement() 也不是真正干活的，经过多级，最终调用 Query_logger::slow_log_write() 记录慢查询到文件中。

// sql/log.cc
bool Query_logger::slow_log_write(THD *thd, const char *query,
                                  size_t query_length, bool aggregate,
                                  ulonglong lock_usec, ulonglong exec_usec) {
  ...
  if (aggregate) {
    query_utime = exec_usec;
    lock_utime = lock_usec;
  } else if (thd->start_utime) {
    query_utime = (current_utime - thd->start_utime);
    lock_utime = thd->get_lock_usec();
  } else {
    query_utime = 0;
    lock_utime = 0;
  }
  ...
  bool error = false;
  for (Log_event_handler **current_handler = slow_log_handler_list;
       *current_handler;) {
    error |= (*current_handler++)->log_slow(
               thd, current_utime,
               (thd->start_time.tv_sec * 1000000ULL) +
               thd->start_time.tv_usec,
               user_host_buff, user_host_len, query_utime,
               lock_utime, is_command, query, query_length);
  }
  ...
}

Query_logger::slow_log_write() 被调用时，参数 aggregate 的值都是 false，上面代码不会进入 if (aggregate) 分支。

if (thd->start_utime) 分支，lock_utime = thd->get_lock_usec()，从当前线程对象（thd）中获取之前累加的表锁、行锁等待时间。

然后，调用 log_slow() 记录慢查询到文件中。

// sql/log.cc
bool Log_to_file_event_handler::log_slow(
    THD *thd, ulonglong current_utime, ulonglong query_start_utime,
    const char *user_host, size_t user_host_len, ulonglong query_utime,
    ulonglong lock_utime, bool is_command, const char *sql_text,
    size_t sql_text_len) {
  if (!mysql_slow_log.is_open()) return false;

  Silence_log_table_errors error_handler;
  thd->push_internal_handler(&error_handler);
  bool retval = mysql_slow_log.write_slow(
      thd, current_utime, query_start_utime, user_host, user_host_len,
      query_utime, lock_utime, is_command, sql_text, sql_text_len);
  thd->pop_internal_handler();
  return retval;
}

Log_to_file_event_handler::log_slow() 最终调用 mysql_slow_log.write_slow() 记录慢查询到文件中。

// sql/log.cc
bool File_query_log::write_slow(...) {
  ...
  if (!thd->copy_status_var_ptr) {
    if (my_b_printf(&log_file,
        "# Query_time: %s  Lock_time: %s"
        " Rows_sent: %lu  Rows_examined: %lu\n",
        query_time_buff, lock_time_buff,
        (ulong)thd->get_sent_row_count(),
        (ulong)thd->get_examined_row_count()) == (uint)-1)
      goto err; /* purecov: inspected */
  }
  ...
}

经常看慢查询日志的读者，想必对这 2 行会非常熟悉：

Query_time: %s  Lock_time: %s
Rows_sent: %lu  Rows_examined: %lu

其中的 Lock_time 就是本文的主题，介绍到这里，总算是和文章标题遥相呼应上了。

6. 总结

Lock_time 由表锁、行锁等待时间相加得到。

表锁等待时间并不纯粹，其中包含执行一些初始化操作花费的时间。

对 FLUSH TABLES ... WITH READ LOCK 语句来说，还包含把其中涉及的表所属表空间的脏页同步刷新到磁盘所花费的时间。

行锁等待时间很纯粹，就是多条记录的行锁等待时间之和，或者一条记录的行锁等待时间。

网站声明：如果转载，请联系本站管理员。否则一切后果自行承担。

本文链接：https://www.xckfsq.com/news/show.html?id=21305
赞同 0
评论 0 条

相关文章

  • Vim 一下日志文件，Java 进程没了？ 2023-11-28 65277 浏览

    一次端口告警，发现java进程被异常杀掉，而根因竟然是因为在问题机器上vim查看了nginx日志。下面我将从时间维度详细回顾这次排查，希望读者在遇到相似问题时有些许启发。时间线15:19收到端口异常odin告警。状态:P1故障名称:应用端口8989指标:data-stream-openapi.port.8989主机:data-stream-openapi-nmg-sf-a9457-1.docker

  • 统信UOS操作系统 | 版本信息查询命令集锦 2023-12-22 67692 浏览

    使用统信UOS操作系统的国产电脑办公，想要知道系统、固件等版本信息时该如何查询？阅读下文，即刻掌握各类版本查询方式及命令。内核版本查询内核版本是指操作系统的核心，它负责管理系统的进程、内存、设备驱动程序、文件和网络系统，决定着系统的性能和稳定性；内核以独占的方式执行最底层任务，保证系统正常运行；协调多个并发进程，管理进程使用的内存，使它们相互之间不产生冲突。不同的设备驱动，软件支持的内核版本不同，

  • SQL 查询总是先从SELECT开始的吗？ 2023-11-30 64222 浏览

    SQL查询的执行顺序于是我研究了一下，发现顺序大概是这样的。SELECT并不是最先执行的，而是在第五个。这张图回答了以下这些问题这张图与SQL查询的语义有关，让你知道一个查询会返回什么，并回答了以下这些问题：可以在GROUPBY之后使用WHERE吗？（不行，WHERE是在GROUPBY之前！）可以对窗口函数返回的结果进行过滤吗？（不行，窗口函数是SELECT语句里，而SELECT是在WHERE和G

  • 统信UOS/麒麟KYLINOS配置日志轮转 2023-11-29 62790 浏览

    1、查看系统信息pdsyw@pdsyw-PC:~/Desktop$cat/etc/os-version[Version]SystemName=UOSDesktopSystemName[zh_CN]=统信桌面操作系统ProductType=DesktopProductType[zh_CN]=桌面EditionName=ProfessionalEditionName[zh_CN]=专业版MajorVe

  • Java实现递归查询树结构的示例代码 2023-11-29 63548 浏览

    我们在实际开发中，肯定会用到树结构，如部门树、菜单树等等。Java后台利用递归思路进行构建树形结构数据，返回给前端，能以下拉菜单等形式进行展示。今天，咱们就来说说怎么样将List集合转换成TreeList我们在实际开发中，肯定会用到树结构，如部门树、菜单树等等。Java后台利用递归思路进行构建树形结构数据，返回给前端，能以下拉菜单等形式进行展示。今天，咱们就来说说怎么样将List集合转换成Tree

  • Linux不停止服务快速清空日志文件（包含所有文件，不光是日志） 2023-11-28 66541 浏览

    以下操作不光是可以清空nohup.log这种日志，而是所有的文件都可以清空，包含txt等。第一种：cat/dev/null>./nohup.log[root@redhat75::~]#ll-htotal216K-rw-------.1rootroot2.0KMay272020anaconda-ks.cfg-rw-r--r--1rootroot41KApr714:00nohup.log#待清空的日志

  • 金仓数据库常用查询语句 2023-11-01 65113 浏览

    查看版本、日期SELECTversion();SELECTcurrent_date;查看角色及用户select*fromsys_user;TEST=#\duselectrolnamefromsys_roles;查看会话进程/数据库连接情况select*fromsys_stat_activity;select*frompg_stat_activity;查询数据库总连接数selectcount(*)f

  • 应对政企多项合规要求，威努特日志审计一步满足 2023-07-11 62473 浏览

    01日志审计需求背景随着网络运营者对网络安全的认识不断增强，网络安全建设工作不断推进，以及《中华人民共和国网络安全法》、等级保护、分级保护以及各行业信息安全管理标准等规范的实施，政企事业单位的网络运营者都迫切需要建设和实施IT设备与系统的日志审计平台，以满足日益严格的合规审计要求。日志记录留存审计是日常信息安全管理中至关重要的环节之一，从庞杂的日志中提取出有价值的信息，满足各类信息安全管理者、参与

  • 【统信】桌面操作系统-如何收集系统日志 2023-07-13 66090 浏览

  • docker基础：docker查看日志用法笔记 2023-12-25 66890 浏览

    大家在平常使用docker的时候，可能会遇到这样或者那样的问题，这个时候想排查问题的时候通常需要查看异常日志，这样才可以快速定位问题，从而解决实际的问题。今天就给大家聊聊Docker查看日志的用法，一起来看看吧！其实Docker查看日志的命令也比较简单就是通过dockerlogs命令。1、Dockerlogs命令格式dockerlogs参数容器名/容器id参数说明：--details显示提供给日志

小阳人
小阳人L0
粉丝 2 发表 28 + 关注 私信
上周热门
银河麒麟添加网络打印机时，出现“client-error-not-possible”错误提示  1447
银河麒麟打印带有图像的文档时出错  1364
银河麒麟添加打印机时，出现“server-error-internal-error”  1150
统信桌面专业版【如何查询系统安装时间】  1072
统信操作系统各版本介绍  1069
统信桌面专业版【全盘安装UOS系统】介绍  1027
麒麟系统也能完整体验微信啦！  984
统信【启动盘制作工具】使用介绍  626
统信桌面专业版【一个U盘做多个系统启动盘】的方法  574
信刻全自动档案蓝光光盘检测一体机  483
本周热议
我的信创开放社区兼职赚钱历程 40
今天你签到了吗？ 27
信创开放社区邀请他人注册的具体步骤如下 15
如何玩转信创开放社区—从小白进阶到专家 15
方德桌面操作系统 14
我有15积分有什么用? 13
用抖音玩法闯信创开放社区——用平台宣传企业产品服务 13
如何让你先人一步获得悬赏问题信息？（创作者必看） 12
2024中国信创产业发展大会暨中国信息科技创新与应用博览会 9
中央国家机关政府采购中心：应当将CPU、操作系统符合安全可靠测评要求纳入采购需求 8
热门标签更多

添加我为好友，拉您入交流群！

请使用微信扫一扫!