-
编辑 删除
MySQL是否需要设置not null -2
性能方面innodb_stats_method 这个参数会影响表的统计信息收集，影响统计信息的value group,默认值是nulls_equalIf the NULL value group size is much higher than the average non-NULL value group size, this method skews
-
编辑 删除
Performance Schema导致的内存告警
线上处罚了内存告警，分析了下，Performance 内存分配还是有问题的虽然每个container 设置了page_size,page_count，但是这个不是硬性的限制，并发请求高的情况下还是超分内存，导致内存使用增高， page的分配也是没有回收，只是标记，然后新的请求使用。另外的一个问题是临时表的信息也记录到performance schema. 导致非必要的消耗，个人感觉临时表的信息可以
-
编辑 删除
MySQL Buffer Pool Resize Crash分析
MySQL buffer pool在 resize后，导致了crash。 看下日志2023-06-26T03:10:12.510862Z 0 [Warning] InnoDB: A long semaphore wait: --Thread 140516243474176 has wai
-
编辑 删除
MySQL中普通sql与预编译sql 区别
线程在初始化创建的时候，会使用init_sql_alloc分配main_mem_root部分,main_mem_root也是mem_root, 在sql执行时候使用。执行普通的sql,在转发sql后，回进行内存的分配，分配到mem_root中，会先在free列表中查找是否有足够的空间，没有就分配，有就返回分配的地址。调用堆栈如下：mysqld!alloc_root (/Users/xia
-
编辑 删除
MySQL中的自增ID问题
MySQL中的表设置成自增ID，但是业务方使用的时候，会有一些意向不到的问题。问题1业务自增ID从0开始，使用SQL_MODE='NO_AUTO_VALUE_ON_ZERO' 设置后，ID从0开始，这种情况在进行数据迁移，以及数据对比的过程中，可能会触发工具的bug，导致失败问题2创建表时候，手工设置了auto_increment 的值，但是没有数据，然后用备份进行恢复的时候，au
-
编辑 删除
slave_preserve_commit_order 的理解
slave_preserve_commit_order 这个参数文档上说是维持顺序，保持跟master一致，但是这个很容易理解成不能并发的组顺序乱序应用，其实不是，这个是指能并发执行的事务间的乱序。所以这个参数关闭后，从库在并行复制的时候，也会出现“Waiting for dependent transaction to commit“ 状态，这个在压测环境很容易复现slave1 [lo
-
编辑 删除
线上online ddl不生效
遇到了线上集群online ddl不生效的问题，本应该使用inplace的走了copy.看了下代码，一开始看的是is_inplace_alter_imppossible,因为从名字来看就是判断是否能使用inplace的，但是看了一圈，夜没发现什么有用的信息，后面退出来看了mysql_alter_table中的流程，发现也有判断是否使用inplace的逻辑/*
-
编辑 删除
Percona MySQL线程池的问题
MySQL 线程池针对大量连接的情况，减少了连接创建，销毁的开销，但是针对徒增的大流量来说，处理的不是很好，在繁忙的系统上，很容易出现连接打满的情况。而且看代码，里面针对连接限流的处理不是特别好，加大了这种情况的发生static ulonglong microsecond_throttling_interval(thread_group_t *thread_group
-
编辑 删除
MySQL并行复制-源码理解记录
MySQL并行复制中，文章中提到在prepare阶段中的事务是可以并行执行的，那么这里指的处于prepare阶段的事务已经获取了锁，更新了数据文件，就等commit阶段的提交，更新事务状态，释放undo ,锁资源，所以prepare阶段的事务互相之间是不冲突的。看下代码中的顺序，确认下是否是先获取锁，然后在设置prepare状态的。在锁以及设置prepare的函数上设置断点，可以看到，是先执行了设
-
编辑 删除
MySQL中的幂等复制分析
之前遇到复制异常，如果确定没有问题，都是跳过异常事务，最近看到了一个新的复制模式：幂等复制--slave-exec-mode=mode 这个参数默认是strict模式，可以设置成IDEMPOTENT，进入幂等复制模式官方文档中描述，这种模式能抑制duplicate-key and no-key-found errors;下面看下代码中的实现，首先是定义了幂等模式的错误码，对普通的错误码，进行了转
-
编辑 删除
MySQL crash recovery恢复慢分析
mysql中的数据库比较多的时候，异常启动时间很慢l_data/xb_doublewrite 2023-02-10T03:10:13.386776Z 0 [Note] InnoDB: Opened 3 undo tablespaces 2023-02-10T03:10:13.386799Z 0 [Note
-
编辑 删除
MySQL添加自增主键的坑
很多不规范的系统，由于各种各样的原因可能一开始没有主键，后面接手的dba，在推动规范化的时候，可能需要对这些表添加自增主键，在添加自增主键的时候，很可能会踩到这个坑。bug: 92949https://bugs.mysql.com/bug.php?id=92949 ## Use two concurrent connecitons on
-
编辑 删除
MySQL optimze table 遇到唯一索引报错分析
对含唯一索引的表执行optimize table的时候，可能会遇到Optimize table fails with duplicate entry on UNIQUE KEY的错误下面分析下这个错误的原因mysql在执行optimize table的时候，内部会转化成alter table 使用online ddl的方式执行alter table 命令堆栈如下mysqld!mysql_recre
-
编辑 删除
MySQL源码上理解下commit_order writeset writeset_session
主要是尝试从代码上看下sequence_number,last_committed的关系，看下各自分别怎么实现的。每个事务有2个逻辑时钟 @c Transaction_ctx::last_committed and @c Transaction_ctx::sequence_number.并行事务跟踪3种模式enum enum_binlog_transaction_depende
-
编辑 删除
MySQL update一个诡异现象的分析
在数据库月报中的http://mysql.taobao.org/monthly/2022/12/04/ 这个案例中，session3没有更新行，这个问题的原因，我看代码没有分析出来，主要是打断点的时候，第三个session的执行总是打不上断点。主要是想跟踪下第三个回话执行的时候，cursor定位的记录标记成delete的后续处理，想看下mysql究竟是怎么处理的。有大佬感兴趣一起分析下吗
-
编辑 删除
MySQL恢复过程
MySQL的xa recover 过程记录1 首先需要了解的是MySQL在启动的时候，会创建trx_sys，trx_sys_init_at_db_start在该函数中调用trx_lists_init_at_db_start，这个函数会去扫描undo 段，将未提交的事务添加到事务链表in_rw_trx_list中。2 开启binlog xa恢复的过程调用堆栈如下mysqld!ha_recover(s
