- 博客(15)
- 资源 (15)
- 收藏
- 关注
原创 复合索引的列顺序判断
复合索引最令人困惑的当属索引列的顺序,不仅依赖于使用该索引的查询,更需考虑排序和分组。前段时候我发了个帖子: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 4024 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
原创 巧妙避开MySQL字符集的骚扰
在执行开发童鞋给的SQL脚本更新时,切记先用【\s】看下字符集,笔者今天在新项目上线时忘了确认字符集,导致页面查出来是乱码,还好老大给力,速度帮我背了黑锅,存底警醒自己以后不要再干出这种蠢事。Good Luck!
2014-04-01 23:42:19 1795 2
mysql+heartbeat+drbd软件集合
2013-05-17
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人