MySQL update语法SQL解析源码分析

最近在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 bug#1162085, bug#1070856

本文介绍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的一个问题

之前用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

[……]

继续阅读

threadpool大量killed连接无法退出

线上问题

为了提升高并发下MySQL读性能,去年11月底我们在线上部署了threadpool版本的mysql(Percona 5.5.18),threadpool patch来自mariadb 5.5.28,作为只读备库运行了4个多月,一切都很正常,上周有DBA在“show processlist;”时发现存在大量处于killed的连接存在,而且killed状态持续的时间很长。关于threadpool线程调度:mariadb 5.5 threadpool, mysql thread sheduler[……]

继续阅读