分类： Database

背景知识

MySQL的XA分为内部XA和外部XA，采用的协议是经典的2PC(2-Phase-Commit)

MySQL内部XA主要用于多个存储引擎之间的事务处理，由binlog作为Transaction Coordinator，事务提交过程中协调各个参与者（事务存储引擎）prepare，commit/rollback，各个事务存储引擎在prepare阶段基本做完了所有的事情（除了写commit标志，释放资源），对于InnoDB存储引擎，提交一个事务的流程如下：（图片来自登博）

[……]

继续阅读

实验：

a) 系统环境：

$echo $LANG
en_US.UTF-8

CREATE TABLE `t1` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `str` varchar(128) CHARACTER SET utf8 DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB

[……]

继续阅读

问题背景

希望根据MySQL binlog回滚已经提交的事务，一个重要的应用场景：回滚误操作，淘宝智胜在这方面做了很多工作，详情参考利用MySQL日志模拟恢复数据变化轨迹, 利用MySQL日志模拟恢复数据变化轨迹II，最近遇到了一些字符集相关问题，回滚失败。这篇文章旨在分析MySQl binlog中与表操作相关的字符集。

实验测试：

a) 系统字符集，保证能够支持中文

$echo $LANG
en_US.UTF-8

[……]

继续阅读

本分析基于 Percona Server 5.5.18

FLUSH TABLES WITH READ LOCK 作用

1. 对于myisam存储引擎，从数据库外部拷贝.frm，.fyd，.fyi文件后，执行FLUSH TABLES/FLUSH TABLES WITH READ LOCK后，就可以使用新表了，这个功能非常有用，备份变得格外简单
2. mysqldump中从主库中拉出一个副本后通过change master后就可以快速搭建slave，为了获得一个一致性点，一般会使用参数–single-transaction和–master-data，它会使用FLUSH TABLES WITH READ LOCK阻塞事务commit写binlog来获得transaction开始时主库binlog位置
3. 与FLUSH TABLES相似，清空table_cache

除了这几个重要作用外，目前还没有发现其他用处，而且对于InnoDB存储引擎，第一条就没用了
[……]

继续阅读

应用场景：

频繁插入/删除一个表中的数据，没有查询，需要评估InnoDB vs. TokuDB插入性能

TokuDB在开源后获得了大量关注，其采用的fractal tree相对于b+tree有着很好的随机插入性能，而查询性能也不低，How TokuDB Tree Indexes Work中介绍了其基本原理和理论性能公式，感兴趣可以阅读，本文将重点focus在性能数据上。

版本信息

mysql> select @@version;
+-------------------------+
| @@version               |
+-------------------------+
| 5.5.30-tokudb-7.0.1-log |
+-------------------------+
1 row in set (0.00 sec)

测试场景（一）

n个线程并发插入total_records条记录
[……]

继续阅读

知识背景

MySQL中每个SELECT/DML/DDL在执行之前需要打开相关的表，执行结束后将它们关闭，为了避免重复打开/关闭的开销，server层提供了table cache和table definition cache用来缓存打开的表信息，在SELECT/DML/DDL执行之前首先从table cache中取空闲表，cache中没有相应表才真正打开表，执行结束后将表置为空闲并放入到table cache中；关于这部分的代码分析可以参考之前写的一篇博客；同时，table cache与MDL一起控制表的并发访问，这部分内容打算之后总结出一篇博客

innodb实现了dict_sys，在内存中缓存了载入过的表信息，包括表的元数据信息（表名，space，列信息，索引，外键等），还包括运行时的信息（有多少handler打开了该表，表上加锁信息，运行时统计信息），具体可以参考数据结构dict_table_struct
[……]

继续阅读

需求描述

最近开发提了这样一个需求：

BEGIN;
UPDATE products SET quantity=quantity-1 WHERE product_id=123456;
SELECT quantity FROM products WHERE product_id=123456;
COMMIT;

在一个事务中UPDATE之后需要SELECT出更新后的值，希望在MySQL中能只使用一条SQL就能做到，这样既可以方便开发，又可以大大减小事务处理时间，其实这个需求在Oracle/PostgreSQL中已经有相应的语法支持，PostgreSQL UPDATE，实现这个需求还有一个前提：不修改MySQL服务器/客户端协议，能够兼容JDBC
[……]

继续阅读

最近在MySQL中实现了Oracle/PostgreSQL中UPDATE…RETURNING…语法，实现过程中详细分析了update语法SQL解析过程，博客中记一笔

mysql_update调用过程

执行一条update语句的入口，函数参数：

int mysql_update(THD *thd,TABLE_LIST *tables,List<item> &fields,
		 List</item><item> &values,COND *conds,
		 uint order_num, ORDER *order, ha_rows limit,
		 enum enum_duplicates handle_duplicates, bool ignore,
                 ha_rows *updated_return);
</item>

传入参数比较多，重点介绍其中几个：
fields：set左值集合，即需要set的字段集合
values：set右值集合，与fields中的字段一一对应
conds：where字段，想详细了解这部分可以参考orczhou的一篇博客
found_return，found_return：这两个是输出参数，返回根据where条件找到的记录数和实际发生更新的记录数
[……]

继续阅读

本文介绍percona修复的两个binlog cache相关的bug，percona bug#1162085 (mysql bug#66237) 和percona bug#1070856，其中percona bug#1070856是修复percona bug#1162085时引入的

percona bug#1162085

这个bug会导致tmp目录被写满，对于一个写入较大的操作，如LOAD DATA / INSERT large_dataset, 全表UPDATE / DELETE, 事务对应的binlog cache会使用到临时文件（ML开头，类似：/tmp/MLjw4ecJ，用lsof查看，状态为deleted）作为缓冲（IO_CACHE），事务在提交后，binlog_cache_data.truncate函数被被调用，但是此函数只会初始化IO_CACHE中的内存缓冲，临时缓冲文件不做清理，只有在session被关闭时，close_cached_file被调用，IO_CACHE对象被销毁，这种策略设计初衷应该是：session退出之前，临时缓冲文件能够一直被使用；然而会出现一个问题：临时缓冲文件会一直存在，且只会越变越大，如果有很多session一直不退出且执行过很大的操作，就会有tmp目录被写满的风险[……]

继续阅读

之前用sysbench 压测MySQL写入性能时遇到一个问题，同样的两台物理机器 A 和 B，CPU (Intel(R) Xeon(R) CPU E5620 @ 2.40GHz）类型和RAM (24G) 都一样，数据基本都在BP里，不涉及到IO，但是测试出来的性能相差近一倍，测试脚本：

sysbench --test=tests/db/update_index.lua --mysql-host=localhost --mysql-user=root --mysql-db=sbtest 
--oltp-tables-count=20 --oltp-table-size=1000000 --mysql-socket=/u01/mysql/run/mysql.sock 
--max-requests=10000000000 --max-time=600 --num-threads=128 run

[……]

继续阅读