C My Life

支付系统的核心无疑就是充值、扣费、转账。假设现在是一个这样的账户表account(InnoDB)：  filedtypeinfoidbigint用户idbalancedecimal余额update_timedatetime数据更新时间 充值的时候那么下面这条语句就可以解决：UPDATE account SET balance = balance + 10.00, update_time = NOW() WHERE id=1;但是扣费和转账这种操作就比较麻烦了。不是下面这条语句就可以解决的：UPDATE

使用系统CentOS 6.2本来已经系统自带安装了mysql 5.1，但是奈何5.1不支持utf8mb4字符集（详见：http://blog.youkuaiyun.com/shootyou/article/details/8236024），只能想办法将Mysql升级到5.5。这果然是一次蛋疼的升级过程。完整步骤：1.首先备份数据，虽说成功的升级数据不会丢失，但是保险起见备份下。

1.设置内存表大小my.cnf的配置会影响内存表大小：max_heap_table_size = 16M这个配置是影响单个表的大小。基本上这个默认值是远远不够用的，测试过一个五列的表，插入15000左右的数据就报异常了：1114 - The table 'XXX' is full根据自己的需要改成想要的大小。

经常处理MYSQL的主从库同步异常，现在做个总结。主从库同步失效的原因各种各样，一般都是在从库上不小心执行了写操作，也有可能从库服务器意外重启等等。进入从库执行show slave status/G看到下面两行：Slave_IO_Running: YesSlave_SQL_Run

问题描述：程序上表现为对 主库 更新操作之后，从 从库 查询数据没发生改变。怀疑是主从库同步延迟导致。上从库查看主从同步状态，发现Seconds_Behind_Master时间长达一千多秒。正常情况下主从库延时个十几秒还可以容忍，一千多秒显然就有问题了么。。。问题分析：我们在一个MYSQL实例上创建了四五个Database，其中一个Database数据量和压力都比较大，从 从库的processlist可以看到从库在处理日志时经常发生lock的状况，但是lock只是压力大database为何会影响到其他dat

<br /><br />为了给高并发情况下的mysql进行更好的优化，有必要了解一下mysql查询更新时的锁表机制。<br />一、概述<br />MySQL有三种锁的级别：页级、表级、行级。<br />MyISAM和MEMORY存储引擎采用的是表级锁（table-level locking）；BDB存储引擎采用的是页面锁（page-level<br />locking），但也支持表级锁；InnoDB存储引擎既支持行级锁（row-level locking），也支持表级锁，但默认情况下是采用行级锁。<br

<br />问题发生的场景：<br />MYSQL安装在Linux下，本地和远程都有应用访问MYSQL，本地访问MYSQL很流畅，但是远程访问非常之缓慢，基本上到了几分钟才响应的地步。SSH连接稳定，ping了下发现无丢包，排除网络问题。那么可能就是MYSQL的设置问题了。<br /> <br />查阅资料发现可以这么配置：<br /> <br />[mysqld] <br />skip-name-resolve <br /><br />该选项用于禁用DNS解析，连接速度会快很多。不过，这样的话就不能在My

今天在解决数据库同步异常的时候用到了flush tables with read lock 这个命令，于是顺便就学习了下锁表的相关知识。1.FLUSH TABLES WITH READ LOCK这个命令是全局读锁定，执行了命令之后所有库所有表都被锁定只读。一般都是用在数据库联机备份，这个时候数据库的写操作将被阻塞，读操作顺利进行。解锁的语句也是unlock tables。2.LOCK TABLES tbl_name [AS alias] {READ [LOCAL] | [LOW_PRIORITY] WRIT

<br />今天部署项目的时候顺便把一些依赖用新版本的jar替换了，其他还好就是MYSQL的驱动出了问题。<br /> <br />原来用的是5.1.5的包，替换成5.1.17之后，如下生成主键的代码都会报错：<br />ps = getConnection().prepareStatement(sql.toString()); ....rs = ps.getGeneratedKeys(); <br />Generated keys not requested. You need to specif

之前还以为从上至下统一用上UTF-8就高枕无忧了，哪知道今天在抓取新浪微博的数据的时候还是遇到字符的异常。从新浪微博抓到的数据在入库的时候抛出异常：Incorrect string value: '\xF0\x90\x8D\x83\xF0\x90...' 发现导致异常的字符不是繁体而是某种佛经文字。。。额滴神。。。但是按道理UTF-8应该能支持才对啊，他不是万能的么？