<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[追风刀·丁奇]]></title><description><![CDATA[]]></description><link>https://blog.youkuaiyun.com/iteye_621</link><language>zh-cn</language><generator>https://blog.youkuaiyun.com/</generator><copyright><![CDATA[Copyright &copy; iteye_621]]></copyright><item><title><![CDATA[各版本MySQL并行复制的实现及优缺点]]></title><link>https://blog.youkuaiyun.com/iteye_621/article/details/82646511</link><guid>https://blog.youkuaiyun.com/iteye_621/article/details/82646511</guid><author>iteye_621</author><pubDate>Tue, 19 Jan 2016 18:02:20 +0800</pubDate><description><![CDATA[
 
MySQL并行复制已经是老生常谈，笔者从2010年开始就着手处理线上这个问题，刚开始两三年也乐此不疲分享，现在再提这个话题本来是难免“炒冷饭”嫌疑。
 
 最近触发再谈这个话题，是因为有些同学觉得“5.7的并行复制终于彻底解决了复制并发性问题”, 感觉还是有必要分析一下。大家都说没有银弹，但是又期待银弹。。
 
既然要说5.7的并行复制，干脆顺手把各个版本的并行复制都说明一下，也...]]></description><category></category></item><item><title><![CDATA[一个mysqldump导出失败的案例分析]]></title><link>https://blog.youkuaiyun.com/iteye_621/article/details/82581605</link><guid>https://blog.youkuaiyun.com/iteye_621/article/details/82581605</guid><author>iteye_621</author><pubDate>Tue, 03 Jun 2014 23:16:03 +0800</pubDate><description><![CDATA[
 背景

MySQL全量逻辑备份恢复最基础的方法，就是mysqldump生成文本，再通过source 命令直接导入。一般用于实例迁移或者版本升级。
这里说明最近碰到的一个失败例子。

描述

这个例子可以简要复现如下，在源库上执行如下操作:
use mydb;
create table t1 (id int);
create view v1 as select * from ...]]></description><category></category></item><item><title><![CDATA[MySQL 聚集UDF，计算列表中的奇数总和]]></title><link>https://blog.youkuaiyun.com/iteye_621/article/details/82581478</link><guid>https://blog.youkuaiyun.com/iteye_621/article/details/82581478</guid><author>iteye_621</author><pubDate>Mon, 02 Jun 2014 23:08:50 +0800</pubDate><description><![CDATA[
 
 技痒之作 -__-
 
 CREATE AGGREGATE FUNCTION oddsum returns INTEGER SONAME &quot;udf_oddsum.so&quot;;
CREATE TABLE `v1` (
  `c` int(11) DEFAULT NULL,
  `id` int(11) NOT NULL,
  PRIMARY KEY (`id`)
) ENGIN...]]></description><category></category></item><item><title><![CDATA[autocommit=0引起的业务hang住]]></title><link>https://blog.youkuaiyun.com/iteye_621/article/details/82580555</link><guid>https://blog.youkuaiyun.com/iteye_621/article/details/82580555</guid><author>iteye_621</author><pubDate>Sun, 25 May 2014 17:53:48 +0800</pubDate><description><![CDATA[
背景
有用户报告一个普通的select 语句被hang住了，执行超时。查明之后发现是autocommit使用不当导致。
这里将case简化，说明复现步骤及原因。

复现
session1 建表并插入数据：

create table if not exists t(id int primary key, c int);
set autocommit=0;
insert int...]]></description><category></category></item><item><title><![CDATA[一个用户SQL慢查询分析，原因及优化]]></title><link>https://blog.youkuaiyun.com/iteye_621/article/details/82580383</link><guid>https://blog.youkuaiyun.com/iteye_621/article/details/82580383</guid><author>iteye_621</author><pubDate>Fri, 23 May 2014 03:25:37 +0800</pubDate><description><![CDATA[
问题描述
一个用户反映线上一个SQL语句执行时间慢得无法接受。SQL语句看上去很简单（本文描述中修改了表名和字段名):
SELECT count(*)  FROM  a  JOIN  b ON  a.`S` = b.`S` WHERE a.`L` &amp;gt; '2014-03-30 00:55:00' AND a.`L` &amp;lt; '2014-03-30 01:00:00' ; 

且查...]]></description><category></category></item><item><title><![CDATA[一个用户迁移数据库前后的性能差异case]]></title><link>https://blog.youkuaiyun.com/iteye_621/article/details/82580203</link><guid>https://blog.youkuaiyun.com/iteye_621/article/details/82580203</guid><author>iteye_621</author><pubDate>Wed, 21 May 2014 14:21:34 +0800</pubDate><description><![CDATA[
 问题 
一个用户问题，数据从ECS迁移到RDS，相同的语句，查询性能下降了几十倍。而实际上RDS这个实例在内存上的配置与原来ECS上的实例相当。
本文简单说明这个case的原因及建议。

用户反馈性能变慢的语句为 （修改了真实表名和列名）
select count(1)  from HR hr join H h on h.hid = hr.hid 
join A e on  e....]]></description><category></category></item><item><title><![CDATA[MySQL一个异常查询问题追查]]></title><link>https://blog.youkuaiyun.com/iteye_621/article/details/82579766</link><guid>https://blog.youkuaiyun.com/iteye_621/article/details/82579766</guid><author>iteye_621</author><pubDate>Fri, 16 May 2014 12:38:26 +0800</pubDate><description><![CDATA[
问题
线上碰到的问题：相同的语句，只是最后的limit行数不同。奇怪的是，limit 10 的性能比limit 100的语句还慢约10倍。

隐藏用户表信息，语句及结果如下
SELECT  f1 , SUM(`f2`) `CNT` FROM T  WHERE f1 IS NOT NULL AND f3 = '2014-05-12'     GROUP BY f1 ORDER BY `C...]]></description><category></category></item><item><title><![CDATA[Webscalesql代码浏览记录]]></title><link>https://blog.youkuaiyun.com/iteye_621/article/details/82575117</link><guid>https://blog.youkuaiyun.com/iteye_621/article/details/82575117</guid><author>iteye_621</author><pubDate>Thu, 03 Apr 2014 18:28:04 +0800</pubDate><description><![CDATA[
浏览了下webscalesql 的代码。目前包含的62个commit分类如下。
 

目前还没有能够体现”webscale”特征的代码，不过从roadmap上看，fb回头会继续把一些大动作加进来，可以期待。
本文先简要说明一下当前分支中一些有趣的代码。
 
关于代码洁癖
Steaphan Greene (@fb)同学的代码洁癖从多达二十几个关于testcase和编译参数调整的co...]]></description><category></category></item><item><title><![CDATA[Webscalesql代码浏览记录]]></title><link>https://blog.youkuaiyun.com/iteye_621/article/details/82575116</link><guid>https://blog.youkuaiyun.com/iteye_621/article/details/82575116</guid><author>iteye_621</author><pubDate>Thu, 03 Apr 2014 18:27:33 +0800</pubDate><description><![CDATA[
浏览了下webscalesql 的代码。目前包含的62个commit分类如下。
 

目前还没有能够体现”webscale”特征的代码，不过从roadmap上看，fb回头会继续把一些大动作加进来，可以期待。
本文先简要说明一下当前分支中一些有趣的代码。
 
关于代码洁癖
Steaphan Greene (@fb)同学的代码洁癖从多达二十几个关于testcase和编译参数调整的com...]]></description><category></category></item><item><title><![CDATA[Webscalesql代码浏览记录]]></title><link>https://blog.youkuaiyun.com/iteye_621/article/details/82575115</link><guid>https://blog.youkuaiyun.com/iteye_621/article/details/82575115</guid><author>iteye_621</author><pubDate>Thu, 03 Apr 2014 18:27:24 +0800</pubDate><description><![CDATA[
浏览了下webscalesql 的代码。目前包含的62个commit分类如下。
 

目前还没有能够体现”webscale”特征的代码，不过从roadmap上看，fb回头会继续把一些大动作加进来，可以期待。
本文先简要说明一下当前分支中一些有趣的代码。
 
关于代码洁癖
Steaphan Greene (@fb)同学的代码洁癖从多达二十几个关于testcase和编译参数调整的com...]]></description><category></category></item><item><title><![CDATA[MySQL Q&A 解析binlog的两个问题]]></title><link>https://blog.youkuaiyun.com/iteye_621/article/details/82574663</link><guid>https://blog.youkuaiyun.com/iteye_621/article/details/82574663</guid><author>iteye_621</author><pubDate>Mon, 31 Mar 2014 17:18:54 +0800</pubDate><description><![CDATA[
连续碰到两个同学问类似的问题，必须要记录一下。
 
问题：
    一个作解析binlog应用的同学发现不论用utf8还是gbk来解析binlog都可能会碰到无法解析的语句，因为有些用户会用utf8，有些用gbk。尤其在处理Query类型的SQL语句中的中文字符，比如建表语句中的中文注释。
     于是他想到用mysqlbinlog来看看binlog里面的内容。
     Mysql...]]></description><category></category></item><item><title><![CDATA[mymysql与go-mysql-driver的一个区别]]></title><link>https://blog.youkuaiyun.com/iteye_621/article/details/82567894</link><guid>https://blog.youkuaiyun.com/iteye_621/article/details/82567894</guid><author>iteye_621</author><pubDate>Thu, 23 Jan 2014 21:16:42 +0800</pubDate><description><![CDATA[
今天要写个工具就想顺便学下go。网上翻了下发现用比较多的是mymysql和go-mysql-driver。
  这两个驱动网上比较的文章也有些了，不过都没有提到一个点，个人觉得是很重要的，记录一下。
  
       先看使用go-mysql-driver的例子。



   db,_:=sql.Open(&quot;mysql&quot;,connect_string)
   db.Query(...]]></description><category></category></item><item><title><![CDATA[MySQL-Transfer2.3发布]]></title><link>https://blog.youkuaiyun.com/iteye_621/article/details/82551806</link><guid>https://blog.youkuaiyun.com/iteye_621/article/details/82551806</guid><author>iteye_621</author><pubDate>Sun, 01 Dec 2013 21:17:40 +0800</pubDate><description><![CDATA[
Transfer 2.3发布，下载地址
 
此版本除了升级based版本外
*优化了无索引表的同步性能
*优化了slave模式下超大事务内存消耗问题
*Transfer模式相关的功能改动较多
*修复transfer模式下超大事务可能同步失败的bug
 
由于有两个公司的同学在使用5.5.31，因此该版本的改动也同时backport到5.5.31，下载地址
版本说明
1、   ...]]></description><category></category></item><item><title><![CDATA[关于MySQL count(distinct) 逻辑的另一个bug]]></title><link>https://blog.youkuaiyun.com/iteye_621/article/details/82551381</link><guid>https://blog.youkuaiyun.com/iteye_621/article/details/82551381</guid><author>iteye_621</author><pubDate>Thu, 28 Nov 2013 09:59:53 +0800</pubDate><description><![CDATA[
背景
         上一篇博文(链接)介绍了count distinct的一个bug。解决完以后发现客户的SQL语句仍然返回错误结果(0), 再查原因，发现了另外一个bug。也就是说，这个SQL语句触发了两个bug -_-
 
这里只说第二个，将问题简化后复现如下，影响已知的所有版本 。
 


drop table if exists tb;
set tmp_table_si...]]></description><category></category></item><item><title><![CDATA[Is it a bug in MySQL or in java-connector？]]></title><link>https://blog.youkuaiyun.com/iteye_621/article/details/82549848</link><guid>https://blog.youkuaiyun.com/iteye_621/article/details/82549848</guid><author>iteye_621</author><pubDate>Tue, 19 Nov 2013 13:58:47 +0800</pubDate><description><![CDATA[
Description
         In mysql-connector-java-5.1.27, the charset utf8mb4 is supported. But the steps and result bellow looks buggy.
1、  set character_set_server=gbk in my.cnf
2、  start mysql
3、  ...]]></description><category></category></item><item><title><![CDATA[关于MySQL count(distinct) 逻辑的一个bug]]></title><link>https://blog.youkuaiyun.com/iteye_621/article/details/82549499</link><guid>https://blog.youkuaiyun.com/iteye_621/article/details/82549499</guid><author>iteye_621</author><pubDate>Sat, 16 Nov 2013 22:56:16 +0800</pubDate><description><![CDATA[ 背景
 
         客户报告了一个count(distinct)语句返回结果错误，实际结果存在值，但是用count(distinct)统计后返回的是0。
         将问题简化后复现如下，影响已知的所有版本。
 


drop table if exists tb;
set tmp_table_size=1024;
create table tb(id int au...]]></description><category></category></item><item><title><![CDATA[MySQL-Transfer2.2发布]]></title><link>https://blog.youkuaiyun.com/iteye_621/article/details/82515180</link><guid>https://blog.youkuaiyun.com/iteye_621/article/details/82515180</guid><author>iteye_621</author><pubDate>Tue, 18 Jun 2013 12:08:42 +0800</pubDate><description><![CDATA[
Transfer 2.2发布。下载地址
 
版本说明
1、  基于版本 Percona-5.5.31 ，简单用法是先安装好官方或PS版5531，然后替换为transfer的mysqld。
2、  新增观察参数 Com_ts_*
在压测过程中，可使用如下命令观察
mysqladmin --socket=run/mysql.sock -uroot   extended-status --...]]></description><category></category></item><item><title><![CDATA[MySQL5.5加主键锁读问题—续]]></title><link>https://blog.youkuaiyun.com/iteye_621/article/details/82514523</link><guid>https://blog.youkuaiyun.com/iteye_621/article/details/82514523</guid><author>iteye_621</author><pubDate>Fri, 14 Jun 2013 17:38:48 +0800</pubDate><description><![CDATA[
背景
       上一篇说到MySQL 5.5加主键导致阻塞源表的读的问题。
有同学提到从调用函数看，在默认的old_alter_table=off的情况下，加主键过程没有看到copy to tmp table。
         这里我们再细说一下。
 
说说fast index creation
         在MySQL 5.1以后InnoDB引入了fast index ...]]></description><category></category></item><item><title><![CDATA[MySQL5.5加主键锁读问题]]></title><link>https://blog.youkuaiyun.com/iteye_621/article/details/82513414</link><guid>https://blog.youkuaiyun.com/iteye_621/article/details/82513414</guid><author>iteye_621</author><pubDate>Sun, 09 Jun 2013 09:30:50 +0800</pubDate><description><![CDATA[
 

背景
     有同学讨论到MySQL 5.5下给大表加主键时会锁住读的问题，怀疑与fast index creation有关，这里简单说明下。
 
对照现象
         为了说明这个问题的原因，有兴趣的同学可以做对比实验。
    1)  在给InnoDB表创建主键期间，会锁住该表上的读数据
    2) 但是同样的表执行删除主键期间，不会锁住该表上的读操作
--...]]></description><category></category></item><item><title><![CDATA[InnoDB row_id边界溢出验证]]></title><link>https://blog.youkuaiyun.com/iteye_621/article/details/82511152</link><guid>https://blog.youkuaiyun.com/iteye_621/article/details/82511152</guid><author>iteye_621</author><pubDate>Tue, 28 May 2013 13:34:01 +0800</pubDate><description><![CDATA[
背景
         跟同学聊到row_id一个边界问题，这里详细说明下。
         InnoDB表若没有定义主键，会使用系统的一个默认递增row_id (dict_sys-&amp;gt;row_id)作为主键。每次插入一行加1，到达最大值循环复用。
         需要注意的是，虽然dict_sys-&amp;gt;row_id 被定义为一个unsigned long long, 但由于这...]]></description><category></category></item></channel></rss>