November 2014

一个Innodb 事务可见性问题

最近碰到的一个innodb事务可见性的问题,以前没关注过,周末过下代码,顺便记录下。 假定如下表: CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 INT, c3 INT, key(c2)); 原创文章,转载请注明: 转载自Simple Life 本文链接地址: 一个Innodb 事务可见性问题 Post Footer automatically generated by wp-posturl plugin for wordpress.

MySQL 5.7: 短连接优化

尽管比较罕见,但某些场景还是存在着短连接,即用户执行完请求后,很快断开会话。伴随着频繁创建/销毁连接的过程。 官方博客: http://mysqlserverteam.com/improving-connectdisconnect-performance/ 对应worklog: http://dev.mysql.com/worklog/task/?id=6606 在之前的版本中, THD/NET/VIO总是由接受连接请求的线程来完成,如果是长连接这没有问题,但如果都是短连接的话,就会应先main线程接受新连接请求的效率,在WL#6606中,THD和NET的初始化被移动到worker线程来完成。 0. background 增加新目录sql/conn_handler,定义了大量的类来处理连接部分的逻辑。下图简单描述了下各个类的关系,可能不是很全面,只涉及linux平台下面比较常用的类. 原创文章,转载请注明: 转载自Simple Life 本文链接地址: MySQL 5.7: 短连接优化 Post Footer automatically generated by wp-posturl plugin for wordpress.

MySQL 5.7: 数据库THD连接管理重构

在WL#6407中,其目的是为了解决shutdown mysql实例的问题,不过主要的代码修改却是重构了对数据库连接相关的管理代码重构。本文的目的主要是梳理这些相关的新增代码。 原创文章,转载请注明: 转载自Simple Life 本文链接地址: MySQL 5.7: 数据库THD连接管理重构 Post Footer automatically generated by wp-posturl plugin for wordpress.

MySQL 5.7.5: 新语法WAIT_FOR_EXECUTED_GTID_SET 及存在的问题

Worklog: http://dev.mysql.com/worklog/task/?id=7796 官方博客:http://mysqlhighavailability.com/wait_for_executed_gtid_set/ 根据worklog的描述,该特性主要是为了解决WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS的缺点: #该功能依赖于slave来运行,如果复制线程没有启动或者出错了,就会返回错误。在某些情况下我们需要一直等待; #返回的是执行的事件的个数,这通常是没有意义的,返回成功或者失败即可。 引入新的语法: WAIT_FOR_EXECUTED_GTID_SET(GTID_SET [, TIMEOUT]) 当GTID_SUBSET(GTID_SET, @@global.gtid_executed)成立时,即指定的GTID是gtid_executed的子集时,返回0表示成功,否则返回1,表示失败。 原创文章,转载请注明: 转载自Simple Life 本文链接地址: MySQL 5.7.5: 新语法WAIT_FOR_EXECUTED_GTID_SET 及存在的问题 Post Footer automatically generated by wp-posturl plugin for wordpress.

MySQL 5.7.5 : GTID_EXECUTED系统表

Gtid是从5.6开始推出的杀手级特性,通过GTID特性,极大的提升了主备切换的效率和一致性,想了解GTID内部实现的朋友可以参阅我之前写的这篇博客:http://mysqllover.com/?p=594 在MySQL5.7.5里引入了一个新的系统表GTID_EXECUTED: root@mysql 11:29:40>SHOW CREATE TABLE mysql.gtid_executed\G *************************** 1. row ***************************        Table: gtid_executed Create Table: CREATE TABLE `gtid_executed` (   `source_uuid` char(36) NOT NULL COMMENT ‘uuid of the source where the transaction was originally executed.’,   `interval_start` bigint(20) NOT NULL COMMENT ‘First number of interval.’,   `interval_end` bigint(20) NOT NULL COMMENT ‘Last […]

MySQL 5.7.5: Buffer Pool 转储、恢复 以及存在的问题

MySQL提供了一个比较有用的功能,能够把buffer pool LRU上的block对应的page id 和space id 存储到文件中。在重启时,会自动读取这个转储文件,然后把对应的<space id, page id>读入到buffer pool中,快速预热内存,以尽快提供服务。 参数 使用该特性比较简单,通过多个参数控制. 简单说下几个参数 原创文章,转载请注明: 转载自Simple Life 本文链接地址: MySQL 5.7.5: Buffer Pool 转储、恢复 以及存在的问题 Post Footer automatically generated by wp-posturl plugin for wordpress.

MySQL 5.7: Innodb 事务子系统优化

MySQL5.7 : Innodb 事务子系统优化 之前写了篇博客介绍了Percona Server对Read View的优化,顺带简单提到了MySQL5.7的事务子系统优化,详细见http://mysqllover.com/?p=834 。 另外一篇博客http://mysqllover.com/?p=1087  也有所涉及。 本文总体介绍了几个和事务子系统相关的worklog以及其代码实现。这部分代码值得细读,因为他们是5.7 Innodb比较核心的改动,极大的提升了只读场景下的性能。 原创文章,转载请注明: 转载自Simple Life 本文链接地址: MySQL 5.7: Innodb 事务子系统优化 Post Footer automatically generated by wp-posturl plugin for wordpress.

MySQL 5.7: Page Cleaner的刷脏问题

之前我已经写过一篇博客,讨论过在flush LRU_LIST/FLUSH_LIST时,5.7对其做的优化,总的来说,就是使用类似Hazard Pointer的方式,避免在flush的过程中重复扫描LIST,将时间复杂度从O(N*N)下降到了O(N)。有兴趣的同学可以翻阅下这篇博客:http://mysqllover.com/?p=1031 本文的目的主要是补充下5.7目前所做的多个page cleaner的实现思路,社区相关的bug讨论,以及我近期对page cleaner所做的一些优化工作。 支持多个Page cleaner 为了提升扩展性和刷脏效率,在5.7.4版本里引入了多个page cleaner线程。从而达到并行刷脏的效果。 原创文章,转载请注明: 转载自Simple Life 本文链接地址: MySQL 5.7: Page Cleaner的刷脏问题 Post Footer automatically generated by wp-posturl plugin for wordpress.

MySQL 5.7 : 索引创建优化(Bulk Load)

先来看一组测试数据 使用sysbench,生成一张大约10,000,000行记录的表,数据全部在buffer pool中 创建索引(k,pad) 5.7.5 alter table sbtest1 add key(k,pad); Query OK, 0 rows affected (44.14 sec) Records: 0  Duplicates: 0  Warnings: 0 5.7.4 root@sbb 04:25:11>alter table sbtest1 add key(k,pad); Query OK, 0 rows affected (1 min 2.03 sec) Records: 0  Duplicates: 0  Warnings: 0 几轮测试的结果都差不多,5.7.5的索引创建速度总是优于5.7.4(同时也优于5.6). 原创文章,转载请注明: 转载自Simple Life 本文链接地址: MySQL 5.7 : 索引创建优化(Bulk Load) […]

MySQL table cache的分区方式

今天在跑高压力高并发下只读查询时,发现个比较有意思的小问题 先来看看performance schema root@performance_schema 03:13:45>SELECT COUNT_STAR, SUM_TIMER_WAIT, AVG_TIMER_WAIT, EVENT_NAME FROM events_waits_summary_global_by_event_name where COUNT_STAR > 0 and EVENT_NAME like ‘wait/synch/%’ order by SUM_TIMER_WAIT desc limit 20; +————-+——————+—————-+—————————————————+ | COUNT_STAR | SUM_TIMER_WAIT | AVG_TIMER_WAIT | EVENT_NAME | +————-+——————+—————-+—————————————————+ | 794349716 | 9217250429384944 | 11603268 | wait/synch/mutex/sql/LOCK_table_cache | | 395819330 | 8052052171747844 | 20342452 | wait/synch/rwlock/sql/LOCK_grant | | […]