02

终于解决了mysql参数thread_concurrency的设置问题

已经在一个非常奇怪的数据库问题上卡了很久,slow log里面全是一些非常基本的sql语句,主键查询或者根据主键更新简单字段,本来应该是毫秒级返回结果的sql,居然总是超时。innodb分明是行级锁,本来这些单行操作是innodb的优势项目,应该毫无压力的,居然成为了瓶颈。

继续阅读全文

21

初窥InnoDB的Memcached插件

本文在使用Memcached插件的时候,所有例子均使用的是读操作,实际上写操作也是支持的,不过在实际使用时,我更倾向于写操作都通过SQL来执行,而Memcached插件仅处理KV形式的读操作,实际压力测试的结果显示,Memcached插件比SQL的方式,性能提升了百分之一百左右,虽然仍不及独立的Memcached,但考虑到其它的优势,这个结果已经很让人欣喜了,下一站,InnoDB的Memcached插件!大家做好准备吧。

继续阅读全文

15

MySQL的varchar定义长度到底是字节还是字符

varchar能够定义的最大长度是多少呢?这个和你当前所使用的字符集有关。抛开字符,其最大长度为65535字节(这是最大行大小,由所有列共享),而放在不同的字符集下,能够定义的最大长度就会有所不同,如UTF8下是21845。据说MySQL5中varchar的长度也为字符,而MySQL4中的则为字节,未经证实,感兴趣的有环境可以自己测下。

继续阅读全文

15

MySQL中无GROUP BY直接HAVING的问题

一般来说,HAVING子句是配合GROUP BY使用的,单独使用HAVING本身是不符合规范的,
但是MySQL会做一个重写,加上一个GROUP BY NULL,”SELECT * FROM t HAVING id=MIN(id)”会被重写为”SELECT * FROM t GROUP BY NULL HAVING id=MIN(id)”,这样语法就符合规范了。
但是,这个 GROUP BY NULL 会产生什么结果呢?经过查看代码和试验,可以证明,GROUP BY NULL 等价于 LIMIT 1:

继续阅读全文

08

MySQL Innodb数据库性能实践——VARCHAR vs CHAR

学过数据库理论的读者,都应该还记得关于CHAR和VARCHAR的性能对比:CHAR比VARCHAR更快,因为CHAR是固定长度的,而VARCHAR需要增加一个长度标识,处理时需要多一次运算。
但测试结果展现了一个与理论不太相符的现象:当表大小小于Innodb buffer pool时,CHAR和VARCHAR没有差别,而在表大小大于Innodb buffer pool时,VARCHAR性能反而更高!这是为什么呢?

继续阅读全文

31

MySQL源代码:从SQL语句到MySQL内部对象

优化器是关系数据库的一个重要而有特色的部分,优化器的理论和实践也多半也都很复杂,本系列文章希望通过解析MySQL优化器,来用好MySQL,扬其长,避其短。顺便也一窥关系数据库优化器的实现思路。文章将重点介绍重要的数据结构和数据结构之间的关系,而不是侧重于代码。

继续阅读全文

31

index merge的补充说明

有一类很少见也比较特殊的index merge,多个索引扫描后进行交集,即 Index Merge Intersection。这类执行计划比较少见(因为MySQL需要ROR的原因),但是,在合适的场景使用,效率仍然会有很大的提示,本文将看看MySQL优化器如何评估和选择此类执行计划。MySQL手册对此只是三言两语简单介绍了一下,这里做个较为详细的说明。

继续阅读全文