【GreatSQL优化器-01】const_table

GreatSQL vs MySQL性能测试来了,速围观~ 无论ibp(innodb_buffer_pool_size)是否充足,MySQL的性能都远不如GreatSQL。MySQL的性能平均约为GreatSQL的70%(最高84.5%,最低61.7%)。在ibp充分的情况下,随着并发数的增加,MySQL并没有表现出该有的性能提升,反倒掉头向下,可见还是不够稳定。在ibp不够的情况下,GreatSQL开启thread pool性能有所提升;当ibp充足的情况下,区别就不大了。MySQL vs GreatSQL性能数据对比各数据库版本分别为。 阅读详情

【GreatSQL优化器-01】const_table

file

一、const_table介绍

GreatSQL的优化器主要用JOIN类来进行处理SQL语句的,JOIN类有以下四个table数量相关的成员变量。其中const_tables是optimize最开始就检查并且标识的,因为这样可以把记录最少的表放在执行计划的第一步,在后面的执行计划里面这些const tables是不参与循环遍历和计算的,因此可以减少很多开销。

计数名称说明哪个函数进行累加
tables该查询语句的所有表的数量,包含物化表和临时表JOIN::get_best_combination()
primary_tables该查询语句的主要表的数量,不包含物化表JOIN::get_best_combination()
const_tables该查询语句中只有0行或者1行的表数量JOIN::extract_const_tables和JOIN::extract_func_dependent_tables
tmp_tables该查询语句中临时表数量JOIN::make_tmp_tables_info()

下面用一个简单的例子来说明 const_table 是什么。

greatsql> CREATE TABLE t1 (c1 int primary key, c2 varchar(32),date1 datetime);
greatsql> INSERT INTO t1 VALUES (1,'aaa','2021-03-25 16:44:00.123456'),(2,'bbb','2022-03-25 16:44:00.123456'),(3,'ccc','2023-03-25 16:44:00.123456');

# 这里看到以下的type类型是const,说明在优化器看来这是一张const table
greatsql> EXPLAIN SELECT * FROM t1 WHERE c1=1 AND c1<10;
+----+-------------+-------+------------+-------+---------------+---------+---------+-------+------+----------+-------+
| id | select_type | table | partitions | type  | possible_keys | key     | key_len | ref   | rows | filtered | Extra |
+----+-------------+-------+------------+-------+---------------+---------+---------+-------+------+----------+-------+
|  1 | SIMPLE      | t1    | NULL       | const | PRIMARY       | PRIMARY | 4       | const |    1 |   100.00 | NULL  |
+----+-------------+-------+------------+-------+---------------+---------+---------+-------+------+----------+-------+
1 row in set, 1 warning (3.60 sec)

# 这句sql语句最后被处理成以下的语句了,可以看到条件语句被提到前面当做列,最后的条件变为where true了。
greatsql> SHOW WARNINGS;
+-------+------+-------------------------------------------------------------------------------------------------------------+
| Level | Code | Message                                                                                                     |
+-------+------+-------------------------------------------------------------------------------------------------------------+
| Note  | 1003 | /* select#1 */ select '1' AS `c1`,'aaa' AS `c2`,'2021-03-25 16:44:00' AS `date1` from `db1`.`t1` where true |
+-------+------+-------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)
二、const_table标识

const_table的寻找和标识在函数JOIN::extract_const_tables和JOIN::extract_func_dependent_tables进行处理,这两个函数的功能各有不同。用上面的例子来说明。

bool JOIN::make_join_plan() {
  if (!(query_block->active_options() & OPTION_NO_CONST_TABLES)) {
    // Detect tables that are const (0 or 1 row) and read their contents.
    //根据表的统计信息table->file->stats.records直接寻找该值为0或者1的表,并且表的cached_table_flags必须为HA_STATS_RECORDS_IS_EXACT,只有引擎是MyISAM和memory才有这个标志
    if (extract_const_tables()) return true;

    // Detect tables that are functionally dependent on const values.
    // 循环所有剩下的没有被标识的表,找出有索引或者有表依赖的表来标识
    if (extract_func_dependent_tables()) return true;
  }
}

bool JOIN::extract_func_dependent_tables() {
do {
  for (JOIN_TAB **pos = best_ref + const_tables; *pos; pos++) {
    一、遍历每张出现的表,寻找表里已经创建的索引。
    二、判断表有join条件的情况,本次不涉及
    三、判断表有表依赖的情况,本次不涉及
    四、检查表是否可以通过key读取或表仅使用 const ref。
    这里需要排除以下表:
    1. 全文搜索,或
    2. 嵌套外连接的一部分,或
    3. 半连接的一部分,或
    4. 具有大开销的外连接条件。
    5. 被 const 表优化的处理程序阻止。
    6. 将不会被使用,通常是因为它们是流式传输的而不是物化的(请参阅 Query_expression::can_materialize_directly_into_result())。
    7. 位于完整连接的两侧
    // 如果找到表有索引,这里用到的keyuse在之前JOIN::update_ref_and_keys()已经获取到。
    if (eq_part.is_prefix(table->key_info[key].user_defined_key_parts)) {
      // 该索引是唯一索引
      if (table->key_info[key].flags & HA_NOSAME) {
        if (const_ref == eq_part) {
          // 标识该表是const table
          mark_const_table(tab, start_keyuse);
          // 改变table的状态为const
          join_read_const_table(tab, positions + const_tables - 1);
        }
      }
    }
  }
} while ((const_table_map & found_ref) && ref_changed);

以下是实际使用的时候表扫描方式类型汇总,其中JT_CONST和JT_SYSTEM就是我们本章要说明的。JT_SYSTEM类型,这个需要跟JT_CONST区分开,JT_SYSTEM主要是扩展表而不是物理表,JT_SYSTEM表没有索引。JT_SYSTEM类型也会被计入const_tables,详情见下面。

join_type访问方法的类型说明
JT_UNKNOWN无效
JT_SYSTEM表只有一行,比如select * from (select 1)
JT_CONST表最多只有一行满足,比如WHERE table.pk = 3
JT_EQ_REF'=符号用在唯一索引
JT_REF'=符号用在非唯一索引
JT_ALL全表扫描
JT_RANGE范围扫描
JT_INDEX_SCAN索引扫描
JT_FTFulltext索引扫描
JT_REF_OR_NULL包含null值,比如"WHERE col = ... OR col IS NULL
JT_INDEX_MERGE一张表执行多次范围扫描最后合并结果
-- 下面的select 1表类型就是system而不是const。但是select 1这张表的数量也会计入const_tables
greatsql> EXPLAIN SELECT * FROM (SELECT 1);
+----+-------------+------------+------------+--------+---------------+------+---------+------+------+----------+----------------+
| id | select_type | table      | partitions | type   | possible_keys | key  | key_len | ref  | rows | filtered | Extra          |
+----+-------------+------------+------------+--------+---------------+------+---------+------+------+----------+----------------+
|  1 | PRIMARY     | <derived2> | NULL       | system | NULL          | NULL | NULL    | NULL |    1 |   100.00 | NULL           |
|  2 | DERIVED     | NULL       | NULL       | NULL   | NULL          | NULL | NULL    | NULL | NULL |     NULL | No tables used |
+----+-------------+------------+------------+--------+---------------+------+---------+------+------+----------+----------------+
2 rows in set, 1 warning (12.33 sec)
三、实际例子说明

接下来看几个例子来说明上面的代码。

greatsql> CREATE TABLE t2 (c1 int, c3 varchar(32));
greatsql> CREATE index idx1 ON t2(c1);
greatsql> INSERT INTO t2 VALUES (1,'aaa'),(2,'bbb');

-- 非唯一索引不是const table
greatsql> EXPLAIN SELECT * FROM t2 WHERE c1=1 AND c1<10;
+----+-------------+-------+------------+------+---------------+------+---------+-------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref   | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+------+---------+-------+------+----------+-------+
|  1 | SIMPLE      | t2    | NULL       | ref  | idx1          | idx1 | 4       | const |    1 |   100.00 | NULL  |
+----+-------------+-------+------------+------+---------------+------+---------+-------+------+----------+-------+
1 row in set, 1 warning (3.84 sec)

-- 改变c1为primary key,看一下结果。
-- between条件也是唯一条件,因此是const table
-- 这里有个约束条件:BETWEEN的上下界条件值必须一样,才会被判定为const,否则是range
greatsql> EXPLAIN SELECT * FROM t1 WHERE c1 BETWEEN 1 AND 1 AND c1<10;
+----+-------------+-------+------------+-------+---------------+---------+---------+-------+------+----------+-------+
| id | select_type | table | partitions | type  | possible_keys | key     | key_len | ref   | rows | filtered | Extra |
+----+-------------+-------+------------+-------+---------------+---------+---------+-------+------+----------+-------+
|  1 | SIMPLE      | t1    | NULL       | const | PRIMARY       | PRIMARY | 4       | const |    1 |   100.00 | NULL  |
+----+-------------+-------+------------+-------+---------------+---------+---------+-------+------+----------+-------+
1 row in set, 1 warning (0.00 sec)

-- value in后面的值即使最小值和最大值相同也走的范围扫描,不被判定为const table
greatsql> EXPLAIN SELECT * FROM t1 WHERE c1 IN (1,1) AND c1<10;
+----+-------------+-------+------------+-------+---------------+---------+---------+------+------+----------+-------------+
| id | select_type | table | partitions | type  | possible_keys | key     | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-------+------------+-------+---------------+---------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | t1    | NULL       | range | PRIMARY       | PRIMARY | 4       | NULL |    1 |   100.00 | Using where |
+----+-------------+-------+------------+-------+---------------+---------+---------+------+------+----------+-------------+
1 row in set, 1 warning (0.01 sec)

-- 下面的表只有一行,但是由于引擎不是MyISAM或者memory而不被判定为const table
greatsql> CREATE TABLE t3 AS SELECT 1 AS c1;
greatsql> EXPLAIN SELECT * FROM t3 WHERE c1=1;
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | t3    | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    1 |   100.00 | Using where |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
1 row in set, 1 warning (1.91 sec)

-- 下面的表只有一行,由于引擎是MEMORY而被判定为const table
greatsql> CREATE TABLE t5 engine=memory AS SELECT 1 AS c1;
greatsql> EXPLAIN SELECT * FROM t5 WHERE c1=1;
+----+-------------+-------+------------+--------+---------------+------+---------+------+------+----------+-------+
| id | select_type | table | partitions | type   | possible_keys | key  | key_len | ref  | rows | filtered | Extra |
+----+-------------+-------+------------+--------+---------------+------+---------+------+------+----------+-------+
|  1 | SIMPLE      | t5    | NULL       | system | NULL          | NULL | NULL    | NULL |    1 |   100.00 | NULL  |
+----+-------------+-------+------------+--------+---------------+------+---------+------+------+----------+-------+
1 row in set, 1 warning (2.70 sec)

-- 两张表进行join的时候,即使这里t1的顺序在后面,因为在优化器里面被判定为const table,所以顺序被提前到第一位。
greatsql> EXPLAIN SELECT t1.c1,t1.c2 FROM t2,t1 WHERE t1.c1=1 AND t1.c1<10;
+----+-------------+-------+------------+-------+---------------+---------+---------+-------+------+----------+-------------+
| id | select_type | table | partitions | type  | possible_keys | key     | key_len | ref   | rows | filtered | Extra       |
+----+-------------+-------+------------+-------+---------------+---------+---------+-------+------+----------+-------------+
|  1 | SIMPLE      | t1    | NULL       | const | PRIMARY       | PRIMARY | 4       | const |    1 |   100.00 | NULL        |
|  1 | SIMPLE      | t2    | NULL       | index | NULL          | idx1    | 4       | NULL  |    1 |   100.00 | Using index |
+----+-------------+-------+------------+-------+---------------+---------+---------+-------+------+----------+-------------+
2 rows in set, 1 warning (2.70 sec)

greatsql> EXPLAIN FORMAT=TREE SELECT t1.c1,t1.c2 FROM t2,t1 WHERE t1.c1=1 AND t1.c1<10;
+-----------------------------------------------------+
| EXPLAIN                                             |
+-----------------------------------------------------+
| -> Index scan on t2 using idx1  (cost=0.35 rows=1)  |
+-----------------------------------------------------+
1 row in set (40.27 sec)

-- 通过打印堆栈查看当前最佳的排列顺序,可以看到表t1确实被提到第一个了。
Thread 56 "connection" hit Breakpoint 16, JOIN::get_best_combination (this=0x7fff14c6d0f0)
    at /sql/sql_optimizer.cc:3663
3663          for (Table_ref *sj_nest : query_block->sj_nests) {
(gdb) p best_ref[0]->table_ref->table_name
$99 = 0x7fff14c5d660 "t1"
(gdb) p best_ref[1]->table_ref->table_name
$100 = 0x7fff14c5d538 "t2"
四、总结

从上面优化器最早的步骤我们认识了const table的定义和判定方法,可以发现实际运用中const table是可以提高查询速度的。这里面通过唯一索引来定位查找数据是最快的就是因为被判定为const table,在后面的实践里面发现 =(等值查询)、特殊情况下的 BETWEEN 的时候都可以被认为是const table,但是 IN 却不行,因此实际运用的时候尽量不要用IN条件,而多用等值条件 和 特殊条件下的BETWEEN来查询,最好是只用等值条件。

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性能对比测试,带您一同探索数据库的速度差异 在选择适合自己的数据库时,性能是一个至关重要的考虑因素。本文将介绍GreatSQL和MySQL两个常见的关系型数据库,并通过性能测试来比较它们之间的速度差异。除了查询性能之外,我们还可以比较GreatSQL和MySQL在插入和更新操作方面的性能差异。除了查询性能之外,我们还可以比较GreatSQL和MySQL在插入和更新操作方面的性能差异。然后,我们分别在GreatSQL和MySQL中执行了一个查询,并记录了执行时间。然后,我们分别在GreatSQL和MySQL中执行了一个查询,并记录了执行时间。 阅读详情

相关推荐

GreatSQL安装篇

操作系统:CentOS7 CPU:X86_64架构 数据库:GreatSQL-8.0.32-26-Linux-glibc2.17-x86_64.tar.xz。

BUTCHER 1123

GreatSQL是一个国内自主的开源数据库,可替代mysql

此外,GreatSQL社区还提供了MySQL Shell for GreatSQL,这是一个高级客户端和代码编辑器,支持JavaScript和Python脚本功能,以及与MySQL一起使用的API。它可以用来管理数据库,特别是对MGR的支持,可以方便地进行搭建、管理和配置。GreatSQL的架构可以分为连接层、服务层和存储引擎层。连接层负责与客户端建立连接,服务层是GreatSQL的核心,包括连接器、分析器、优化器、执行器等,而存储引擎层则负责数据的存储和提取。

地球空间 3193

GreatSQL数据库8.0快速安装部署

本文介绍了GreatSQL数据库在Linux系统上的安装配置流程。主要内容包括:1)系统兼容性检查和环境准备;2)关闭SELinux和防火墙;3)安装依赖包;4)创建安装目录并上传安装包;5)解压和安装RPM包;6)配置数据目录权限;7)初始化数据库并获取临时密码;8)修改配置文件;9)启动服务并修改密码;10)创建远程访问用户。最后还说明了如何使用Navicat客户端连接数据库。整个流程详细说明了从安装到配置的完整步骤。

m0_61389590的博客 707

技术干货 | 图文结合带你搞懂GreatSQL体系架构

所有的数据,数据库、表的定义,表的每一行的内容,索引,都是存在 文件系统上,以文件的方式存在的,并完成与存储引擎的交互。服务层是GreatSQL Server的核心,主要包含连接器、分析器、优化器、执行器等,涵盖 GreatSQL 的大多数核心服务功能,以及所有的内置函数(如日期、时间、数学和加密函数等),所有跨存储引擎的功能都在这一层实现,比如存储过程、触发器、视图等。GreatSQL数据库区别于其他数据库的一个特点就是其可插拔的表存储引擎,特别需要注意的是,存储引擎是基于表的,而不是数据库。

GreatDB的博客 437

Ubuntu系统下搭建QtCreator开发环境详细过程(Qt简介;Linux下安装QtCreator;Ubuntu安装后闪退蓝屏的解决方法)

Qt 是一个跨平台的 C++开发库。主要用来开发图形用户界面 (Graphical User Interface,简称 GUI) 程序。Qt 支持的操作系统有很多,例如通用操作系统 Windows、Linux、Unix、智能手机系统Android、ios、WinPhone, 嵌入式系统 QNX、VxWorks 等。

分享学习成长历程,Winter is coming! 8564

【RTOS】 Vxworks 653 第一章 —— 初识 vx653 3.x

。。不是很重要,自己搜吧鲁棒分区是一种确保共享计算资源中独立运行功能实现​​时空隔离​​的机制,其目标是为集成模块中的混合临界性应用提供与联邦式部署(federated implementation)同等级别的功能隔离保障。具体表现为:​​多关键性共存​​:支持不同安全等级应用(如飞控系统A级与娱乐系统D级)在同一模块中协同运行。​​抗干扰能力​​:防止未授权或意外的时空干扰(如内存越界、时间窗口冲突),确保应用间互不影响。​​。

qq_38183694的博客 1280

CentOS7安装GreatSQL

GreatSQL 数据库是一款 开源免费 数据库,可在普通硬件上满足金融级应用场景,具有 高可用、高性能、高兼容、高安全 等特性,可作为 MySQL 或 Percona Server for MySQL 的理想可选替换。

落的博客 1701

Vensim系统动力学建模实战:从理论到仿真优化【案例详解】

本文详细介绍了Vensim在系统动力学建模中的实战应用,从基础理论到仿真优化全面解析。通过人口增长、供应链库存优化等典型案例,展示如何利用Vensim构建动态模型并进行参数优化,帮助读者掌握系统动力学建模的核心技术与实践技巧。

weixin_29231725的博客 477

GreatSQL体系架构的了解

通过学习《图文结合带你搞懂GreatSQL体系架构》,能对GreatSQL的基本底层原理有所了解。一张经典的体系架构图,图1_GreatSQL5.7 版本体系架构图由此可以发现,GreatSQL5.7由以下几部分组成,连接池组件系统管理和控制工具SQL接口组件查询解析器查询优化器缓存组件可插拔存储引擎系统和日志文件GreatSQL数据库区别于其他数据库的一个特点就是其可插拔的表存储引擎,特别需要注...

bisal的专栏 409

C# HttpClient 实战:3步绕过Cloudflare指纹拦截,获取完整网页内容

本文详细介绍了如何使用C# HttpClient绕过Cloudflare指纹拦截,获取完整网页内容的3步实战方案。通过完美复制浏览器请求头、智能管理Cookie容器以及处理动态挑战页面,开发者可以有效突破Cloudflare的反爬机制,适用于爬虫开发和数据采集项目。

weixin_31856057的博客 320

maxwell 平面变压器仿真(一)

在学习开关电源设计的时候,我们难免要设计变压器,采用有限元仿真软件MAXWELL 可以帮助我们确定变压器的励磁电感,漏感等参数。对于我们的理论分析大有裨益。但是苦于这破软件的教程真的是相当的零散,我相信大家用起来也总是苦于没有系统的教程指导,撰写本文的目的有两个,一个是记录自己使用的一些问题,一个是给大家提供一个可以参考的文档。

qq_45405656的博客 8246

探索卓越性能:GreatSQL - 高效数据库解决方案

探索卓越性能:GreatSQL - 高效数据库解决方案 项目简介 是一个开源的、高性能的关系型数据库管理系统,它源自 MySQL 的 Percona Server for MySQL 分支,并在此基础上进行了一系列优化和增强,旨在提供更优秀的事务处理能力、更高的并发性能以及更好的大数据处理能力。 技术分析 性能提升 GreatSQL 在 MySQL 的基础上,针对 InnoDB 存储引擎进行了深度...

gitblog_00021的博客 645

VS2010“未能正确加载包”问题解决方法小汇

本文按照由简至繁的顺序详述了借助网络获知的四种解法,主要面向重装 VS2010 后遭遇题述问题的网友,相关包尤指 VSTS、RadLangSvc、Language、Bootstrap 及 MicrosoftDataEntityDesign。

虚有其表的博客 1万+

MariaDB 和 GreatSQL 性能差异背后的真相

最近项目上遇到了两次 MariaDB 和 GreatSQL 的对比,GreatSQL受到客户质疑,最后经过排查抓到性能差异背后的真相。基于此做个分享。无论是问题一中的100倍性能背后还是插入hang住,其实背后都是对产品的不了解,MariaDB 10.3.39其实对应的是5.7的产品,而且其本身的默认参数调整有作弊嫌疑,默认关闭binlog ,sync_binlog设置为0,checkpoint阈值降低,提高checkpoint的频率等设置,面向测试环境数据是很好看的,但是增加了生产环境的风险和硬件成本。

GreatSQL2021的博客 1668

基于深度学习的灰度图像气泡群识别与优化

灰度图像气泡群深度学习识别优化研究 本研究针对MATLAB实现的深度学习气泡群识别系统在从1445个点到4992个点扩展时出现的精度不稳定问题,提出了一套完整的解决方案。文章首先分析了问题根源,包括数据复杂度增加、类别不平衡、网络容量不足等因素,然后系统性地提出了数据预处理增强、网络架构优化、训练策略调整和后处理算法改进等优化措施。通过改进的U-Net架构、自适应直方图均衡化等技术创新,有效提升了模型在大规模气泡群图像上的识别精度和稳定性,为化工、生物医学等领域的灰度图像分析提供了可靠的技术支持。

max500600的博客 412

手把手完整实现STM32+ESP8266+MQTT+阿里云服务器+手机APP应用——第一节—阿里云物联网平台配置+IoTStudio界面绘制+MQTT.fx模拟MQTT客户端与使用AT命令发布订阅消息

通过MQTT.fx模拟连接以及通过CH340串口连接ESP8266发送AT命令,实现阿里云物联网平台发送数据同时接收数据,IOT studio界面显示数据。具体来说:使用ESP8266(本系列使用了ESP8266-ESP01/01S以及正点原子的ATK-ESP8266) 来连接网络,获取设备数据发送到阿里云物联网平台并显示数据,通过IOT studio界面显示数据并发送命令控制设备。本系列使用的主控芯片是STM32F103系列,当然也可以使用其他系列单片机都可以实现,思路都是一样的。同时本系列有手机APP源

嵌入式阿齐Archie 5万+

腾讯 GreatSQL 全链路实战:从国产化选型到 MGR 集群部署

【摘要】GreatSQL是由腾讯主导开发的开源MySQL分支数据库,基于MySQL 8.0内核深度优化,完全兼容MySQL协议与语法,特别适配国产信创环境。其核心优势包括:增强的MGR高可用架构,支持仲裁节点避免脑裂;性能较原生MySQL提升30%;提供国密加密等安全特性;完美适配鲲鹏、飞腾等国产CPU及麒麟、统信等操作系统。安装部署支持二进制包方式,配置与MySQL高度一致,同时针对MGR集群进行了优化预设。GreatSQL的零代码迁移特性使其成为金融、政务等领域替代Oracle/MySQL的理想选择,特

一火的专栏 842

jre9下载 jdk9

(Java SE Runtime Environment 9.0) 9.0u175 官方最新版 【x86|x64】

图文解读MySQL/GreatSQL体系架构

*GreatSQL社区原创内容未经授权不得随意使用,转载请联系小编并注明来源。往期系列回顾图文结合系列之带你搞懂MySQL日志系列很多小伙伴使用了GreatSQL,但是对GreatSQL的底层原理还不是很了解,今天就带大家一起揭开GreatSQL体系架构的神秘面纱!首先来回顾一张经典的体系架构图:图1_GreatSQL5.7 版本体系架构图由此可以发现,GreatSQL5.7 由以下几部分组成连...

老叶茶馆 520

锂电池充电器电路设计 里面有电路

锂电池充电器电路设计 里面有电路 3.7V升压到5V电路设计。

IDEA的使用指南

IDEA基于java的使用手册,可以最快速的上手,在使用中不断的丰富自己的使用技巧.

关于GreatSQL字符集的总结

最近的SQL优化工作中经常遇到因字符集或校验规则不一致导致索引使用不了的问题,修改表的字符集或校验规则相当于把表重构,表中数据量大时,处理起来费时费力,希望应用开发者在设计之初时注意到此问题,让后期接手运维的小伙伴少一些负担。GreatSQL的字符集和校验规则种类繁多,提供灵活性的同时,也带来使用混乱的烦恼。本文对字符集做一个总结,让读者对GreatSQL的字符集有一个全面的了解。

GreatSQL2021的博客 1143

ssm框架搭建

这个是一个在idea上成功跑起来的ssm框架项目,保存在这里方便以后使用直接下载

面向金融级应用的GreatSQL正式开源

本文首发于 GreatSQL社区 微信公众号。经过几个月的紧张筹备,GreatSQL宣布正式开源。GreatSQL是源于Percona Server的分支版本,除了Percona Serv...

老叶茶馆 510

GreatSQL单机环境安装

《国产数据库之-GreatSQL》介绍了万里的GreatSQL数据库,在这篇文章中,我们尝试搭建一个单机版的环境。GreatSQL是源于Percona Server的分支版本,因此从整体安装的流程上,和MySQL基本一致。1. 下载安装文件可以从这个链接,下载对应平台的安装文件,如果是CentOS,可以选择GreatSQL-8.0.25-15-Linux-glibc2.1...

bisal的专栏 2843

快速上手 GreatSQL 8.0.32-25 with openEuler 24.03 LTS

GreatSQL 针对MGR进行了大量改进和提升工作,新增支持地理标签、仲裁节点、读写节点可绑定动态IP、快速单主模式、智能选主,并针对流控算法、事务认证队列清理算法、节点加入&退出机制、recovery机制等多项MGR底层工作机制算法进行深度优化,进一步提升优化了MGR的高可用保障及性能稳定性。GreatSQL 数据库是一款开源免费数据库,可在普通硬件上满足金融级应用场景,具有高可用、高性能、高兼容、高安全等特性。查看一些基础信息,如操作系统的版本,内核版本,语言设定等。

少安事务所 1792

GreatSQL优化技巧:半连接(semijoin)优化

GreatSQL的 IN 子查询适用于半连接时,优化器提供了5种优化策略:Table pullout、FirstMatch、LooseScan、Duplicate weedout、materialize。

GreatSQL2021的博客 957

GreatSQL 深度解析:金融级开源数据库全攻略

GreatSQL 是国内开源数据库生态中的一颗明珠。价值说明高可用不再是痛点MGR 深度优化 + greatdb_ha VIP 自动漂移,搭建企业级高可用集群门槛大幅降低HTAP 一体化Rapid + Turbo 双引擎,让同一套数据库同时支撑交易和分析,无需额外维护 OLAP 系统Oracle 迁移利器广泛的 Oracle 语法兼容,让存量 Oracle 应用向开源迁移有了可行路径安全合规开箱即用国密 SM4、审计、脱敏、备份加密,满足金融、政务等行业的合规要求零迁移成本。

qyq88888的专栏 788

GreatSQL 8.0.25-16初体验

*GreatSQL社区原创内容未经授权不得随意使用,转载请联系小编并注明来源。1. 准备工作1.1 下载RPM包1.2 准备YUM源2. 初始化安装2.1 各节点安装RPM包2.2 初始化Primary节点2.3 初始化Secondary 和 Arbitrator 节点3、搭建MGR集群体验GreatSQL 8.0.25-16各个新特性。在刚刚发布的GreatSQL 8.0.25-16中,主打以...

老叶茶馆 751

GreatSQL源码架构解析:从SQL解析到存储引擎的执行之旅

当你向 GreatSQL 发送一条简单的 SQL 语句,比如 `SELECT * FROM orders WHERE user_id = 10086`,它究竟经历了怎样的旅程?GreatSQL 源码架构解析,带你深入这条从客户端连接、SQL 解析、查询优化,到存储引擎落盘执行的完整链路。GreatSQL 作为一款开源免费、可在普通硬件上满足金融级应用场景的数据库,其源码基于 MySQL 8.4 深

gitblog_00775的博客 275
上一篇: MySQL 8.0 执行COUNT()很慢原因分析
下一篇: 5.7 与 8.0 对相同文件的 LOAD DATA 语句结果不同
GreatSQL社区
博客等级 码龄5年 1210粉丝 390原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明:

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

余额充值