本文介绍用 dbops 部署 GreatSQL 单机架构，涵盖工具简介、环境信息、下载安装步骤，还可自定义安装目录，快来学习~
dbops 助力 GreatSQL 单机架构安装部署 本文将深入介绍如何运用 dbops 完成 GreatSQL 单机架构的安装部署，无论是数据库新手寻求入门，还是经验丰富的技术人员追求高效操作，都能从中获取有价值的信息，助力构建坚实的数据库基础。 dbops 简介 dbops 是一套基于 Ansible Playbook 的化工具集，专为高效部署生产级数据库及其周边生态而设计。它遵循 “高效
【GreatSQL优化器-18】GROUP_INDEX_SKIP_SCAN 一、GROUP_INDEX_SKIP_SCAN介绍 GreatSQL 优化器的分组索引跳跃扫描（GROUP Index Skip Scan） 是一种优化查询的技术，尤其在联合索引中用于减少扫描的无效行数。group by操作在没有合适的索引可用的时候，通常先扫描整个表提取数据并创建一个临时表，然后按照 group by 指
GreatSQL 为何选择全表扫描而不选索引 1. 问题背景 在生产环境中，发现某些查询即使有索引，也没有使用索引，反而选择了全表扫描。这种现象的根本原因在于优化器评估索引扫描的成本时，认为使用索引的成本高于全表扫描。 2. 场景复现 2.1 环境信息 机器 IP：192.168.137.120 GreatSQL 版本：8.0.32-26 2.2 环境准备 通过脚本创建了一个包含 100 万条
【GreatSQL优化器-17】DYNAMIC RANGE 一、DYNAMIC RANGE介绍 GreatSQL 的优化器有一种扫描方式是动态范围扫描方式，类似于“已读乱回”模式，这种模式是在表有多个索引的情况下，对驱动表连接的时候部分选择索引的情况。优化器没有找到好的索引可以使用，但发现在知道前面表的列值后，可能会使用某些索引。对于前面表中的每个行组合，优化器检查是否可以使用 range 或 i
优化GreatSQL日志文件空间占用 GreatSQL对于日志文件磁盘空间占用，做了一些优化，对于binlog、relay log、slow log和audit log的总空间占用进行了限制，使DBA免除了大量日志生成导致磁盘满的顾虑，极大的方便了数据库磁盘空间管理。 1.binlog二进制日志 binlog_space_limit GreatSQL增加了静态参数 binlog_space_l
【GreatSQL优化器-16】INDEX_SKIP_SCAN 一、INDEX_SKIP_SCAN介绍 GreatSQL 优化器的索引跳跃扫描（Index Skip Scan） 是一种优化查询的技术，尤其在联合索引中用于减少扫描的无效行数。它通过"跳跃"式的扫描方式，避免了对索引中无用部分的扫描，从而提升查询效率。这种技术适合特定场景，并有一定的优缺点。 索引跳跃扫描利用的是联
GreatSQL 8.0.32-27 GA (2025-3-10) 版本信息 发布时间：2025年3月10日 版本号：8.0.32-27, Revision aa66a385910 下载链接：://gitee./GreatSQL/GreatSQL/releases/tag/GreatSQL-8.0.32-27 用户手册：://greatsql.cn/do
GreatSQL5.7 与 8.0 对 DATE 非法值处理方式不同 一、问题描述 1. 问题现象 当分别通过LOAD DATA LOCAL INFILE和INSERT导入非法的 DATE 字段数据时，在5.7.21和 8.0.25使用LOAD DATA LOCAL会报一个Warning，数据异常但可以插入成功，而且实际插入的数据跟用户计划插入的不同，具体是0000-00-00；而使用LOAD D
基于 MySQL 8.0 细粒度授权：单独授予 KILL 权限的优雅解决方案 一、引言 作为一名数据库从业者，我在日常工作中经常会遇到一个棘手的问题：如何在保证安全的前提下，让业务团队拥有足够的权限去管理数据库执行的 SQL，尤其是终止那些失控的慢查询或异常线程？这个问题看似简单，却牵涉到权限设计、安全合规以及数据库稳定性等多方面的权衡。今天，我们就来聊聊 MySQL 8.0 如何通过权限体系的
函数索引触发的一个有趣的问题 导引 听同事提到一个有意思的事情，说在使用GreatSQL时，在navicat客户端和GreatSQL命令行客户端创建的函数索引不能共用，navicat客户端创建的函数索引，在navicat上执行SQL时可以使用，在GreatSQL命令行执行相同的SQL却用不上，反之，在GreatSQL命令行创建的函数索引，在navicat客户端无法使用，这究竟是怎么回事呢？ 问题回
GreatSQL修改配置文件参数无法生效 一、问题描述 客户需要创建无主键表，因提供默认模板设置了参数sql_require_primary_key = ON（创建新表或更改现有表结构的语句强制要求表具有主键），当创建无主键表时会提示ERROR 3750 (HY000): Unable to create or change a table without a primary key, when
【GreatSQL优化器-15】index merge 一、index merge介绍 GreatSQL的优化器的Index Merge Optimization是查询优化器在处理复杂查询时使用的一种高级技术。当查询的 WHERE 子句中有多个独立的条件，且每个条件都可以使用不同的索引时，优化器会尝试将这些索引合并起来，以提高查询效率。这种优化策略允许数据库在一个查询中同时使用多个索引，从而避免全
【GreatSQL优化器-14】直方图应用 一、直方图介绍 GreatSQL的优化器负责将SQL查询转换为尽可能高效的执行计划，但因为数据环境不断变化有可能导致优化器对查询数据了解不够充足，可能无法生成最优的执行计划进而影响查询效率，因此推出了直方图(histogram)功能来解决该问题。 直方图用于统计字段值的分布情况，向优化器提供统计信息。利用直方图，可以对一张表的一列数据做分布统计，估算wh
主从复制中回放慢涉及的表 一、前提 世界千奇百怪，每个人都有自己独立的思想，有些事情即使你附耳告知，也可能如风般吹过，进而消逝，为了性能为了不延迟，表要加索引嘛，然而在某业务场景，业务表数千张，无索引的表几百张，这些表都是上百万的数据。 二、现象 在 GreatSQL 主从架构中，某天在系统资源充足的情况下，主从突然延迟，而且持续增长，我们通过SHOW PROCESSLIST 和 SHOW S
【GreatSQL优化器-13】直方图 一、直方图介绍 GreatSQL的优化器负责将SQL查询转换为尽可能高效的执行计划，但因为数据环境不断变化有可能导致优化器对查询数据了解不够充足，可能无法生成最优的执行计划进而影响查询效率，因此推出了直方图(histogram)功能来解决该问题。 直方图用于统计字段值的分布情况，向优化器提供统计信息。利用直方图，可以对一张表的一列数据做分布统计，估算WHER
【GreatSQL优化器-12】make_tmp_tables_info 一、make_tmp_tables_info介绍 GreatSQL的优化器对于聚合函数和窗口函数需要创建内部临时表来进行计算并输出最后结果，这个内部临时表又需要原始表来作为数据输入源，具体的代码处理在make_tmp_tables_info函数实现。 下面用一个简单的例子来说明make_tmp_tables_info是做什么
加速无索引表引起的主从延迟数据回放 一、场景 由于某些原因，客户现场存在一张 8千万 的大表，而且该表上无任何索引（也无主键），平时该表上 UPDATE 或 DELETE 只操作几条数据。忽然有一天业务进行了某种操作，DELETE 2万 条数据，悲剧发生了，当在主库上执行了之后，传到从库上之后一直回放，当时评估了下可能会回放10天，后来在经过业务同意之后，对表进行操作，用于加速回放日志，处理该问题
数据迁移丨借助 pg2mysql 从 PostgreSQL 到 GreatSQL 上篇《数据迁移丨借助 AI 从 PostgreSQL 到 GreatSQL》介绍了如何使用 AI + pg_dump/COPY 的方式将 PostgreSQL 迁移到 GreatSQL 中，各位同学看过之后，会发现两款数据库还是有一些差异，例如对象层次结构、数据类型等方面，如果采用人工来迁移，还是会比较麻烦，所以本篇
数据迁移丨借助 AI 从 PostgreSQL 到 GreatSQL 本文将介绍如何从 PostgreSQL 到 GreatSQL 的数据迁移，并运用 AI 协助迁移更加方便。迁移的方式有很多，例如： pg_dump：导出SQL文件，修改后导入 GreatSQL 数据库。 COPY：导出txt文本文件，导入 GreatSQL 数据库。 pg2mysql：从 PostgreSQL 迁移到 MyS
【GreatSQL优化器-11】finalize_table_conditions 一、finalize_table_conditions介绍 GreatSQL的优化器在对join做完表排序后，在make_join_query_block函数对表添加条件，添加完条件在finalize_table_conditions会对条件再次进行确认，对ref扫描的条件进行删除，对需要cache的条件进行替换，
【GreatSQL优化器-10】find_best_ref 一、find_best_ref介绍 GreatSQL的优化器对于join的表需要根据行数和cost来确定最后哪张表先执行哪张表后执行，这里面就涉及到预估满足条件的表数据，在keyuse_array数组有值的情况下，会用find_best_ref函数来通过索引进行cost和rows的估计，并且会找出最优的索引。这样就可能不会继续用后面的ca
【GreatSQL优化器-09】make_join_query_block 一、make_join_query_block介绍 GreatSQL优化器对于多张表join的连接顺序在前面的章节介绍过的best_access_path函数已经执行了，接着就是把where条件进行切割然后推给合适的表。这个过程就是由函数make_join_query_block来执行的。 下面用几个简单的例子来说明joi
【GreatSQL优化器-08】statistics和index dives 一、statistics和index_dives介绍 GreatSQL的优化器对于查询条件带有范围的情况，需要根据 mm tree 来估计该范围内大概有多少行，然后以此来计算cost。对于等号条件，给出了两种方法来估计对应行数--Statistics和index dives，前者不精确后者精确，可以通过系统变量eq_ra
使用 gt-checksum 迁移表结构到 GreatSQL 背景 本文以从 ORACLE 迁移到 GreatSQL 为例讲述如何使用 gt-checksum 迁移表结构。 关于gt-checksum gt-checksum是GreatSQL社区开源的一款静态数据库校验修复工具，支持MySQL、Oracle等主流数据库。其商业版本近期新增了表结构迁移功能，如下是一个简单的表结构迁移使用案例。 本
【GreatSQL优化器-07】mm tree 一、mm tree介绍 GreatSQL 的优化器主要用 mm tree 也就是 min-max tree 来确定条件的范围，然后根据不同索引的范围值来计算 cost，选取 cost 最小的索引来执行SQL。 下面用一个简单的例子来说明 mm tree 是什么。 greatsql> CREATE TABLE t1 (c1 INT PRIMARY
DML操作报列不存在？ 背景概述 客户在测试时发现执行某些DML语句时，出现了异常情况，报表不存在或者列不匹配的情况； 我在做数据迁移测试的时候也出现此问题，迁移数据时报 unknow column； 看到这种情况的时候很奇怪，查看表结构时也能看到当前执行的SQL语句涉及的表及列是存在的； 经过排查，最终发现当前这张表涉及触发器，报错的也不是这张表，而是其他表。 问题复现 本次测试基于 Great
【GreatSQL优化器-06】条件过滤导致选择非 一、condition_fanout_filter导致计划非 GreatSQL 的优化器对于 join 的表需要根据行数和 cost 来确定最后哪张表先执行哪张表后执行，这里面就涉及到预估满足条件的表数据，condition_fanout_filter会根据一系列方法计算出一个数据过滤百分比，这个比百分比就是 filtered 系数，这个
Copyright © 2005-2025 51CTO.COM 版权所有 京ICP证060544号
