lidan3959的专栏

昨天由于服务器空间告紧，需要将mysql的datadir从默认的/var/lib/mysql移到/usr/local/mysql下，操作如下：1.修改了/etc/mysql/my.cnf，改为：datadir = /usr/local/mysql2.cp -a /var/lib/mysql /usr/local/3./etc/init.d/mysql start问题

今天登陆mysql 发现任何操作都报错如下：MariaDB [(none)]> select sleep(4);Ignoring query to other databaseMariaDB [(none)]> use test;Database changedMariaDB [(none)]> show databaes;Ignoring query to oth

今天本来想在开发测试机上做测试，测试过程中需要flush table ，不过让人想不到的是执行后居然卡住不动了。于是赶紧开启另一个会话查看情况如下：原来数据库里还有一个慢查询（已经执行了2w多秒），然后继续执行show processlist 观察，更多惊喜还在后面：所有的查询都在“waiting for table flush” ，够恐怖的吧（这让人想起了

废话先不多说，直接上实验情况。测试表结构如下：CREATE TABLE `test` (  `id` bigint(20) NOT NULL DEFAULT '0',  `stat_date` varchar(10) COLLATE utf8_bin DEFAULT NULL,  `earner_id` varchar(20) COLLATE utf8_bin DEFAULT NU

前段时间的一个报错，原因是业务上进行大量的更新操作一个操作大概更新上百万数据，最后悲剧出现：140314 13:05:48  InnoDB: ER#RR: the age of the last checkpoint is 1132216877,InnoDB: which exceeds the log group capacity 724770202.InnoDB: If you a

bug 详情见官介绍：

这算是前几天的事了，仅仅是在线上执行三个简单的update，由于大意chada

昨天晚上为了回收表空间，打算用pt-online-schema-change对一张58G的大表进行

昨天晚上因为重建一些大表(每张表数据量都

今天一个朋友问说忘了mysqlroot密码怎么办，我告诉他重启的时候加--skip-grant-tables，然后update 密码之后flush privilges即可。不过这哥们按照我说的做却直接报错如下： [root@hostxxx mysql-5.5.34-linux2.6-x86_64]# /etc/init.d/mysql3307 restart --skip-grant-ta

第一次玩pecona 就给一个下马威，初始化数据库居然给我报

今天玩了一下mariadb-10.0.6  在初始化系统库mysql_install_db  --defaults-file=/home/mha/app/mariadb-data/my.cnf --user=mha的时候居然报错：ERROR: 1406  Data too long for column 'url' at row 1 查来查去居然是sql_mode的问题，我的配置文

做为一款轻量级数据库软件，MySQL在使用过程中遇到访问速度慢，或者无法响应这类的问题，解决方式基本都有定式，一般第一反应都会是登录到MySQL, show processlist看看当前连接状态。虽说简单，但show processlist显示的信息确实是相当有用，有一回，三思收到反馈说MySQL查询很慢，于是，赶紧登录到mysql中，执行show processlist查看当前连接信息

今天发生一个故障，MM复制结构（主备库），备库slave delay越来越大，造成在备库上的读与主库数据不一致，登上备库分析：1.show processlistdrop table tmp_table 在  Waiting for table metadata lock 2.ps mysqldump 在备份整个实例数据 kill了备份进程，drop table tmp

背景：      数据库链接不上，报错：root@localhost:/var/log/mysql# mysql -uzjy -p -h192.168.1.111 --default-character-set=utf8 -P3306Enter password: ERROR 2013 (HY000): Lost connection to MySQL server at 'rea

表多了，任何操作都要小心，累加效应会带来意想不到的故障的背景执行的DDL操作形如，单台机器上两个库,每个库32个表,顺序执行：alter table tc__xxoo add column cxxx1 datetime not null,add column cxx2 datetime not null;一条DDL的执行时间，我们期望

这个问题来自冷之同学测试时候碰到的一个“诡异现象”。 1、 测试现象       测试的库有很多数据，但是重启之后，只对一个表的5w条记录作查询。查询条件客户端控制，确保查询范围。innodb_buffer_pool_size设置为35G。现象1：查询性能会出现大幅度抖动；现象2：介入追查后发现，Innodb_buffer_pool_pages_free = 0    

背景这个问题由一个同事问到的一次导入数据引发。一个很常见的操作，将数据从一个表中dump出来，在用mysql 在执行导入的时候，提示 MySQL server has gone away。在追查的时候突然想到会不会是因为max_allowed_packet太小导致的。将max_allowed_packet改大，确实解决了问题。本文基于在此之后想到的两个问题：1、  

今天开发说在从oracle迁移数据到msyql的测试过程中出现字段长度不够的问题，第一反应是字段设置太短，但是看过字段后发现不是这么简单错误代码：java.sql.BatchUpdateException: Data truncation: Data too long for column 'conditions' at row 1  错误截图：oracle 字段类型和长度

今天开发大神说有一个update的普通sql执行有问题，抱怨mysql太烂，后来看了sql后发现原来是update 更新使用where条件使用了本身表的子查询的问题，不得不说mysql有这方面的限制不过绕一绕也是可以的，当然最后还是让开发心满意足的离开了。这个限制其实早就存在，包括mysql及其mariadb （甚至是10.0.6）只不过我忘了告诉开发的大神们，这次记录一下，也许其他不知道写法

在存储过程中，调用：delete a from db1.tb1 a, db2.tb2 b where a.col1 = b.col1 and a.col2 = b.col2;出现题目中的错误，原因如下：在mysql中多表联合删除时，表别名只能在sql中表关联部分声明。我们应该避免不是表关联部分声明别名，因为这产生歧义的sql,从而产生不是期望的结果，例如在错

今天为研发改写了一个巨复杂的sql，因为保密原因就不贴出来了，自觉得意之时开发哥哥抱怨说只能在命令行执行，一旦放程序里就报错（hibernate包装过）这里给一个简单的sql来做例子：select a.id ,a.d ,if(@od=a.d,@rank:=@rank+1,@rank:=1) num ,@od:=a.d from (select id ,d from number c ord

今天早上到公司看到邮件告警，一个备库延迟巨大，奇怪为啥没告警，后来发现脚本告警被人注释，先不管这么多，查看主备相关信息show variables like '%commit%' 发现 主库设置为1，备库设置为2，这就奇怪了，主库业务不是特别大没道理延迟NN秒，然后有查看 show variables like '%sync%' 发现主备库都设置为1,然后默默尝试将备库设置为0，没多久

今天碰巧遇到一个以前忽视的问题，就是sql_mode对自增列值的影响，这里做个简单的测试：(user:root  time: 11:30)[db: lidan]show variables like '%mode%';+--------------------------+---------------------+| Variable_name            | Va

以前对mysql用户授权和回收都是使用grant 和revoke没出现过任何问题，昨天领导更改了办公网ip（蛋疼），所有办公网连接数据库都报错（恩，不要抱怨）。然后默默的开始写脚本批量更新上百台服务器的权限，更新脚本如下：mysql -umysqldba -pxxx -e "update mysql.user set host='218.247.217.66' where host like