如果你的MySQL表字符集刚好被设置为xxx_ci，比如utf8_generic_ci，如果刚好你做了一个如下查询，如果刚好你的数据库里面刚好有以下这两条记录，如果你足够细心，那么恭喜你应该发现出乎意料的结果。
table user
id name
1 hello
2 HELLO
SQL
select * from user where name=”hello”
结果集
id name
1 hello
2 HELLO
难道不应该是？
id name
1 hello
原来MySQL某些字符集下面默认是不区分查询大小写的，这主要是由mysql的字符校验规则的设置决定的。
简单介绍一下字符校验规则吧
字符集是一套符号和编码,校对规则是在字符集内用于比较字符的一套规则。任何一个给定的字符集至少有一个校对规则，它可能有几个校对规则。
校对规则一般有这些特征：
两个不同的字符集不能有相同的校对规则。
每个字符集有一个默认校对规则。例如，utf8默认校对规则是utf8_general_ci。
存在校对规则命名约定：它们以其相关的字符集名开始，通常包括一个语言名，并且以_ci（大小写不敏感）、_cs（大小写敏感）或_bin（二元）结束。
所以对于一些比较敏感的数据，应该十分注意字符集。
通常对结尾为『_cs』的字符集为『大小写敏感』型，或者使用『_bin』后续字符集，如utf8_bin.
那么对于已经存在的历史数据应该如何处理呢？
其实针对已经设置为xxx_ci字符集，同时又不得不处理大小写敏感问题的数据我们除了修改字符集以外还可以修改查询语句。
1.在SQL语句中使用collate:：select * from user where name collate utf8_bin = ‘hello’;
2.在SQL语句中使用binary操作符：select * from user where binary name = ‘hello’;
最近上了几台从库之后经常出现疑似主从同步延时问题，但经过运维排查后给出结论是主从同步正常，不存在比较严重的延时问题，依据是反复实验参数Seconds_Behind_Master=0，但问题真的真的是存在。
事实上问题已经很明确，可能存在的问题就那么几点，主从延时可能性确实很大，后来查了一下资料才恍然，原来 Seconds_Behind_Master参数并不能说明主从同步是否延时问题
官方解释是：
- When the slave is actively processing updates, this field shows the difference between the current timestamp on the slave and the original timestamp logged on the master for the most event currently being processed on the slave.
准确说Seconds_Behind_Master指的是slave 系统当前时间和当前SQL thread处理的binlog event时间差，这个时间差与binlog event 和 slave 系统时间直接关联。如果master 和 slave时间不同步，就有可能产生 Seconds_Behind_Master 参数显示问题，可以在从库执行 date -s“+1 hour” 看看Seconds_Behind_Master是不是突然变的很大了？
- When no event is currently being processed on the slave, this value is 0.
当前没有待处理binlog event时，Seconds_Behind_Master也为0
这样问题就已经很明朗了，因为I/O thread并不能保证和master保持实时同步，所以Seconds_Behind_Master=0也不同说明同步没有延时。
阅读全文…
本文就常见MySQL运行参数做详细列举与说明，并对各参数的设置条件做尽可能详尽的解释，由于MySQL配置参数比较多，本文尽可能全面介绍各参数，如有遗漏将陆续更新，欢迎大家点评投稿.
鉴于MySQL配置参数优化与数据库运行环境有密切关联，本文主要对MySQL参数做解释翻译整理，部分设置参数值来源整理自其他博客，考虑到尊重原创，本人尽量标注引用来源，如有遗漏，请及时联系我更正。 阅读全文…
Percona Xtrabackup 是一个开源的MySQL热备份工具，采用GPL开源协议，支持InnoDB、XtraDB引擎在线热备份、Non-blockingd备份，流式备份，压缩备份，增量备份等特性，是商业备份工具InnoDB HotBackup的一个很好的替代品。目前Percona Xtrabackup支持InnoDB、XtraDB和MyISAM，原生MySQL以及Percona Server上的XtraDB，可运行在Linux和FreeBSD上，Windows平台目前处于测试阶段。
阅读全文…
“Cache为王”，无所不在。为了最小化磁盘I/O，MyISAM将最频繁访问的索引块（“index block”）都放在内存中，这样的内存缓冲区我们称之为Key Cache，它的大小可以通过参数key_buffer_size来控制。在MyISAM的索引文件中（MYI），连续的单元（contiguous unit）组成一个Block，Index block的大小等于该BTree索引节点的大小。Key Cache就是以Block为单位的。
1. MyISAM如何使用Key Cache
当MySQL请求(读或写)MyISAM索引文件中某个Index Block时，首先会看Key Cache队列中是否已经缓存了对应block。如果有，就直接在Key Cache队列中进行读写了，不再需要请求磁盘。如果是写请求，那么Key Cache中的对应Block就会被标记为Dirty（和磁盘不一致）。在MyISAM在Key Cache成功请求（读写）某个Block后，会将该Block放到Key Cache队列的头部。
如果Key Cache中没有待请求（读或写）的Block，MyISAM会向磁盘请求对应的Block，并将其放到Key Cache的队列头部。队列如果满了，会将队列尾部的Block删除，该Block如果是Dirty的，会将其Flush到磁盘上。我们看到MyISAM维护了一个LRU（Least Recently Used）的Key Cache队列。队列中的Dirty Block会在Block被踢出队列时Flush到磁盘上。
阅读全文…
数据库属于 IO 密集型的应用程序，其主要职责就是数据的管理及存储工作。而我们知道，从内存中读取一个数据库的时间是微秒级别，而从一块普通硬盘上读取一个IO是在毫秒级别，二者相差3个数量级。所以，要优化数据库，首先第一步需要优化的就是 IO，尽可能将磁盘IO转化为内存IO。本文先从 MySQL 数据库IO相关参数（缓存参数）的角度来看看可以通过哪些参数进行IO优化： 阅读全文…