The latest from the MySQL community

一、表：      单个表的字段数控制在 20个以下，最好不超过50个      单个表不超过20个char 或varchar 字段      单表不超过50个纯int字段      拒绝大SQL，大事务，批量操作   二、字段类型定义： 字段类型选取原则： 1、选取合适范围的数据类型 2、只取正...

【mysql】  【函数】  【索引】  【数据库开发】  【字符集】   …

 大家习惯于以响应时间来衡量性能表现，实际响应时间指的正是从接收请求开始到发送响应之间的时间跨度。我们通常的做法是在代码里加入日志计算时间，这个是不准确的，该方式只是单单计算应用程序内部经过的时间，没有计算网卡到应用程序，应用程序到网卡的时间。

【mysql】  【日志】  【timestamp】   点击查看原文>

微博上讨论MySQL在删除大表engine=innodb（30G+）时，如何减少MySQL hang的时间，现做一下简单总结：（微博地址：http://weibo.com/1642466057/yuPz2guYJ） 当buffer_pool很大的时候（30G+），由于删除表时，会遍历整个buffer pool来清理数据，会导致MySQL hang住，解决的办法是： 1、当innodb_file_per_table=0的时候，以上不是问题，因为采用共享表空间的时候，该表所占用的空间不会被删除，buffer pool中的相关页不会 被discard。

【mysql】  【innodb】  【性能】  【脚本】   …

  摘自官方文档：     主要是Innodb特点及其负责部分：     Storage limits（存储限制）：64T     Transactions（是否支持事务）：yes     Locking granularity（锁粒度）：Row     MVCC（是否支持多版本控制）：yes  ...

【mysql】  【innodb】  【函数】  【加密】  【cluster】  【索引】   …

测试库中有将近300张表，其中有278张表的fid,uid字段需要作出修改。    解决办法是自动生成修改字段属性的SQL语句。    用于生成SQL的语句：    select CONCAT('alter table  ',TABLE_NAME,'  modify  ',COLUMN_NAME,' varchar(50) ;') from information_schema.

【mysql】  【SQL】  【测试】  【varchar】  【Blog】   点击查看原文>

MySQL的性能从查看日志开始。硬件配置低常常导致这样的问题，但事实上大多数情况并不在这里。某些“慢"SQL阻塞了其他语句的执行，优化查询是第一步需要做的。     “工欲善其事必先利其器”，MySQL自身的一款mysqldumpslow 查询日志分析器，该工具不但陈旧，验证规范不准确。

【mysql】  【memcached】  【SQL】  【日志】  【LOG】  【review】   …

在MySQL主从复制过程中，常常需要对某些重要的表进行一致性检查。     由于主从数据在同步时存在一定的延迟，因此直接读取服务器数据的方式无法严格保证信息的一致性。在数据在同步完全结束之前，一直处于不断变化且并不完整的状态下。

【mysql】  【同步】  【Server】  【checksum】  【IT】   点击查看原文>

今天要介绍的是Percona中的pt-stalk工具。    有些问题间歇性的发生，监控信息也许根本来不及采集信息，MySQL的锁定或活动的高峰通常没有留下任何数据来分析。    Pt-stalk 会监测一个触发条件，然后收集相关信息，该工具会将信息写入到 指定的日志文件，默认以时间格式区分。

【监控】  【mysql】  【日志】  【脚本】  【variables】   …

 记录工作的点点滴滴：     今天遇到case 1:     在测试机上，start slave 出现“假死”现象，数据库能够连接，     show processlist;显示：队列等待master     从错误日志里面看到： 120831 16:20:59 [ERROR] /us...

【mysql】  【日志】  【线程】  【Create】  【binlog】  【磁盘】   …

主从复制延迟的监测，我以前的做法是通过比较show slave status\G中的两个变量的差值（Read_Master_Log_Pos，Exec_Master_Log_Pos），将差值设置为一个自己认为合理的范围，Seconds_Behind_Master 没有适用过，今天做一次解析:     Seconds_Behind_Master 是通过比较 SQL THREAD 接受 events事件的时间戳（timestamp） 与IO THREAD  执行事件 events时间戳的差值--秒数来确定slave 落后于master多少。

【监控】  【mysql】  【同步】  【test】   …