MySQL修行 | 老叶茶馆-腾讯云开发者社区

开发者社区

文档建议反馈控制台

最新优惠活动

文章/答案/技术大牛

发布

MySQL修行 | 老叶茶馆

专栏成员

254

文章

234321

阅读量

47

订阅数

慎重升级到MySQL 8.0.38及更高版本（文末附规避风险办法）

日志数据 mysql 测试工程师

昨日，Percona 资深工程师 Marco Tusa 爆料，升级到 MySQL 8.0.38 版本后，当实例中的表个数超过一万个，实例重启后会发生 Crash 而失败，即便是重启时加上 validate_tablespace_paths=OFF 也不行。

2024-07-19

4840

Slave SQL线程与PXB FTWRL死锁问题分析

日志事务线程 sql 备份

144 Coordinator线程分发relay log中事务时发现这个事务不能执行，要等待前面的事务完成提交，所以处于waiting for dependent transaction to commit的状态。145/146线程和备份线程162形成死锁，145线程等待162线程 global read lock 释放，162线程占有MDL::global read lock 全局读锁，申请全局commit lock的时候阻塞等待146线程，146线程占有MDL:: commit lock，因为从库设置slave_preserve_commit_order=1，保证从库binlog提交顺序，而146线程执行事务对应的binlog靠后面，所以等待145的事务提交。最终形成了145->162->146->145的死循环，形成死锁。三个线程相互形成死锁，还是很少见的。 2.2 相关参数为何未生效 --ftwrl-wait-timeout=60　指的是执行FTWRL之前，如果检测到存在长SQL，先等待指定时间（秒），如果超时后还存在长SQL，则备份报错退出。默认为0则表示立即执行。 --ftwrl-wait-threshold=5 指的是执行FTWRL之前，检测长SQL的方法，如果在执行flush前存在已经运行了超过指定时间（秒）的SQL，则将该SQL定义为长SQL，默认60s。 --kill-long-queries_timeout=0 在执行FTWRL后，如果flush操作被阻塞了N秒，则kill掉阻塞它的线程，默认0的情况就是不kill任何阻塞flush的SQL，直到该SQL执行完成。从上面各个参数的解释，不难看出，--ftwrl-wait-*参数是针对执行FTWRL之前的长SQL检测机制，对于已执行FTWRL时无济于事，--kill-long-*参数则是设置默认值0，不起任何作用。 3. 结论与建议

2024-05-27

1030

GreatSQL统计信息维护管理

管理数据索引统计优化

非持久化统计信息的缺点显而易见，数据库重启后如果大量表开始更新统计信息，会对实例造成很大影响，所以目前都会使用持久化统计信息。 2、持久化统计信息在以下情况会被自动更新：

2024-05-18

710

GreatSQL死锁案例分析及扩展解读

事务数据 lock object record

2024-05-18

1060

MySQL复制从库延迟优化思路

事务优化 mysql 变量配置

2、主从延迟常见的原因有哪些？ 1、大事务，从库回放时间较长，导致主从延迟 2、主库写入过于频繁，从库回放跟不上 3、参数配置不合理 4、主从硬件差异 5、网络延迟 6、表没有主键或者索引大量频繁的更新 7、一些读写分离的架构，从库的压力比较大 3、解决主从延迟有哪些方法 1、对于大事务，拆分成小事务 2、开启并行复制 3、升级从库硬件 4、尽量都有主键 4、什么是并行复制，参数有哪些？先回顾MySQL并行复制的路程 a. MySQL5.6 是基于数据库级别的并行复制 slave-parallel-type=DATABASE(不同库的事务，没有锁冲突)

2024-05-09

3170

MySQL复制从库延迟原因深入分析

线程 mysql 事务数据算法

* GreatSQL社区原创内容未经授权不得随意使用，转载请联系小编并注明来源。背景介绍近来一套业务系统，从库一直处于延迟状态，无法追上主库，导致业务风险较大。从资源上看，从库的CPU、IO、网络使用率较低，不存在服务器压力过高导致回放慢的情况；从库开启了并行回放；在从库上执行 SHOW PROCESSLIST 看到没有回放线程阻塞，回放一直在持续；解析relay log日志文件，发现其中并没大事务回放。过程分析现象确认收到运维同事的反馈，有一套从库延迟的非常厉害，提供了SHOW SLAVE STATUS延迟的截图信息

2024-05-08

1690

GreatSQL的多层SP中Cursor的m_max_cursor_index相关BUG分析

max 解决方案开发 bug cursor

一、问题发现在一次开发中在sp中使用多层cursor的时候想知道每层的m_max_cursor_index值分别是多少，以用来做后续开发。于是做了以下的试验，但是发现第一个level=2那层的m_max_cursor_index的值有点问题。注：本次使用的GreatSQL 8.0.32-25 SQL语句示例： greatsql> CREATE TABLE t1 (a INT, b VARCHAR(10)); 以下注释里面是该层sp_pcontext的参数值。 DELIMITER $$ CREATE PROCEDURE processnames() -- level=0，m_max_cursor_index=1+8+1 BEGIN DECLARE nameCursor0 CURSOR FOR SELECT * FROM t1; -- level=1，m_cursor_offset=0，m_max_cursor_index=1+8+1 begin DECLARE nameCursor1 CURSOR FOR SELECT * FROM t1; -- level=2，m_cursor_offset=1，m_max_cursor_index=1+8 ☆问题点 begin DECLARE nameCursor2 CURSOR FOR SELECT * FROM t1; -- level=3，m_cursor_offset=2，m_max_cursor_index=1 DECLARE nameCursor3 CURSOR FOR SELECT * FROM t1; -- level=3，m_cursor_offset=2，m_max_cursor_index=2 DECLARE nameCursor4 CURSOR FOR SELECT * FROM t1; -- level=3，m_cursor_offset=2，m_max_cursor_index=3 DECLARE nameCursor5 CURSOR FOR SELECT * FROM t1; -- level=3，m_cursor_offset=2，m_max_cursor_index=4 end; end; begin DECLARE nameCursor6 CURSOR FOR SELECT * FROM t1; -- level=2，m_cursor_offset=1，m_max_cursor_index=1 end; END $$ DELIMITER ; 首先查看上面的sp的code，可以发现nameCursor6和nameCursor1属于同一层，因此他们的offset值一样。 greatsql> show procedure code processnames; +-----+---------------------------------------+ | Pos | Instruction | +-----+---------------------------------------+ | 0 | cpush nameCursor0@0: SELECT * FROM t1 | | 1 | cpush nameCursor1@1: SELECT * FROM t1 | | 2 | cpush nameCursor2@2: SELECT * FROM t1 | | 3 | cpush nameCursor3@3: SELECT * FROM t1 | | 4 | cpush nameCursor4@4: SELECT * FROM t1 | | 5 | cpush nameCursor5@5: SELECT * FROM t1 | | 6 | cpop 4 | | 7 | cpop 1 | | 8 | cpush nameCursor6@1: SELECT * FROM t1 | | 9 | cpop 1 | | 10 | cpop 1 | +-----+---------------------------------------+ 11 rows in set (6.02 sec) 然后通过debug查看每层 sp_pcontext 的参数值（相关参数值已经在上面标识出），发现第一个level=2的sp_pcontext的m_max_cursor_index值多了很多，预期值应

2024-04-28

1020

源码解析丨一次慢SQL排查之旅

time 日志索引源码 sql

void THD::update_slow_query_status() { if (my_micro_time() > utime_after_lock + variables.long_query_time) server_status | = SERVER_QUERY_WAS_SLOW; } // my_micro_time() 获取当前系统时间点，单位为微妙 // utime_after_lock 为MDL LOCK和row lock等待时间后的时间点，单位为微妙 // variables.long_query_time 慢日志阈值long_query_time * 1000000 ，单位为微妙 // 等价于：my_micro_time() - utime_after_lock > variables.long_query_time // 不包含锁等待时间

2024-04-28

960

面试题：INSERT...t...SELECT s会对s表加锁吗

select 事务数据 insert lock

insert into t2 select * from t1; 这条语句会对查询表 t1 加锁吗？不要轻易下结论。对GreatSQL的锁进行研究之前，首先要确认一下事务的隔离级别，不同的事务隔离级别，锁的表现是不一样的。

2024-04-28

1440

工具分享丨分析GreatSQL Binglog神器

工具排序日志事件事务

事务控制事件涵盖了事务的起始时间、起始位置、结束时间和结束位置。通过这些详细信息，我们能够计算事务的大小，进而评估其是否属于大型事务，以及是否可能引起主从同步的延迟问题，及时发现大事务,可避免复制故障。简介本文分享的神器的名字就叫做binlog_summary，出自陈臣老师的手笔，也是开源的Python脚本文件，开源地址：https://github.com/slowtech/dba-toolkit/blob/master/mysql/binlog_summary.py 下载运行此工具需要有Python环境，若没有python环境请自行下载下载binlog_summary.py脚本，并授权 $ wget https://raw.githubusercontent.com/slowtech/dba-toolkit/master/mysql/binlog_summary.py $ chmod 755 binlog_summary.py 先用./binlog_summary.py -h查看下帮助 $ ./binlog_summary.py -h usage: binlog_summary.py [-h] [-f BINLOG_TEXT_FILE] [--new] [-c {tps,opr,transaction}] [--start START_DATETIME] [--stop STOP_DATETIME] [--sort SORT_CONDITION] [-e] [--limit LIMIT] options: -h, --help show this help message and exit -f BINLOG_TEXT_FILE, --file BINLOG_TEXT_FILE Binlog text file, not the Raw binary file --new Make a fresh start -c {tps,opr,transaction}, --command {tps,opr,transaction} Command type: [tps, opr, transaction],tps: transaction per second, opr: dml per table, transaction: show transaction info --start START_DATETIME Start datetime, for example: 2004-12-25 11:25:56 --stop STOP_DATETIME Stop datetime, for example: 2004-12-25 11:25:56 --sort SORT_CONDITION Sort condition: time or size, you can use it when command type is transaction -e, --extend Show transaction info in detail,you can use it when command type is transaction --limit LIMIT Limit the number of rows to display 其中参数介绍:

2024-04-28

1360

MyCat分库分表实时同步到GreatSQL

索引同步 sql mycat 数据

MyCat作为经典的分库分表中间件，在长时间内被广泛认为是管理超大MySQL数据库集合的有效解决方案。近来接到客户需求，需要将MyCat集群迁移到GreatSQL中，并且在一段时间内需要实时从MyCat中同步数据到GreatSQL中，全量同步数据比较容易操作，增量同步有如下两个棘手的问题：

2024-04-15

1150

被误写入Slave的数据如何恢复到主库

二进制日志数据数据同步同步

在GreatSQL主从复制环境中，有时候可能会出现一些误操作，将本应该写入到主库的数据写入到了从库，导致主从数据不一致，影响数据同步。是否可以将写入从库的数据同步写入主库呢？

2024-04-15

990

MySQL 8.0.26版本升级32版本查询数据为空的跟踪

mysql select set 客户端数据

某业务系统将MySQL 8.0.26升级为 GreatSQL 8.0.32-24 后，某些特定的SQL语句不能查询到数据。经测试 MySQL 8.0.32也存在相同的问题

2024-04-15

1090

SQL优化案例解析：MINUS改写为标量子查询后提升5倍，但还可以再快近百倍

数据优化 sql rows 存储过程

* GreatSQL社区原创内容未经授权不得随意使用，转载请联系小编并注明来源。写在前面(By老叶)从GreatSQL 8.0.32-25版本开始支持Rapid引擎，该引擎使得GreatSQL能满足联机分析（OLAP）查询请求。老叶尝试利用Rapid引擎优化本案例，结果是相当可喜的，对比如下： -SQL执行耗时(秒)Rows_examinedRead_keyRead_nextRead_rnd_nextTmp_tablesTmp_disk_tablesTmp_table_sizesInnoDB_pages_distinct原始SQL9.943230200036368909070210877403112372448181标量子查询改写优化后2.294906728836617308100036382011284368182走Rapid引擎0.11763300001090000 上述测试结果表明：

2024-04-03

1500

关于GreatSQL字符集的总结

系统变量编码服务器客户端

最近的SQL优化工作中经常遇到因字符集或校验规则不一致导致索引使用不了的问题，修改表的字符集或校验规则相当于把表重构，表中数据量大时，处理起来费时费力，希望应用开发者在设计之初时注意到此问题，让后期接手运维的小伙伴少一些负担。

2024-04-02

1020

LOAD DATA中包含NULL导致主从报错结局

数据字符串 data load null

目前需要搭建一个从库，由于单表数据量较大，时间比较有限，考虑到导入导出的时间，并且GreatSQL支持并行load data的功能，能够加速数据的导入，因此决定使用 select into outfile 和 load data 的方式进行数据的迁移；

2024-04-02

1320

GreatSQL登陆Arch Linux之旅

数据库 linux 内核软件系统

Arch Linux是一个轻量、灵活、基于x86-64架构的Linux发行版，遵循K.I.S.S.原则。注重代码正确、优雅和极简主义，期待用户能够愿意去理解系统的操作。

2024-04-02

850

GreatSQL Shell如何接管手动搭建（含仲裁节点）MGR集群

shell 集群进程权限数据

连接 Primary 节点，查看下原来的账户权限情况，对MGR专属账户增加相应授权

2024-04-02

1210

为什么SHOW TABLE STATUS显示Rows少了40%

status table 统计 rows show

测试环境中，有一个表执行 SHOW TABLE STATUS 时看到的 rows 结果总是和真实数量相差了将近40%：

2024-03-12

1520

GreatSQL TPC-H 性能测试报告正式发布！

性能测试测试脚本数据数据库

完整性能测试报告：https://greatsql.cn/docs/8032-25/user-manual/10-optimze/3-3-benchmark-greatsql-tpch-report.html

2024-03-02

970

点击加载更多

社区活动

【纪录片】中国数据库前世今生

穿越半个世纪，探寻中国数据库50年的发展历程

Python精品学习库

代码在线跑，知识轻松学

博客搬家 | 分享价值百万资源包

自行/邀约他人一键搬运博客，速成社区影响力并领取好礼

技术创作特训营·精选知识专栏

往期视频·千货材料·成员作品最新动态