GreatSQL 中为什么 Update 不会被锁等待

GreatSQL社区 GreatSQL社区 博客等级 墨衍会员 · AI 创作全网分发 墨衍智能分发 本文由作者通过墨衍一键同步至各平台 1分发平台 1k累计阅读 1.1k平均单平台 已同步平台 优快云 微信公众号 微博 知乎 掘金 百家号 博客园 抖音 小红书 你的文章也可以这样分发 墨衍会员 ¥399起/年，写一次发全网 我也要 码龄5年
关注
原创 最新推荐文章于 2026-10-31 17:23:27 发布 1k 阅读 AI 写同款· GEO 优化 ›
医学图像处理实战：ABIDE数据集获取与预处理全攻略 本文详细介绍了ABIDE数据集的获取与预处理全流程，涵盖官方脚本下载、Nilearn库高效下载、数据预处理与格式转换等关键步骤。ABIDE数据集作为自闭症脑成像研究的重要资源，提供了标准化的功能磁共振成像数据，适合机器学习模型训练。文章还提供了常见问题排查与优化建议，帮助开发者高效处理医学图像数据。 阅读详情

出乎意料的现象

我们有一张测试表 t1，表中有一些数据，当 session1 开启一个事务，并执行了 select for update 操作后仍未提交事务，在并发事务(如 session2)开启事务并行执行一些操作会有不同的锁现象，表现在：

  1. select for update 会出现锁等待
  2. delete 会出现锁等待
  3. update 执行成功，不受影响

为什么 select for update、delete 会出现预期内的锁等待，而 update 不会出现锁等待呢？

问题复现

首先在 test 库中创建一张测试表 t1

greatsql> show create table t1\G;
*************************** 1. row ***************************
       Table: t1
Create Table: CREATE TABLE `t1` (
  `id` int NOT NULL,
  `type_id` int DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin
1 row in set (0.00 sec)

在表中插入原始数据如下

greatsql> select * from t1;
+----+---------+
| id | type_id |
+----+---------+
|  1 |       3 |
|  2 |       3 |
|  3 |       4 |
|  4 |       3 |
|  5 |       4 |
|  6 |       4 |
|  7 |       5 |
|  8 |       5 |
|  9 |       4 |
| 12 |       4 |
| 15 |       4 |
+----+---------+
11 rows in set (0.00 sec)

现在 session1 对表 t1 开启一个事务，并执行select for update操作，保持事务，不执行 commit

greatsql> begin;
Query OK, 0 rows affected (0.02 sec)

greatsql> select * from t1 where type_id=4 for update;
+----+---------+
| id | type_id |
+----+---------+
|  3 |       4 |
|  5 |       4 |
|  6 |       4 |
|  9 |       4 |
| 12 |       4 |
| 15 |       4 |
+----+---------+
6 rows in set (0.02 sec)

模拟并发 session2 开启事务，并发执行操作

greatsql> select * from t1 where type_id=3 for update;
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

greatsql> delete from t1 where type_id=3;
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

greatsql> update t1 set type_id=2 where type_id=3;
Query OK, 3 rows affected (0.01 sec)
Rows matched: 3  Changed: 3  Warnings: 0

现象解答

其实这并非是一个问题，而是 GreatSQL READ COMMITTED 隔离级别下的一种正常现象，具体表现在

当我们使用的是 GreatSQL 的 READ COMMITTED 隔离级别

greatsql> show variables like '%iso%';
+-----------------------+----------------+
| Variable_name         | Value          |
+-----------------------+----------------+
| transaction_isolation | READ-COMMITTED |
+-----------------------+----------------+
1 row in set (0.03 sec)

在 session1 执行 select * from t1 where type=4 for update; 后，由于表 t1 在 type_id 字段上并没有索引，这会导致全表扫描。但是呢，在 GreatSQL 的 READ COMMITTED 隔离级别下会对所有的行进行加锁，找到对应的记录后加锁，会对不符合条件的行释放锁

因此 session1 最后获取了意向排他锁(IX)和 6 条行锁(X,REC_NOT_GAP)，仅仅锁住了 type_id=4 的 6 行记录。

greatsql> select ENGINE_LOCK_ID,ENGINE_TRANSACTION_ID,LOCK_MODE,LOCK_TYPE,INDEX_NAME,OBJECT_SCHEMA,OBJECT_NAME,LOCK_DATA,LOCK_STATUS,THREAD_ID from performance_schema.data_locks;
+-----------------------------------------+-----------------------+---------------+-----------+------------+---------------+-------------+-----------+-------------+-----------+
| ENGINE_LOCK_ID                          | ENGINE_TRANSACTION_ID | LOCK_MODE     | LOCK_TYPE | INDEX_NAME | OBJECT_SCHEMA | OBJECT_NAME | LOCK_DATA | LOCK_STATUS | THREAD_ID |
+-----------------------------------------+-----------------------+---------------+-----------+------------+---------------+-------------+-----------+-------------+-----------+
| 140547538324696:1073:140547436105584    |                  2719 | IX            | TABLE     | NULL       | test          | t1          | NULL      | GRANTED     |        93 |
| 140547538324696:11:4:6:140547436102528  |                  2719 | X,REC_NOT_GAP | RECORD    | PRIMARY    | test          | t1          | 3         | GRANTED     |        93 |
| 140547538324696:11:4:7:140547436102528  |                  2719 | X,REC_NOT_GAP | RECORD    | PRIMARY    | test          | t1          | 5         | GRANTED     |        93 |
| 140547538324696:11:4:8:140547436102528  |                  2719 | X,REC_NOT_GAP | RECORD    | PRIMARY    | test          | t1          | 6         | GRANTED     |        93 |
| 140547538324696:11:4:9:140547436102528  |                  2719 | X,REC_NOT_GAP | RECORD    | PRIMARY    | test          | t1          | 9         | GRANTED     |        93 |
| 140547538324696:11:4:10:140547436102528 |                  2719 | X,REC_NOT_GAP | RECORD    | PRIMARY    | test          | t1          | 12        | GRANTED     |        93 |
| 140547538324696:11:4:11:140547436102528 |                  2719 | X,REC_NOT_GAP | RECORD    | PRIMARY    | test          | t1          | 15        | GRANTED     |        93 |
+-----------------------------------------+-----------------------+---------------+-----------+------------+---------------+-------------+-----------+-------------+-----------+
7 rows in set (0.00 sec)
  1. select for update 会出现锁等待

session2 执行 select * from t1 where type_id=3 for update; 后，由于 type_id 字段没有索引，执行全表扫描，从第一行开始，但是此时 session1 获得的行锁中第一个为 id=3 的记录，因此 session2 获得了 id=1 和 id=2 的行锁，但是当扫描到第三行时（即 id=3 这条记录），这一行已经被 session1 持有了锁，因此 session2 被阻塞了，出现了锁等待。

因此 session2 最后获取了意向排他锁(IX) 和 3 条行锁(X,REC_NOT_GAP)，id=3 这一行的锁被阻塞获取不到。

greatsql> select ENGINE_LOCK_ID,ENGINE_TRANSACTION_ID,LOCK_MODE,LOCK_TYPE,INDEX_NAME,OBJECT_SCHEMA,OBJECT_NAME,LOCK_DATA,LOCK_STATUS,THREAD_ID from performance_schema.data_locks;
+-----------------------------------------+-----------------------+---------------+-----------+------------+---------------+-------------+-----------+-------------+-----------+
| ENGINE_LOCK_ID                          | ENGINE_TRANSACTION_ID | LOCK_MODE     | LOCK_TYPE | INDEX_NAME | OBJECT_SCHEMA | OBJECT_NAME | LOCK_DATA | LOCK_STATUS | THREAD_ID |
+-----------------------------------------+-----------------------+---------------+-----------+------------+---------------+-------------+-----------+-------------+-----------+
| 140547538325504:1073:140547436111664    |                  2726 | IX            | TABLE     | NULL       | test          | t1          | NULL      | GRANTED     |        94 |
| 140547538325504:11:4:2:140547436108560  |                  2726 | X,REC_NOT_GAP | RECORD    | PRIMARY    | test          | t1          | 1         | GRANTED     |        94 |
| 140547538325504:11:4:3:140547436108560  |                  2726 | X,REC_NOT_GAP | RECORD    | PRIMARY    | test          | t1          | 2         | GRANTED     |        94 |
| 140547538325504:11:4:6:140547436108904  |                  2726 | X,REC_NOT_GAP | RECORD    | PRIMARY    | test          | t1          | 3         | WAITING     |        94 |
| 140547538324696:1073:140547436105584    |                  2719 | IX            | TABLE     | NULL       | test          | t1          | NULL      | GRANTED     |        93 |
| 140547538324696:11:4:6:140547436102528  |                  2719 | X,REC_NOT_GAP | RECORD    | PRIMARY    | test          | t1          | 3         | GRANTED     |        93 |
| 140547538324696:11:4:7:140547436102528  |                  2719 | X,REC_NOT_GAP | RECORD    | PRIMARY    | test          | t1          | 5         | GRANTED     |        93 |
| 140547538324696:11:4:8:140547436102528  |                  2719 | X,REC_NOT_GAP | RECORD    | PRIMARY    | test          | t1          | 6         | GRANTED     |        93 |
| 140547538324696:11:4:9:140547436102528  |                  2719 | X,REC_NOT_GAP | RECORD    | PRIMARY    | test          | t1          | 9         | GRANTED     |        93 |
| 140547538324696:11:4:10:140547436102528 |                  2719 | X,REC_NOT_GAP | RECORD    | PRIMARY    | test          | t1          | 12        | GRANTED     |        93 |
| 140547538324696:11:4:11:140547436102528 |                  2719 | X,REC_NOT_GAP | RECORD    | PRIMARY    | test          | t1          | 15        | GRANTED     |        93 |
+-----------------------------------------+-----------------------+---------------+-----------+------------+---------------+-------------+-----------+-------------+-----------+
11 rows in set (0.00 sec)
  1. delete 会出现锁等待

session2 执行 delete from t1 where type_id=3; 后，由于 type_id 字段没有索引，执行全表扫描，从第一行开始，但是此时 session1 获得的行锁中第一个为 id=3 的记录，因此 session2 获得了 id=1 和 id=2 的行锁，但是当扫描到第三行时（即 id=3 这条记录），这一行已经被 session1 持有了锁，因此 session2 被阻塞了，出现了锁等待。

因此 session2 最后获取了意向排他锁(IX) 和 3 条行锁(X,REC_NOT_GAP)，id=3 这一行的锁被阻塞获取不到。

greatsql> select ENGINE_LOCK_ID,ENGINE_TRANSACTION_ID,LOCK_MODE,LOCK_TYPE,INDEX_NAME,OBJECT_SCHEMA,OBJECT_NAME,LOCK_DATA,LOCK_STATUS,THREAD_ID from performance_schema.data_locks;
+-----------------------------------------+-----------------------+---------------+-----------+------------+---------------+-------------+-----------+-------------+-----------+
| ENGINE_LOCK_ID                          | ENGINE_TRANSACTION_ID | LOCK_MODE     | LOCK_TYPE | INDEX_NAME | OBJECT_SCHEMA | OBJECT_NAME | LOCK_DATA | LOCK_STATUS | THREAD_ID |
+-----------------------------------------+-----------------------+---------------+-----------+------------+---------------+-------------+-----------+-------------+-----------+
| 140547538325504:1073:140547436111664    |                  2727 | IX            | TABLE     | NULL       | test          | t1          | NULL      | GRANTED     |        94 |
| 140547538325504:11:4:2:140547436108560  |                  2727 | X,REC_NOT_GAP | RECORD    | PRIMARY    | test          | t1          | 1         | GRANTED     |        94 |
| 140547538325504:11:4:3:140547436108560  |                  2727 | X,REC_NOT_GAP | RECORD    | PRIMARY    | test          | t1          | 2         | GRANTED     |        94 |
| 140547538325504:11:4:6:140547436108904  |                  2727 | X,REC_NOT_GAP | RECORD    | PRIMARY    | test          | t1          | 3         | WAITING     |        94 |
| 140547538324696:1073:140547436105584    |                  2719 | IX            | TABLE     | NULL       | test          | t1          | NULL      | GRANTED     |        93 |
| 140547538324696:11:4:6:140547436102528  |                  2719 | X,REC_NOT_GAP | RECORD    | PRIMARY    | test          | t1          | 3         | GRANTED     |        93 |
| 140547538324696:11:4:7:140547436102528  |                  2719 | X,REC_NOT_GAP | RECORD    | PRIMARY    | test          | t1          | 5         | GRANTED     |        93 |
| 140547538324696:11:4:8:140547436102528  |                  2719 | X,REC_NOT_GAP | RECORD    | PRIMARY    | test          | t1          | 6         | GRANTED     |        93 |
| 140547538324696:11:4:9:140547436102528  |                  2719 | X,REC_NOT_GAP | RECORD    | PRIMARY    | test          | t1          | 9         | GRANTED     |        93 |
| 140547538324696:11:4:10:140547436102528 |                  2719 | X,REC_NOT_GAP | RECORD    | PRIMARY    | test          | t1          | 12        | GRANTED     |        93 |
| 140547538324696:11:4:11:140547436102528 |                  2719 | X,REC_NOT_GAP | RECORD    | PRIMARY    | test          | t1          | 15        | GRANTED     |        93 |
+-----------------------------------------+-----------------------+---------------+-----------+------------+---------------+-------------+-----------+-------------+-----------+
11 rows in set (0.00 sec)

讲到这里，不得不说一下手册权威解释了，在 GreatSQL READ COMMITTED 隔离级别下，手册是这样解释的

对于 update 和 delete 操作 innodb 仅仅会锁住更新和删除行，在 GreatSQL 中根据 where 条件搜索后，会将不满足条件行的行锁进行释放，这样可以很好的降低死锁发生的概率，但也仍然可能发生。

Using READ COMMITTED has additional effects:

  • For UPDATE or DELETE statements, InnoDB holds locks only for rows that it updates or deletes. Record locks for nonmatching rows are released after MySQL has evaluated the WHERE condition. This greatly reduces the probability of deadlocks, but they can still happen.
  • For UPDATE statements, if a row is already locked, InnoDB performs a “semi-consistent” read, returning the latest committed version to MySQL so that MySQL can determine whether the row matches the WHERE condition of the UPDATE. If the row matches (must be updated), MySQL reads the row again and this time InnoDB either locks it or waits for a lock on it.

手册也说明了，对于 update 操作，如果某行被锁后，innodb 会执行 semi-consistent(半一致读)操作，将最新提交的版本返回给 GreatSQL ，以便 GreatSQL 来判断该行是否符合 update 的 where 条件。如果该行匹配（必须更新），GreatSQL 会再次读取该行，并且这一次 innodb 要么锁定它，要么等待它上的锁。

  1. update 执行成功，不受影响

这也就将要说的 session2 执行 update t1 set tpye_id=2 where type=3; 后为什么成功了。 session2 执行 update 后，innodb 会进行半一致读，获取每一行的最新提交版本，然后通过 where 条件过滤，判断该行是否能被锁定，如下图，对于 id=1,id=2 的记录符合 where 条件，可以获取到行锁，对于 id=3 的记录并不符合 where 条件记录，所以 session2 对 id=3 的行不加锁，也就说和 session1 持有的 id=3 的行锁并不冲突。继续后续扫描，对于 id=4 的记录符合 where 条件，可以获取到行锁。直到完成所有的扫描和加锁。

greatsql> select ENGINE_LOCK_ID,ENGINE_TRANSACTION_ID,LOCK_MODE,LOCK_TYPE,INDEX_NAME,OBJECT_SCHEMA,OBJECT_NAME,LOCK_DATA,LOCK_STATUS,THREAD_ID from performance_schema.data_locks;
+-----------------------------------------+-----------------------+---------------+-----------+------------+---------------+-------------+-----------+-------------+-----------+
| ENGINE_LOCK_ID                          | ENGINE_TRANSACTION_ID | LOCK_MODE     | LOCK_TYPE | INDEX_NAME | OBJECT_SCHEMA | OBJECT_NAME | LOCK_DATA | LOCK_STATUS | THREAD_ID |
+-----------------------------------------+-----------------------+---------------+-----------+------------+---------------+-------------+-----------+-------------+-----------+
| 140547538325504:1073:140547436111664    |                  2749 | IX            | TABLE     | NULL       | test          | t1          | NULL      | GRANTED     |        94 |
| 140547538325504:11:4:2:140547436108560  |                  2749 | X,REC_NOT_GAP | RECORD    | PRIMARY    | test          | t1          | 1         | GRANTED     |        94 |
| 140547538325504:11:4:3:140547436108560  |                  2749 | X,REC_NOT_GAP | RECORD    | PRIMARY    | test          | t1          | 2         | GRANTED     |        94 |
| 140547538325504:11:4:4:140547436108560  |                  2749 | X,REC_NOT_GAP | RECORD    | PRIMARY    | test          | t1          | 4         | GRANTED     |        94 |
| 140547538324696:1073:140547436105584    |                  2748 | IX            | TABLE     | NULL       | test          | t1          | NULL      | GRANTED     |        93 |
| 140547538324696:11:4:6:140547436102528  |                  2748 | X,REC_NOT_GAP | RECORD    | PRIMARY    | test          | t1          | 3         | GRANTED     |        93 |
| 140547538324696:11:4:7:140547436102528  |                  2748 | X,REC_NOT_GAP | RECORD    | PRIMARY    | test          | t1          | 5         | GRANTED     |        93 |
| 140547538324696:11:4:8:140547436102528  |                  2748 | X,REC_NOT_GAP | RECORD    | PRIMARY    | test          | t1          | 6         | GRANTED     |        93 |
| 140547538324696:11:4:9:140547436102528  |                  2748 | X,REC_NOT_GAP | RECORD    | PRIMARY    | test          | t1          | 9         | GRANTED     |        93 |
| 140547538324696:11:4:10:140547436102528 |                  2748 | X,REC_NOT_GAP | RECORD    | PRIMARY    | test          | t1          | 12        | GRANTED     |        93 |
| 140547538324696:11:4:11:140547436102528 |                  2748 | X,REC_NOT_GAP | RECORD    | PRIMARY    | test          | t1          | 15        | GRANTED     |        93 |
+-----------------------------------------+-----------------------+---------------+-----------+------------+---------------+-------------+-----------+-------------+-----------+
11 rows in set (0.00 sec)

GreatSQL 就是利用 semi-consistent(半一致读)操作对 update 进行的优化，从而提高并发性。

Enjoy GreatSQL :)

关于 GreatSQL

GreatSQL是适用于金融级应用的国内自主开源数据库，具备高性能、高可靠、高易用性、高安全等多个核心特性，可以作为MySQL或Percona Server的可选替换，用于线上生产环境，且完全免费并兼容MySQL或Percona Server。

相关链接： GreatSQL社区 Gitee GitHub Bilibili

GreatSQL社区：

image

社区有奖建议反馈： https://greatsql.cn/thread-54-1-1.html

社区博客有奖征稿详情： https://greatsql.cn/thread-100-1-1.html

（对文章有疑问或者有独到见解都可以去社区官网提出或分享哦~）

技术交流群：

微信&QQ群：

QQ群：533341697

微信群：添加GreatSQL社区助手（微信号：wanlidbc ）好友，待社区助手拉您进群。

标签
#GreatSQL #MySQL
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
普冉PY32F003定时器实战：从HSE时钟配置到500ms精准闪烁LED（附完整代码） 本文详细解析了普冉PY32F003单片机定时器的实战应用，从HSE时钟配置到实现500ms精准LED闪烁。通过完整的代码示例和深入的技术分析，帮助开发者掌握定时器参数计算、中断优先级管理及调试技巧，适用于各类嵌入式开发项目。 阅读详情

相关推荐

/proc/sys/vm/max_map_count耗尽时，调用glibc 2.11.3 free()导致程序crash，问题追踪和解决

1. 问题 在客户环境下，当我们的程序消耗较大内存时，会偶尔crash。 通过gdb分析，程序core dump在malloc/free函数内。 当把/proc/sys/vm/max_map_count 从65530增加到131070，程序再也不crash。 相关命令 echo 131073 > /proc/sys/vm/max_map_count 2.  core

万大胖博客，苦并快乐着 4430

CentOS 7下GreatSQL安装与MySQL兼容性测试指南

数据库兼容性测试是系统迁移过程中的关键环节，特别是当评估MySQL替代方案时。GreatSQL作为MySQL的重要分支，在高并发事务处理场景中展现出性能优势。本文以CentOS 7环境为例，详细介绍从源码编译安装GreatSQL到完整兼容性测试的全流程，包括系统配置优化、服务管理设置以及常见问题解决方案。通过实际测试案例展示如何验证基础SQL功能、高级特性（如窗口函数和JSON处理）以及权限系统的兼容性，为金融级应用迁移提供可靠参考。内容涵盖性能调优参数配置、sysbench基准测试对比以及使用mysqld

weixin_34088583的博客 286

为什么我的Win11家庭版找不到BitLocker？教你两种强制关闭加密的隐藏方法

本文解释了Win11家庭版为何缺少BitLocker功能，并提供了两种强制关闭加密的隐藏方法。通过注册表修改和PowerShell命令，用户可以调出隐藏的加密控制面板或直接操控加密引擎，解决家庭版设备加密的管理难题。

weixin_42535703的博客 1769

GreatSQL执行Update失败案例分析

业务反馈在应用核心库的用户基本信息表执行部分update命令失败，报错如下： 二 问题分析 经过分析表结构，没有发现异常。 进一步分析对于该表的存储过程、触发器等，发现 xxx.xxx_staffbasicinfo 表上建了8个触发器，其中有包括3个update类型触发器。分析每个update类型触发器，发现xxx.xxx_STAFFBASICINFO_U 触发器作用是在满足指定条件时将xxx.xxx_staffbasicinfo原来记录或者新的记录insert 到xxx.xxx__STAFFBASICIN

GreatSQL2021的博客 989

搞定汽车座椅电机EMC超标：一个PCB滤波板的实战设计与避坑心得

本文详细介绍了汽车座椅电机EMC超标问题的解决方案，通过PCB滤波板的实战设计，解决了传导发射测试超标问题。文章分享了在空间受限条件下的滤波电路架构设计、接地系统优化及迭代验证过程，为汽车直流电机的EMC整改提供了实用方法论。

weixin_30336061的博客 379

【NLP】文献翻译4——CH-SIMS：中文多模态情感分析数据集与细粒度的模态注释

CH-SIMS: A Chinese Multimodal Sentiment Analysis Dataset with Fine-grained Annotations of Modality摘要1. 介绍2. 相关工作2.1 多模态数据集2.2 多模态情感分析2.3 多任务学习3. CH-SIMS 数据集3.1 数据获取3.2 标注3.3 特征提取4. 多模式多任务学习框架4.1 单模态子网4.2 特征融合网络4.3 优化目标5. 实验5.1 基准5.2 实验的细节5.3 结果和讨论5.3.1 与

YoungSeng's Blog 1万+

MySQL 迁移至 GreatSQL 后，timestamp 字段插入报错解析

某业务系统进行国产化适配，将 MySQL的数据迁移到GreatSQL 后，执行 INSERT INTO ,update_time 传参为空时报错，报错信息为：ERROR 1048 (23000): Column 'update_time' cannot be null ，而原来旧的 MySQL 环境中没有这个问题。

ascagawgaf的博客 868

DDR4协议规范之（一）DDR4结构和寻址

DDR4 SDRAM结构和寻址DDR4 SDRAM的封装和寻址新的改变功能快捷键合理的创建标题，有助于目录的生成如何改变文本的样式插入链接与图片如何插入一段漂亮的代码片生成一个适合你的列表创建一个表格设定内容居中、居左、居右SmartyPants创建一个自定义列表如何创建一个注脚注释也是必不可少的KaTeX数学公式新的甘特图功能，丰富你的文章UML 图表FLowchart流程图导出与导入导出导入 DDR4 SDRAM的封装和寻址 你好！ 这是你第一次使用 Markdown编辑器 所展示的欢迎页。如果你想学习

YJFeiii的博客 3万+

MySQL迁移至GreatSQL后，timestamp字段插入报错解析

MySQL 迁移 GreatSQL 后 timestamp 插入报错解析，揭秘版本参数差异，附解决办法与升级注意事项，助您规避兼容问题。

GreatSQL2021的博客 902

Visual studio 2013 配置 Halcon 13 （非抄袭）

Visual studio 2013 配置 Halcon 13.0.2.2 (其他版本适用) 针对网上抄袭的配置方法均不可用，写了一篇亲试可行的配制方法。如下： 1.下载Halcon安装后（C:\Program Files\MVTec\HALCON-13.0） 添加环境变量，（按下win按键，键入“环境变量”，出现 “编辑系统环境变量”后按下enter即可打开，下方找到“环境变量”按钮）的系...

huyanjackson的专栏 1042

Obsidian跨设备同步实战：阿里云OSS与Remotely Save插件配置指南

本文详细介绍了如何利用阿里云OSS对象存储与Remotely Save插件，为Obsidian笔记软件搭建一个低成本、高可靠性的私有化多端同步方案。从创建OSS Bucket、配置CORS规则、生成子账户密钥，到插件安装与多设备同步策略，提供了完整的实战配置指南，有效解决Obsidian用户的跨设备同步痛点。

qsc901234567的博客 1284

Clair v4 指标（Metrics）监控指南：Prometheus 与 OTLP 导出配置详解

Clair v4 内置了完整的可观测性能力，通过独立的 introspection（内省）HTTP 服务，以 Prometheus 格式对外暴露运行指标，并支持通过 OpenTelemetry（OTLP）协议将指标推送至外部采集端。本指南基于官方 [metrics 参考文档](https://link.gitcode.com/i/aa064b1d3f2c9f48c27b680be699b3a2)

gitblog_01038的博客 259

【无标题】ReaxFF拟合参数以及算法安装

ReaxFF拟合参数以及算法安装

zmzyzm的博客 1419

【GreatSQL优化器-02】索引和Sargable谓词

GreatSQL的优化器在有过滤条件的时候，需要先把条件按照是否有索引来进行区分，可以用索引来加速查询的条件称为Sargable，其中arge来源于（搜索参数）的首字母拼成的"SARG"。GreatSQL用索引数组和Sargables数组来储存Sargable谓词，其中Sargable数组是对的补充使用，比如``a<b``条件如果 a 列上建立有索引并且b不是常量，a存入数组，而这个b就存入Sargable数组。因此 Sargable 也可以叫做可索引谓词。Sargable谓词在优化器执行的一开始就通过。

GreatSQL2021的博客 775

Statistics and Machine Learning Toolbox

Statistics and Machine Learning Toolbox（带书签），MATLAB统计学习工具

NTscan扫描工具

ntscan是一个扫描器，可以扫描没有密码和弱密码的共享，先到配置文件中填写猜测的用户名和密码，扫描过程中右侧出现的是扫描日志。

【GreatSQL 优化器 - 13】直方图

从上面直方图创建的步骤我们认识了直方图的类型和创建方法，包括自动和手动两种，以及等宽和等高直方图的区别，学会了查看直方图的桶个数和数据，如果表是一张大表的话，想让样本尽可能多的被抽样，那么系统变量就设置大一点，这样精确度更高，当然相对的更占硬盘资源。下一节讲直方图的应用。

laowangseo1的博客 1338

LinePhone3.2.7(android端最新版本) sip客户端

SIP客户端For android：LinePhone3.2.7(最新版本)，官网地址：http://www.linphone.org/

GreatSQL配置文件my.cnf详解：新手必读的10个关键参数

GreatSQL 是一款开源免费、兼容 MySQL 的数据库，可在普通硬件上满足金融级高可用、高性能、高安全应用场景。对于刚接触 GreatSQL 的新手来说，**my.cnf 配置文件**是最先要掌握的技能——它决定了数据库实例的端口、存储路径、内存占用与性能表现。本文用通俗语言为你详解 my.cnf 中最关键的 10 个参数，帮你少踩坑、快上手。 ## 一、my.cnf 是什么？它在哪里？

gitblog_01097的博客 834

Devexpress16.2.6破解工具

Devexpress16.2.6破解工具Devexpress16.2.6破解工具Devexpress16.2.6破解工具Devexpress16.2.6破解工具

GreatSQL复制中断问题分析与slave_skip_errors参数风险

数据库复制技术是确保数据高可用的核心机制，其基本原理是通过主库的二进制日志(binlog)将数据变更同步到从库。在MySQL及GreatSQL等分支版本中，复制过程涉及IO线程和SQL线程的协同工作，任何环节出错都可能导致数据不一致。slave_skip_errors参数作为控制复制错误处理的关键配置，当其设置为ALL时会跳过所有错误继续复制，虽然能维持复制线程运行，但会带来严重的数据一致性问题。实际运维中，主从复制架构常遇到的binlog过期、GTID空洞等现象，往往与不合理的参数配置有关。通过分析Gre

weixin_29587015的博客 329

ContextMenuManager 右键菜单管理实战：三步整理清爽

整理前，我的右键菜单有 38 个启用项，弹出要 2.5 秒；用 ContextMenuManager 清理后，剩 12 项，0.4 秒。ContextMenuManager 是一款纯粹的 Windows 右键菜单管理程序，能对文件、文件夹、发送到、打开方式、Win+X 等场景的菜单项做启用/禁用、改名、改图标，还能直接定位到对应注册表位置，不用手动翻注册表。 ## ContextMenuMana

gitblog_01084的博客 482

openGauss 迁移到 GreatSQL：DataX 全流程实操指南

DataX 是阿里巴巴开源的异构数据源离线同步工具。它将数据同步过程抽象为 Reader、Framework 和 Writer 三部分：Reader 从源端读取数据，Framework 负责调度和传输，Writer 将数据写入目标端。GreatSQL 完全兼容 MySQL 协议和 MySQL 语法，因此目标端使用 DataX 的插件写入。源端 openGauss 与 PostgreSQL 生态有较高兼容性，但在 JDBC 驱动、数据类型和 SQL 语法上仍需要注意差异。什么是DataX。

TYV5P72P9的博客 235

【GreatSQL优化器-13】直方图

GreatSQL的优化器负责将SQL查询转换为尽可能高效的执行计划，但因为数据环境不断变化有可能导致优化器对查询数据了解不够充足，可能无法生成最优的执行计划进而影响查询效率，因此推出了直方图(histogram)功能来解决该问题。直方图用于统计字段值的分布情况，向优化器提供统计信息。利用直方图，可以对一张表的一列数据做分布统计，估算WHERE条件中过滤字段的选择率，从而帮助优化器更准确地估计查询过程中的行数，选择更高效的查询计划。直方图以灵活的JSON的格式存储。会基于表大小自动判断是否要进行取样操作。

GreatSQL2021的博客 683

【GreatSQL优化器-14】直方图应用

优化器系列第十四篇，全网独家解析代码+例子，深入透彻地理解每一个细节。在本篇中，将聚焦于“直方图应用”。

GreatSQL2021的博客 420
上一篇： Percona Toolkit 神器全攻略（性能类）
下一篇： 通过MySQL Workbench 将 SQL Server 迁移到GreatSQL
点赞 11
评论 0
书签 书签 26
GreatSQL社区
GreatSQL社区
博客等级 码龄5年 1210粉丝 390原创
+ 关注
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值