ibdata1文件持续增加的问题定位

December 10th, 2013 Comments off

用户的ibdata1文件持续增加:

Innodb的表有两种存放方式:

第一种共享表空间方式:所有表的索引,数据统一存放在一个共享表空间中,这样会导致共享表空间的空间迅速增长,同时空间回收困难;

第二种独占表空间方式:就是RDS目前采用 的,也就是一张表一个表空间,表中的索引和数据存放在自己独立的表空间中,空间能够比较容易的回收;

无论是独占还是共享表空间,innodb都会有系统共享表空间(ibdata1),该系统表空间主要用于存储数据字典,undo entry,insert buffer,doublewrite buffer,

该系统表空间的增加通常的原因[……]

Read more

Categories: database Tags:

有趣的大小写问题-utf8_bin

October 15th, 2013 Comments off

问题:

xxx@3023 14:51:26>insert into test_tmp_log_node_10445__01 select * from test;

ERROR 1062 (23000): Duplicate entry ‘taobao|维西v’ for key ‘idx_nodetemp_10445_01’

查看表结构:

CREATE TABLE `test` (
`user_id` varchar(64) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL COMMENT ‘主键。客户全局统一ID,由客户统[……]

Read more

Categories: database Tags:

巧用query cache

October 5th, 2013 Comments off

收到一用户反馈其应用日志中狂报错误,获取连接超时:

同时应用报错超出了数据库的最大连接数:max connections:

这种情况很有可能是有慢sql占用了连接池中的连接没有释放,导致后续进来的请求迟迟获取不到连接池中的连接,导致请求报错,登录数据库排查发现如下sql出现执行非常的慢:

mysql> select * from user where md5(nick)=’3f5950f59ddf2a0d14a44166040e348f’;
Empty set (1.32 sec)

一眼可以看出在nick上使用了md5函数,导致user表中的索引不能使用,而全表扫描[……]

Read more

Categories: database, mysql, RDS Tags:

sqlserver中几种典型的等待

October 5th, 2013 Comments off

为了准备今年的双11很久没有更新blog,在最近的几次sqlserver问题的排查中,总结了sqlserver几种典型的等待类型,类似于oracle中的等待事件,如果看到这样的等待类型时候能够迅速定位问题的根源,下面通过一则案例来把这些典型的等待处理方法整理出来:

第一种等待.memory等待

早上接到一用户反馈其RDS实例非常的慢,通过观察sqlserver活动会话监视器(active monitor)的waiting tasks(类似于mysql的thread running)可以看到有10多w的等待任务,可以明确数据库现在已经出现了较大的瓶颈,紧接着通过resource wa[……]

Read more

Categories: database, MSSQL, RDS Tags:

使用Percona Data Recovery Tool for InnoDB恢复数据

August 29th, 2013 Comments off

昨晚收到一则求助,一个用户的本地数据库的重要数据由于误操作被删除,需要进行紧急恢复,用户的数据库日常并没有进行过任何备份,binlog也没有开启,所以从备份和binlog入手已经成为不可能,咨询了丁奇,发了一篇percona的文章给我,顿时感觉有希望,于是到percona的官网上下载了恢复工具
一.安装:
.tar -xvf percona-data-recovery-tool-for-innodb-0.5.tar.gz
.cd percona-data-recovery-tool-for-innodb-0/mysql-source/
../configure
.cd percon[……]

Read more

Categories: database Tags:

查看mysql实时运行sql的工具–orztop

June 12th, 2013 Comments off

该工具为我的同事朱旭开发的一款可以查看mysql数据库实时运行的sql状况的工具,以前苦于通过show processlist/show full processlist抓取sql的同志们现在只要盯一盯屏幕就可以了,非常的方便,点击这里进行下载,使用方法也很简单,如下:

root@alsdb_admin1a:/root>./orztop –help
==========================================================================================
Info :
Created By zhuxu[……]

Read more

Categories: database Tags:

化繁为简-优化sql

March 29th, 2013 Comments off

下面的一段对话取自于和用户的一段旺旺聊天记录,在征得用户的同意后,放到我的blog中,希望更多的人能够看见,分享是一件快乐的事情;同时也想借此来说明一些问题,有时候试图用一条sql完成所有的业务逻辑可能会遇到麻烦,需要对复杂的sql进行一些拆分,可能会得到更好的效果,好吧,废话少说,进入正题:

RDS用户:(17:06:28):
EXPLAIN SELECT COUNT(DISTINCT mobile) AS clientcount , COUNT(aliww) AS aliwwcount , COUNT(DISTINCT email) AS emailcount FROM users[……]

Read more

Categories: database, mysql, RDS, sql优化 Tags:

RDS MySql支持online ddl

March 29th, 2013 No comments

在日常和客户沟通的过程中发现,他们在做mysql ddl变更的时候由于MySql本身的缺陷不支持online ddl,导致他们的业务不得不hang住一会儿,表越大,时间影响越长,所以期待有更好的解决方法;有些用户也想了一些方法,比如通过主备切换的方法,先在备库进行ddl,然后在通过主备切换到原主库进行ddl,但由于RDS对外提供给用户的是一个dns加port,所以后端的主备对用户是透明的,此方法行不通。其实在开源社区中已经有比较成熟的方法,那就是percona的pt-online-schema-change工具是其中之一,下面通过测试主要了解该工具的可靠性以及存在的问题,是否在RDS上支持。[……]

Read more

Categories: database, mysql, RDS Tags:

RDS-MSSQL问题排查方法

March 20th, 2013 No comments


早上收到客户反馈用户操作非常的卡,联系帮助进行排查,下面总结关于sqlserver 问题排查的方法经验:

方法一:ACTIVE MONITOR

通过sqlserver 的active monitor 来观察当前系统的实时运行状况

A. OVERVIEW 概况:CPU,WAITING TASK,DATABASE IO,BATCH REQUESTS

(1).CPU 是代表了当前实例的cpu 的使用情况,通常情况下,cpu 使用越高,代表了你的实例存在性能问题,常见的比如索引选择错误,全表扫描导致数据库的逻辑读非常的高,当然不能仅仅凭cpu 来判断问题,要综合结合其他指标[……]

Read more

Categories: database, MSSQL Tags:

MySql sql优化之order by desc/asc limit M

February 4th, 2013 No comments

Order by desc/asc limit M是我在mysql sql优化中经常遇到的一种场景,其优化原理也非常的简单,就是利用索引的有序性,优化器沿着索引的顺序扫描,在扫描到符合条件的M行数据后,停止扫描;看起来非常的简单,但是我经常看到很多性能较差的sql没有利用这个优化规律,下面将结合一些实际的案例来分析说明:

案例一:

一条sql执行非常的慢,执行时间为:

root@test 02:00:44
 
SELECT * FROM test_order_desc WHERE  END_TIME>now() ORDER BY GMT_CREATE DESC,count_num DESC LIMIT 12, 12;
 
+---------+-----------+------------+------+---------------------+---------------------+-------------------
Data1.....................................................................................................
 
Data2.....................................................................................................
 
+---------+-----------+------------+------+---------------------+---------------------+-------------------
12 ROWS IN SET (0.49 sec)
执行计划如下:
root@test_db01:53:23
 
EXPLAIN SELECT * FROM test_order_desc  WHERE  END_TIME > now()
 ORDER BY GMT_CREATE DESC,count_num DESC LIMIT 12, 12;
 
+----+-------------+----------+-------+-----------------+-----------------+---------+------+--------+-----
 
| id | select_type | TABLE    | TYPE  | possible_keys   | KEY    | key_len | REF  | ROWS   | Extra     |
 
+----+-------------+----------+-------+-----------------+-----------------+---------+------+--------+-----
 
|  1 | SIMPLE      | test_order_desc | range | ind_hot_endtime | ind_hot_endtime | 9       | NULL | 113549 | USING WHEREUSING filesort |
 
+----+-------------+----------+-------+-----------------+-----------------+---------+------+--------+-----

Ind_hot_endtime索引为:

51efcd69[……]

Read more

Categories: database, sql优化 Tags: