Tips:
1）注意InnoDB总是一个事务引擎，如果你在自动提交模式，则每个语句都会作为一个事物提交：每次对数据库有改变的提交都会导致InnoDB刷新日志到磁盘。
当然，这个地方要看 innodb_flush_log_at_trx_commit 选项的设置：
参考：
http://dev.mysql.com/doc/refman/5.1/en/innodb-tuning.html innodb性能调节提示
http://dev.mysql.com/doc/refman/5.1/en/innodb-parameters.html#option_mysqld_innodb_flush_log_at_trx_commit
2）尽量将多个update语句放在一个事务中提交，但是也不能设置事务过大，原因：过大时如果回滚，会造成很大的磁盘开销
http://dev.mysql.com/doc/refman/5.1/en/innodb-tuning.html 这里说明：
InnoDB在插入中使用插入缓冲来节约磁盘I/O，但是在相应的回滚中没有使用这样的机制。一个磁盘绑定的回滚可以用相应插入花费时间的30倍来执行。
杀掉数据库进程没有是帮助的，因为回滚在服务器启动时会再次启动。除掉一个失控的回滚的唯一方法是增大缓冲池使得回滚变成CPU绑定且跑得快或者使用专用步骤。
http://marksverbiage.blogspot.com/2008/04/improve-reliability-and-maintainability.html
这里有个极端：用无状态的连接来保证可靠性，用MySQL API层就可以提供自动重连机制。
如果用无状态的连接，那连接相关的：事务，临时表，session变量就得慎用！
那如何可以继续使用事务呢？
自动提交事务：并且将每个事务用单条语句提交，或者用存储过程。
3）不用用表锁 -- 这个是为表级别锁的存储引擎设计工作的
4）主键
尽可能使用主键查找数据；
实际中遇到的问题：之前在一个应用的Master上有3个表，我们所有的UPDATE和INSERT都是使用PK来进行的，由于以前还部署了一些查询的应用，有很多联合索引，后来
迁移到SLAVE后，我们认为这些索引会占据更多的数据空间，而且现在也不会继续用到，因此在Master上删除了所有这些"无用"的索引，因为我们每个UPDATE操作都会直接使用PK，
这些索引本来应该是无用的？可导致的结果竟然是平均UPDATE操作由之前的100ms增长到180ms左右，WHY？
前天，另外一件事情，我们在某个表增加了一些联合索引后，表空间竟然变的更小了！
参考：
http://www.innodb.com/innodb/info/
http://www.innodb.com/wp/wp-content/uploads/2007/05/uc2007-innodb-performance-optimization.pdf
InnoDB Performance Optimization
InnoDB can perform extremely well or be your performance nightmare if you do not tune it right. This talk is about InnoDB performance optimization, covering a wide range of topics from Server Settings optimization, to InnoDB specific query optimization, including hardware configuration and OS tuning tricks. This presentation was delivered at the 2007 MySQL User Conference by Peter Zaitsev of Percona, Ltd. and Heikki Tuuri. You will find this and other presentations and articles about MySQL and InnoDB performance on the MySQL Performance Blog.
--EOF--
Leave a comment