MySQL -- IT技术博客大学习 -- 共学习共进步！

• Innodb分表太多或者表分区太多，会导致内存耗尽而宕机

因为线上某个应用表分区太多，直接导致遍历表或者dump数据的时候导致内存耗尽死机。原因是Innodb的数据字典不会释放内存，会将所有表和分区的信息记录在内存当中，当表数量或者分区数到达一定数量之后(经验值:约10万张表或者10万个表分区，占用将近1G大小的内存)，会导致内存耗尽。 my.cnf 配置参数: innodb_additional_mem_pool_size 查看数据字典使用多少内存: SHOW engine innodb STATUS\\G Dictionary memory allocated xxxxxx...

• 数据不算大，备份却非常慢

问题环境硬件：DELL 1950, 146G SAS 15K RPMS * 2, 8G Ram软件：2.6.9-55.ELsmp x86_64, mysql 5.1.x现象2个库，其中1个业务库下有20多个表，表文件大小总量不到2G。另一个为日志库，下400多个表，大致是每天会产生5个表，其中有一个表较大，约400MB，总量约40多GB。每次备份耗时较长，最严重的一次花了5个多小时才完成。业务库为当前活动库，日志库则主要用作备份，每天日志归档，过期数据表很少有读写请求。InnoDB Buffer Pool总...

• show engine innodb status显示信息不全?

问题：执行 show engine innodb status\\G 时，显示的信息不全，DEADLOCK相关信息太多，后面的都没了原因：这是mysql客户端的一个bug：BUG#19825，交互式客户端限制了输出信息最大为 64KB，因此更多的信息无法显示。解决办法：解决方法有两种：1. 启用 innodb_status_file修改 my.cnf，增加类似下面一行innodb_status_file = 1就可以了。2. 启用 innodb_monitormysqld在线运行时，创建 innodb_monitor 表，即可记录相关信息到日志...

• 无需过分关注Created_tmp_disk_tables

通常地，我们习惯以 Created_tmp_tables/(Created_tmp_disk_tables + Created_tmp_tables) 或者已各自的一个时段内的差额计算，来判断基于内存的临时表利用率。所以，我们会比较关注 Created_tmp_disk_tables 是否过多，从而认定当前服务器运行状况的优劣。而事实上，我们并没有必要太过分的关注 Created_tmp_disk_tables，因为通过上面的公式，并不能真正反映到mysql里临时表的利用率。

• MySQL优化之 Discuz论坛优化

很早以前写过一个文章，是关于discuz论坛的优化：MySQL优化之 Discuz论坛优化。写的时候是2006年，没想到过了这么久，discuz论坛的问题还是困扰着很多网友，其实从各论坛里看到的问题总结出来，很关键的一点都是因为没有将数据表引擎转成InnoDB导致的，discuz在并发稍微高一点的环境下就表现的非常糟糕，产生大量的锁等待，这时候如果把数据表引擎改成InnoDB的话，我相信会好很多。这次就写个扫盲贴吧。

• innodb_flush_method 与 Linux File I/O

陶方在《innodb_flush_method带来的性能影响》中从实验角度比较了fdatasync，O_DSYNC和O_DIRECT在性能上的差异。本文将试图从Linux/Unix”文件I/O”（unbuffered I/O）的角度来解释innodb_flush_method是如何...

• innodb_flush_method带来的性能影响

innodb_flush_method有三个值，分别是fdatasync，O_DSYNC和O_DIRECT，其中fdatasync是默认值。它们控制了InnoDB刷新日志和数据的模式。

• MyISAM和InnoDB的插入性能测试

总的来说，Ext3的cache算法性能还是非常不错的，不愧是linux上面备受推崇的文件系统。InnoDB虽然提供了高可用性，但是插入性能方面的表现并不如MyISAM稳定。

• InnoDB select性能拐点测试

传说InnoDB的数据量到了一定程度就会有一个很大的下滑。那么这个阙值究竟是是多少？来做一下测试吧！

• InnoDB insert性能拐点测试

上篇blog《InnoDB select性能拐点测试》测试了InnoDB select的性能拐点，本篇blog对insert的性能拐点做了一些对比研究。大家有兴趣就关注一下吧！

• InnoDB之Dirty Page、Redo log

在InnoDB中，buffer pool里面的dirty page一方面可以加快数据处理速度，同时也会造成数据的不一致(RAM vs DISK)。本文介绍了dirty page是如何产生，以及InnoDB如何利用redo log如何消除dirty page产生的数据不...

• 随机主键对InnoDB插入性能的影响

孔子说得好，“学而不思则罔，思而不学则殆”。看书看多了不去想不去做对比，很快脑子就会一片混乱。这篇blog稍微介绍下随机主键对InnoDB插入性能的影响。 InnoDB引擎的行结构相当复杂...

• Query Cache，看上去很美

当你的数据库打开了Query Cache（简称QC）功能后，数据库在执行SELECT语句时，会将其结果放到QC中，当下一次处理同样的SELECT请求时，数据库就会从QC取得结果，而不需要去数据表中查询。在这...

• Mysql combine index

先说骗子。这年头骗子真多。刚才拨打一个网上搜索的特价飞机订票热线400-6064-***，对方叫我直接去建设银行上汇钱再给出票，还给了一个个人的建设银行账户。明显就是骗子，还好老婆提醒我不贪图小利，警防骗子，不然我真去银行傻汇了。在此提醒大家出行注意安全。 Oracle的组合索引操作有2种，access和filter,当然access更好。Mysql在组合索引上，只有access，没有filter。因此要注意MYSQL处理where clause包括多个range条件的SQL...

• 恢复删除的数据表，数据库

在您进行恢复操作时，我们常常面临执行删除表/库操作丢失数据的问题。在这种情况下,就是我们的InnoDB 数据恢复工具也爱莫能助，因为存放表文件的目录被删除了(如果你设置了innodb-file-per-table)。同样的事情也发生在Myisam表中，所有的.MYD,.MYI,.frm文件也被删了。所以当drop操作发生后，第一第一要干的事情就是：恢复文件。在ext3文件系统下，有两工具能帮上你的忙，前提是如果您足够地快（或者说足够幸运)。第一个是ext3gre...

• REPLACE INTO 为什么返回”2 rows affected”

为啥呢….看起来数据啥也没变，不是吗?

• mysql cache功能小记

mysql cache功能分析：1 mysql的cache功能的key的生成原理是：把select语句按照一定的hash规则生成唯一的key，select的结果生成value，即key=>value。所以对于cache而言，select语句是区分大小写的，也区分空格的。两个select语句必须完完全全一致，才能够获取到同一个cache。2 生成cache之后，只要该select中涉及到的table有任何的数据变动（insert，update，delete操作等）,相关的所有cache都会被删除。因此只有数据很少变动...

• 如何建立索引

关于如何建立索引，及哪些情况适合使用索引，哪些情况不适合使用索引，各种书籍资料有很多。但是最重要的原则是：实际测试。实践是检验真理的唯一标准。建立索引的时候，应进行如下测试：1 explain select语句，看看是否有使用到索引。2 运行update和insert操作，看看建立索引的负效应是否在可接受范围。3 务必在接近生产环境的数据规模下进行索引性能的测试。

• MySQL常用维护管理工具

　MySQL是一个非常流行的小型关系型数据库管理系统，2008年1月16号被Sun公司收购。目前MySQL被广泛地应用在Internet上的中小型网站中。由于其体积小、速度快、总体拥有成本低，尤其是开放源码这一特点，许多中小型网站为了降低网站总体拥有成本而选择了MySQL作为网站数据库。　　MySQL的管理维护工具非常多，除了系统自带的命令行管理工具之外，还有许多其他的图形化管理工具，这里我介绍五个我经常使用的MySQL图形化管理工具，供...

• MySQL 5.1 的参数简表

整理一个MySQL 5.1 的参数简表，共303个，方便平时查询。