2014年04月_linwaterbin

11月 08月 05月 04月 02月 01月

原创复合索引的列顺序判断

复合索引最令人困惑的当属索引列的顺序，不仅依赖于使用该索引的查询，更需考虑排序和分组。前段时候我发了个帖子：where条件顺序和复合索引字段顺序。感兴趣的朋友不妨参与讨论。今天我提个自己的观点。在应用开发阶段，【选择性】是我们首要考虑因素，请看简图：当出现sql性能问题时，你可能需要注意以下几个：1. 随机IO2. 排序(order by)3. 分组(group by or distinct)这时

2014-04-27 19:04:44 12341 1

原创 Oracle 物理和逻辑备库健康监测的一个依据

以下面关键字眼为例：1 物理备库健康检查依据：Tue Apr 22 16:44:51 CST 2014Media Recovery Log /data/CMS/arch_log/1_58334_722210153_58334arch.dbfMedia Recovery Waiting for thread 1 sequence 58335 (in transit)2 逻辑备库健康检查依据：Tue

2014-04-25 11:33:06 6179

原创江湖救急篇：slave 复制出错

事情是这样的，我们DBA组有位同学误删了备库的一个临时表，导致复制出错老大给力，江湖救急。关于该参数，淘宝丁奇写了篇文章还不错：MySQL小误区：关于set global sql_slave_skip_counter=N 命令的一些点还有360的杨挺也有一篇：sql_slave_skip_counter 介绍这2篇文章看下大概理解了最后说下，保险点的做法是 N恒等于 1，比较不容易出错 :-)当然

2014-04-22 12:12:57 6560

原创 Oracle DG故障诊断一则：alter database recover to logical standby new_logical_dbname卡住

我们在基于物理standby的基础上搭建逻辑备库过程过程中，在执行：alter database recover to logical standby READDB;卡住不动，并且alert也没有报错信息，无比郁闷，咨询了别人，聊天记录如下：我们的业务是passport应用，无法停止或者停掉非常麻烦，总之，药不能停。经过摸索，我们得到一个经验：需要等到MRP应用日志到跟主库一致，此时执行该命令才不

2014-04-21 21:35:40 8466

原创 Oracle DG故障诊断案例一则：ORA-16047: DGID mismatch between destination setting and standby

前天在搭建物理standby时，前面步骤都没错(实际上是有错)，在验证归档日志是否同步到备库时发现：ORA-16047: DGID mismatch between destination setting and standby我们的处理方案是：在主备同时设置相同的log_archive_config1. 备库idle> show parameter log_archive_config;NA

2014-04-15 10:03:23 10046

原创 Python多进程编程（一）：初探

1 基础例子比较常用的做法是，创建一个进程时可以提供参数来告诉他要做什么。本例子里，输出的"worker"将打印5次，不过不清楚孰先孰后，因为每个进程都在竞争访问输出流。1.1 输出顺序的不同[root@localhost pydoc]# ./tmp.pyworker 0worker 1worker 2worker 3worker 4[root@localhost pydoc]# ./

2014-04-13 22:21:08 6878

原创我踩了mysqldump的一个地雷（续）

这个地雷我没踩过，不过今天周老大在微博记录了，想必这是他老人家心中的一个痛。为什么要记录？因为我认为这和我上次踩过的一个雷有异曲同工之妙，不同的是，我那个是数据库级别，而周老大那是表级。感兴趣的不妨结合起来看：我踩了mysqldump的一个地雷这种默认带删除操作真是坑死人不偿命啊，啊啊啊，受不了，功能多也是不好，这和MySQL的作风完全不符呀，完全属于PG一类。下面我来揭露下周老大心中的痛 :-)

2014-04-13 18:34:54 6416 2

原创 TokuDB && InnoDB insert压力测试对比

1 测试环境指标测试环境机型DELL PE R720（2U PC Server）CPUXeon E5-2620(6核，12线程，2.0GHz, L3 15MB) * 2内存32G(4G * 8)阵列卡及设置PERC H710，512MB，BBU(FW：12.10.1-0001)，RAID 1+0FORCE WB硬盘15K RPM 300G SAS * 8网卡Intel 1GbE操作系统RHEL 5

2014-04-12 10:44:21 5696

原创 MySQL SQL优化：碍手碍脚的索引

该篇是SQL优化的第4篇。这里主要表达我的一个观点是：不该存在的索引就该干掉，留着碍事在2014-3-12 15:39:01 -- 15:55:00这段时间内，在某个业务系统我们发现2个问题：1. 数据库存在大量的查询等待2. 服务器的存在较严重的io等待这种现象在数据库中实际也是很常见，就是某个慢查询，始作俑者，执行特马慢，把后面本该很快的查询给堵住，导致系列长查询出现经诊断，我们发现某张表里存

2014-04-05 17:22:54 4023 2

原创 MySQL SQL优化：关联子查询的局限性

这是MySQL SQL优化的第三篇。公司某个业务系统频繁抛出问题SQL，我们对此类SQL做了基本面统计：此类SQL近期共执行了12次，最长一次花费480秒，最短286秒t1表的rows有90多万，始终会扫描这么多不需要的数据这是由于MySQL查询优化器在处理相关子查询方面存在局限性MySQL总是会将相关的外层表压到子查询中，它认为这可以更高效地查找数据行。这就意味着MySQL先选择对外层表进行全表

2014-04-05 16:57:47 3274 1

原创 MySQL SQL优化：Percona优化器真的好吗？

这是MySQL SQL优化分享第2篇，大家都很崇尚MySQL的一个强大分支Percona，真该跟风吗？有些时候，还是原配靠谱，小三不一定给力。我们先看下sar报告：明显地，CPU %idle 非常低，粗大事了。我们的告警邮件里显示，单条SQL执行时间长达 300秒左右。原始SQL非常长，这里就不贴了，但要表述的一个优化技巧是，优化的第一步，就是格式化 SQL :-)我们看下问题SQL的问题部分：

2014-04-05 16:26:33 4259

原创 MySQL SQL优化：SQL爬虫翻页优化

赶着这几天有些时间，把前段时间优化的几条SQL经验分享并总结下，以飨来者。第一个要分享的是对MyISAM优化limit分页。背景来自公司某个业务系统提供给爬虫抓取数据，MySQL版本是5.1，引擎为MyISAM，原始SQL内容大致如下：注：为避免敏感信息，将很多字段变为col，但不影响阅读 :-) SELECT Aa.* , B.col, B.col,

2014-04-05 11:55:21 2668

原创运维故障：假如下次注意，可能不会这么幸运

最近开始做运维，连着2天发生过意外，虽然都有惊无险，但我认为是侥幸！故障记录如下：1. 2014-4-1 新项目上线，在执行DDL时忘了确认字符集，导致开发同学那边查出来是乱码。2. 2014-4-3 部署Oracle DG，自以为主库不是线上库，初始化后重启了主库发生事情是我们都喜欢事后诸葛亮，然后扪心自谓:"我下次注意"，不要忘了，生产环境是随机行走的，你无法意料它的走向。我的意思是不可控的风

2014-04-03 22:29:56 2717 1

原创我踩了mysqldump的一个地雷

我们先看2种情况：P 1：[ 21:56:33-root@ssdtest:~ ]#mysqldump -S /data/mysql/test_3306/mysql.sock --single-transaction --force --databases tpcc > v1.sqlP 2：[ 21:56:54-root@ssdtest:~ ]#mysqldump -S /data/mysql/t

2014-04-02 22:41:37 2107