- 博客(356)
- 收藏
- 关注
RSS订阅原创 事务处理对持久统计信息自动收集的影响
本文探讨事务处理对持久统计信息自动收集的影响，通过 INSERT 和 DELETE 测试，发现回滚后统计信息或不匹配，需ANALYZE TABLE修正。
2025-04-02 10:44:25
212
原创 dbops 助力 GreatSQL 单机架构安装部署
本文介绍用 dbops 部署 GreatSQL 单机架构，涵盖工具简介、环境信息、下载安装步骤，还可自定义安装目录，快来学习~
2025-03-28 09:38:49
818
原创 【GreatSQL优化器-18】GROUP_INDEX_SKIP_SCAN
优化器系列第十八篇，全网独家解析代码+例子，深入透彻地理解每一个细节。在本篇中，将聚焦于“GROUP_INDEX_SKIP_SCAN”。
2025-03-26 10:26:12
402
原创 【GreatSQL优化器-17】DYNAMIC RANGE
GreatSQL 的优化器有一种扫描方式是动态范围扫描方式，类似于“已读乱回”模式，这种模式是在表有多个索引的情况下，对驱动表连接的时候部分选择索引的情况。优化器没有找到好的索引可以使用，但发现在知道前面表的列值后，可能会使用某些索引。对于前面表中的每个行组合，优化器检查是否可以使用 range 或 index merge 访问方法来检索行。虽然这不是很快，但比执行完全没有索引的连接要快。下面用一个简单的例子来说明直方图怎么应用在优化器。
2025-03-19 10:09:45
500
原创 优化GreatSQL日志文件空间占用
自动清理旧日志，告别磁盘爆满！通过 binlog/relay log/slow log/audit log 四大空间参数控制，智能管理日志文件总量，DBA 从此无忧。
2025-03-14 11:01:56
835
原创 【GreatSQL优化器-16】INDEX_SKIP_SCAN
优化器系列第十六篇，全网独家解析代码+例子，深入透彻地理解每一个细节。在本篇中，将聚焦于“INDEX_SKIP_SCAN”。
2025-03-12 10:29:02
440
原创 GreatSQL 8.0.32-27 GA (2025-3-10)
新增 Turbo 引擎加速查询，Rapid 引擎内核升级。优化 MGR 事务传输，完善插件，支持 Zstd 压缩提效率。改进兼容性和安全性，修复崩溃、丢数据等问题！
2025-03-10 11:06:58
1036
原创 GreatSQL5.7 与 8.0 对 DATE 非法值处理方式不同
MySQL 8.0 与 5.7 在 DATE 非法值处理上差异显著，本文不仅对比两者表现，还深入探讨成因，为从业者提供实操建议。
2025-03-07 14:05:59
916
原创 基于 MySQL 8.0 细粒度授权：单独授予 KILL 权限的优雅解决方案
MySQL 8.0 权限体系新变革！教你单独授予 KILL 权限，保障安全又灵活，附实战操作与关键要点，速学！
2025-03-05 14:39:42
790
原创 函数索引触发的一个有趣的问题
揭秘字符集差异导致的索引失效现象，解析整型列使用字符函数时的隐式转换陷阱，助开发者规避跨客户端索引兼容性问题，提升数据库查询优化技巧!
2025-02-26 10:25:22
528
原创 GreatSQL修改配置文件参数无法生效
GreatSQL 修改配置文件参数sql_require_primary_key遇失效问题，排查发现持久化影响，取消后重启生效。速来了解！
2025-02-24 10:12:50
501
原创 【GreatSQL优化器-15】index merge
优化器系列第十五篇，全网独家解析代码+例子，深入透彻地理解每一个细节。在本篇中，将聚焦于“index merge”。
2025-02-21 10:37:18
896
原创 【GreatSQL优化器-14】直方图应用
优化器系列第十四篇，全网独家解析代码+例子，深入透彻地理解每一个细节。在本篇中，将聚焦于“直方图应用”。
2025-02-19 10:17:21
307
原创 主从复制中定位回放慢涉及的表
主从架构下的性能问题，突发延迟且持续增长，经排查是 DELETE 事务回放缓慢所致。利用SHOW PROCESSLIST等命令，可定位到回放慢涉及的表，多为无索引且数据量庞大的表，这使得从库回放效率低下
2025-02-17 11:04:39
376
原创 【GreatSQL优化器-13】直方图
GreatSQL的优化器负责将SQL查询转换为尽可能高效的执行计划，但因为数据环境不断变化有可能导致优化器对查询数据了解不够充足，可能无法生成最优的执行计划进而影响查询效率，因此推出了直方图(histogram)功能来解决该问题。直方图用于统计字段值的分布情况，向优化器提供统计信息。利用直方图，可以对一张表的一列数据做分布统计，估算WHERE条件中过滤字段的选择率，从而帮助优化器更准确地估计查询过程中的行数，选择更高效的查询计划。直方图以灵活的JSON的格式存储。会基于表大小自动判断是否要进行取样操作。
2025-02-14 11:20:41
603
原创 【GreatSQL优化器-13】直方图
GreatSQL的优化器负责将SQL查询转换为尽可能高效的执行计划，但因为数据环境不断变化有可能导致优化器对查询数据了解不够充足，可能无法生成最优的执行计划进而影响查询效率，因此推出了直方图(histogram)功能来解决该问题。直方图用于统计字段值的分布情况，向优化器提供统计信息。利用直方图，可以对一张表的一列数据做分布统计，估算WHERE条件中过滤字段的选择率，从而帮助优化器更准确地估计查询过程中的行数，选择更高效的查询计划。直方图以灵活的JSON的格式存储。会基于表大小自动判断是否要进行取样操作。
2025-02-14 11:19:23
722
原创 【GreatSQL优化器-12】make_tmp_tables_info
GreatSQL的优化器对于聚合函数和窗口函数需要创建内部临时表来进行计算并输出最后结果，这个内部临时表又需要原始表来作为数据输入源，具体的代码处理在函数实现。下面用一个简单的例子来说明是做什么的。"items": [},],},},},},"considering_tmp_tables": [ 这里创建临时表"adding_tmp_table_in_plan_at_position": 2, 临时表总是添加在主表之后},"steps": [
2025-02-12 10:18:42
620
原创 数据迁移丨借助 pg2mysql 从 PostgreSQL 到 GreatSQL
pg2mysql 工具是一款开源工具，由 VMware 公司提供，主要用于将数据从 PostgreSQL 迁移至 MySQL 或 GreatSQL。其核心价值在于数据兼容性检查与迁移功能。在实际迁移操作之前，该工具会仔细检查 MySQL/GreatSQL 的表结构与 PostgreSQL 中相应表结构是否兼容。若检测到诸如字段长度不足之类的潜在问题，它会向用户发出提示，以便用户进行修正。pg2mysql 工具主要是用 Go 语言编写的，遵循 Apache - 2.0 许可证。
2025-01-22 09:51:32
625
原创 数据迁移丨借助 AI 从 PostgreSQL 到 GreatSQL
相对 MySQL 及 Percona Server For MySQL 的性能表现更稳定优异，支持 Rapid 引擎、事务无锁化、并行LOAD DATA、异步删除大表、线程池、非阻塞式DDL、NUMA 亲和调度优化 等特性，在 TPC-C 测试中相对 MySQL 性能提升超过 30%，在 TPC-H 测试中的性能表现是 MySQL 的十几倍甚至上百倍。了解数据库直接交互的应用程序、服务、脚本等，分析这些依赖关系，有助于制定迁移计划，和减少对业务的影响。语句的形式导出数据，而不是默认的自定义格式。
2025-01-20 10:03:29
863
原创 数据迁移丨借助 AI 从 PostgreSQL 到 GreatSQL
相对 MySQL 及 Percona Server For MySQL 的性能表现更稳定优异，支持 Rapid 引擎、事务无锁化、并行LOAD DATA、异步删除大表、线程池、非阻塞式DDL、NUMA 亲和调度优化 等特性，在 TPC-C 测试中相对 MySQL 性能提升超过 30%，在 TPC-H 测试中的性能表现是 MySQL 的十几倍甚至上百倍。了解数据库直接交互的应用程序、服务、脚本等，分析这些依赖关系，有助于制定迁移计划，和减少对业务的影响。语句的形式导出数据，而不是默认的自定义格式。
2025-01-20 10:02:55
936
原创 数据迁移丨借助 AI 从 PostgreSQL 到 GreatSQL
相对 MySQL 及 Percona Server For MySQL 的性能表现更稳定优异，支持 Rapid 引擎、事务无锁化、并行LOAD DATA、异步删除大表、线程池、非阻塞式DDL、NUMA 亲和调度优化 等特性，在 TPC-C 测试中相对 MySQL 性能提升超过 30%，在 TPC-H 测试中的性能表现是 MySQL 的十几倍甚至上百倍。了解数据库直接交互的应用程序、服务、脚本等，分析这些依赖关系，有助于制定迁移计划，和减少对业务的影响。语句的形式导出数据，而不是默认的自定义格式。
2025-01-20 10:01:18
959
原创 【GreatSQL优化器-11】finalize_table_conditions
GreatSQL的优化器在对join做完表排序后，在函数对表添加条件，添加完条件在会对条件再次进行确认，对ref扫描的条件进行删除，对需要cache的条件进行替换，生成的条件就是表执行查询最后用的条件。下面用一个简单的例子来说明做什么事情。],},},},},"original_table_condition": "(`t2`.`cc1` = `t1`.`c1`)", 原始添加的条件。
2025-01-15 09:44:57
796
原创 【GreatSQL优化器-10】find_best_ref
GreatSQL的优化器对于join的表需要根据行数和cost来确定最后哪张表先执行哪张表后执行，这里面就涉及到预估满足条件的表数据，在keyuse_array数组有值的情况下，会用find_best_ref函数来通过索引进行cost和rows的估计，并且会找出最优的索引。这样就可能不会继续用后面的calculate_scan_cost()进行全表扫描计算cost，可以节省查询时间。这个功能是对之前【优化器05-条件过滤】的补充功能，二者有可能一起用，也有可能只选择一种计算，要看具体条件。
2025-01-10 10:30:21
628
原创 【GreatSQL优化器-10】find_best_ref
GreatSQL的优化器对于join的表需要根据行数和cost来确定最后哪张表先执行哪张表后执行，这里面就涉及到预估满足条件的表数据，在keyuse_array数组有值的情况下，会用find_best_ref函数来通过索引进行cost和rows的估计，并且会找出最优的索引。这样就可能不会继续用后面的calculate_scan_cost()进行全表扫描计算cost，可以节省查询时间。这个功能是对之前【优化器05-条件过滤】的补充功能，二者有可能一起用，也有可能只选择一种计算，要看具体条件。
2025-01-10 10:22:40
686
原创 【GreatSQL优化器-09】make_join_query_block
GreatSQL优化器对于多张表join的连接顺序在前面的章节介绍过的best_access_path函数已经执行了，接着就是把where条件进行切割然后推给合适的表。这个过程就是由函数make_join_query_block来执行的。下面用几个简单的例子来说明join连接中条件推送是什么。下面这个例子((t1.c1 = t3.ccc1) or (t3.ccc1 < 3))条件推送给t1-> Hash下面例子(t1.c1 < 3)条件推给t1，(ccc1=t1.c1)条件推给t3。
2025-01-08 10:07:12
867
原创 GreatSQL temp文件占用时长分析
GreatSQL是适用于金融级应用的国内自主开源数据库，具备高性能、高可靠、高易用性、高安全等多个核心特性，可以作为MySQL或Percona Server的可选替换，用于线上生产环境，且完全免费并兼容MySQL或Percona Server。GreatSQL DBA在日常工作中可能会遇到这种情况，存在一个 InnoDB 引擎下的 temp_x.ibt 文件很大，但是却无法确定这个文件是什么时间由哪个连接建立的，难以支撑后续定位问题，今天这篇文章彻底讲明白这个问题。那么，这个文件是由那个连接占用的呢？
2025-01-03 10:05:45
903
原创 【GreatSQL优化器-08】statistics和index dives
GreatSQL的优化器对于查询条件带有范围的情况，需要根据 mm tree 来估计该范围内大概有多少行，然后以此来计算cost。对于等号条件，给出了两种方法来估计对应行数和，前者不精确后者精确，可以通过系统变量设置阈值来决定用哪种方法来估计等号条件的行数。对于一条查询 SQL 如果等号条件太多的时候执行会占用较多资源，这时候设置一个合理的阈值改为统计值估计可以有效避免占用过多资源，提升执行效率。名称定义说明Statistics用统计值来估计等号条件的行数，不精确。
2024-12-27 09:59:35
868
原创 使用 gt-checksum 迁移表结构到 GreatSQL
gc-task.cnf是gt-checksum的初始配置文件，内容包括源端目标端DB连接串以及迁移对象列表等信息，位于gt-checksum程序的config-simple目录下，gt-cheksum会根据gc-task.cnf来生成表结构迁移相关配置文件。gc-struct.cnf中部分参数根据gc-task.cnf生成，无需修改，还有部分参数是默认配置，需要根据项目实际情况来修改，此处仅展示表结构迁移过程中部分必改参数，其余参数及其含义见文件内容。本次使用的是 gt-checksum 商业版本。
2024-12-20 10:38:11
647
原创 DML操作报列不存在？
客户在测试时发现执行某些DML语句时，出现了异常情况，报表不存在或者列不匹配的情况；我在做数据迁移测试的时候也出现此问题，迁移数据时报看到这种情况的时候很奇怪，查看表结构时也能看到当前执行的SQL语句涉及的表及列是存在的；经过排查，最终发现当前这张表涉及触发器，报错的也不是这张表，而是其他表。
2024-12-13 09:49:33
644
原创 【GreatSQL优化器-05】条件过滤condition_fanout_filter
GreatSQL 的优化器对于 join 的表需要根据行数和 cost 来确定最后哪张表先执行哪张表后执行，这里面就涉及到预估满足条件的表数据，会根据一系列方法计算出一个数据过滤百分比，这个比百分比就是 filtered 系数，这个值区间在[0,1]，值越小代表过滤效果越好。用这个系数乘以总的行数就可以得出最后需要扫描的表行数的数量，可以大幅节省开销和执行时间。这个功能是由OPTIMIZER_SWITCH_COND_FANOUT_FILTER这个OPTIMIZER_SWITCH来控制的，默认是打开的。
2024-12-06 09:52:53
905
原创 GreatSQL内存消耗异常排查攻略：从系统到应用层面的深入分析
确认内存使用是否超标：结合系统工具与 GreatSQL 内部视图分析。确定具体内存分配模块：通过。
2024-11-29 13:47:44
831
原创 GreatSQL 自动开启复制导致同步报错
目前需要将生产数据恢复到一个单实例，再将单实例和生产节点配置主从关系，由于单表数据量较大，时间比较有限，考虑到导入导出的时间，并且GreatSQL支持XtraBackup备份恢复，能够加速数据的恢复，因此决定使用XtraBackup备份工具进行数据的迁移；在数据恢复完成后进行数据同步，从库发生报错 1062 主键冲突，通过解析relaylog，根据relaylog中的insert记录，以主键id字段为查询条件进行查询，发现从库中存在该条记录；
2024-11-27 10:26:43
1037
原创 【GreatSQL优化器-04】贪婪搜索算法浅析
GreatSQL的优化器用方法来枚举所有的表连接场景，然后从中根据最小cost来决定最佳连接顺序。这里面就涉及每种场景的cost计算方法，不同计算方法会导致不同的排序结果。因为枚举所有join场景，当表数量很大的时候就有可能无穷无尽消耗系统资源，因此GreatSQL执行greedy_search的时候使用和变量（分别对应GreatSQL中的和系统变量），防止无穷无尽的分析各种连接顺序的成本，如果连接表的个数小于，那么就继续穷举分析每一种连接顺序的cost，否则只对与值相同数量的表进行穷举分析。
2024-11-22 10:43:46
780
原创 【GreatSQL优化器-03】查询开销估算
GreatSQL的优化器在创建执行计划的时候是根据每张表的行数和数据分布以及读数据硬盘消耗等信息来判断先查询哪张表后查询哪张表，要不要使用索引，这些表资源信息就被称为cost，俗称为"开销"。在这之前已经执行了（参考【GreatSQL优化器-02】）和（参考【GreatSQL优化器-01】），拿到了信息和表的索引信息，这里就开始计算单张表扫描的开销，做一个初步的估计，用来给后面的搜索最佳表顺序提供原始数据信息。优化器通过函数初步计算单表开销，这个函数最后会计算出3个重要的数据。名称说明计算公式。
2024-11-20 09:46:11
973
原创 【GreatSQL优化器-02】索引和Sargable谓词
GreatSQL的优化器在有过滤条件的时候，需要先把条件按照是否有索引来进行区分，可以用索引来加速查询的条件称为Sargable，其中arge来源于（搜索参数）的首字母拼成的"SARG"。GreatSQL用索引数组和Sargables数组来储存Sargable谓词，其中Sargable数组是对的补充使用，比如``a<b``条件如果 a 列上建立有索引并且b不是常量，a存入数组，而这个b就存入Sargable数组。因此 Sargable 也可以叫做可索引谓词。Sargable谓词在优化器执行的一开始就通过。
2024-11-15 11:19:46
667
原创 5.7 与 8.0 对相同文件的 LOAD DATA 语句结果不同
1.BUG原因MySQL8.0重构定长数据导入出现BUG.同一个数据库会话，多次执行命令，则第n次执行的字符集使用的是n-1次的字符集，当文件的字符集存在不同，例如先后处理GB18030、UTF8字符集的文件就会数据乱码。此问题MySQL官方已证实为BUG（编号115824）2.BUG触发条件触发条件：需同时满足以下三个条件才会触发此bug。1）LOAD DATA2）在同一个连接中，多次执行LOAD DATA命令，且先后处理的文件字符集存在不同（例如GB18030和UTF8）。
2024-11-14 17:51:45
596
原创 【GreatSQL优化器-01】const_table
GreatSQL的优化器主要用JOIN类来进行处理SQL语句的，JOIN类有以下四个table数量相关的成员变量。其中const_tables是optimize最开始就检查并且标识的，因为这样可以把记录最少的表放在执行计划的第一步，在后面的执行计划里面这些const tables是不参与循环遍历和计算的，因此可以减少很多开销。计数名称说明哪个函数进行累加tables该查询语句的所有表的数量，包含物化表和临时表该查询语句的主要表的数量，不包含物化表该查询语句中只有0行或者1行的表数量。
2024-11-08 11:08:01
632
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人