2次Update执行性能上的差异很大，请教原因

Question

大家好，
我的应用是这样的，对mysql中的一个表执行全表的update操作，这个表大概有1万条左右的数据，第一次执行花了约70秒，第二次执行只用了约7秒钟。这个表是innodb的存储引擎，数据库的table_cache设置为256，总共的数据库表约为100多个，数据库运行的操作系统是linux as5，请问大概是什么原因引起了这个现象呢？做什么配置可以让数据库每次执行都能达到原先第二次的执行效果呢？谢谢！

Answer 1

都是对同一张表进行操作？如果是，不仅是MYSQL，其它数据库(SQLSERVER、ACCESS、
SQLANYWHERE、VFP)等等都是如此，应该是在缓存(内存、系统临时表)中保存了经优化
的SQL语句 OR 结果，在SQL ANYWHERE中有一个参数是强制重新SQL语句，不用以前保留
的数据，估计是数据库运行机制造成的。

Answer 2

具体语句是什么？第二次估计是少了语句的分析过程。并且如果你的SQL中如果有SELECT之类的，第二次会直接从上次的缓存中取得。 但具体为什么要看了你的SQL语句之后再知道。

Answer 3

这个原因就是：第一次写数据的时候那些数据没有，所以要更新INNODB的 非聚簇索引里面的主键值。所以慢。
而第二次写数据的时候，因为引擎检测到主键值的分布不需要更新，所以时间很少。
当然语句的分析过程是有的。以上是我个人愚见，不对的大家批评改正。

Answer 4

谢谢大家的回复。
我这里的操作就是针对那一个表的，我还做了一个测试，在另外一台配置较差的机器上也安装了mysql数据库，跑同样的应用，奇怪的是在那台机器上，每次执行的效率都是一样的，都约7秒左右，为什么缓存在新的机器上没有什么效果呢？对比了两个数据库的设置参数，基本都是一样的，还有什么东西要设置吗？

Answer 5

给你看下这个东西吧。mysql> update ytt_inno set rank = 127 where id = 2;
Query OK, 0 rows affected (0.01 sec)
Rows matched: 1  Changed: 0  Warnings: 0mysql> show status like '%dirty%';
+--------------------------------+-------+
| Variable_name                  | Value |
+--------------------------------+-------+
| Innodb_buffer_pool_pages_dirty | 5     | 
+--------------------------------+-------+
1 row in set (0.00 sec)mysql> update ytt_inno set rank = 127 where id = 2;
Query OK, 0 rows affected (0.00 sec)
Rows matched: 1  Changed: 0  Warnings: 0mysql> show status like '%dirty%';
+--------------------------------+-------+
| Variable_name                  | Value |
+--------------------------------+-------+
| Innodb_buffer_pool_pages_dirty | 4     | 
+--------------------------------+-------+
1 row in set (0.00 sec)

Answer 6

我执行了楼上说的，结果如下：
mysql> show status like '%dirty%';
+--------------------------------+-------+
| Variable_name                  | Value |
+--------------------------------+-------+
| Innodb_buffer_pool_pages_dirty | 254   |
+--------------------------------+-------+
1 row in set (0.00 sec)
基本上Value都在250-300之间，是不是要把innodb_buffer_pool_size设置的大一些呢？现在这台机器的内存是3G，innodb_buffer_pool_size的设置应该是mysql的缺省配置。