Oh... I thought that it uses it's own buffer cache as same as the InnoDB. I 
have got a mistake for this,  thanks!



________________________________
 发件人: Karen Abgarian <a...@apple.com>
收件人: mysql@lists.mysql.com 
发送日期: 2012年5月9日, 星期三, 上午 2:51
主题: Re: 回复: 回复: 回复: Why is creating indexes faster after inserting massive data 
rows?
 
Hi, 

If MyISAM tables were being written directly to disk, the MyISAM tables would 
be so slow that nobody would ever use them.    That's the cornerstone of their 
performance, that the writes do not wait for the physical I/O to complete!



On May 8, 2012, at 3:07 AM, Johan De Meersman wrote:

> ----- Original Message -----
>> From: "Zhangzhigang" <zzgang_2...@yahoo.com.cn>
>> 
>> As i known, the mysql writes the data to disk directly but does not
>> use the Os cache when the table is updating.
> 
> If it were to use the OS cache for reading but not writing, then the OS cache 
> would be inconsistent with the underlying filesystem as soon as you wrote a 
> block, and you'd need some complicated logic to figure out which of the two 
> was correct.
> 
> No, the MyISAM engine will simply yield to whatever the kernel/VFS wants to 
> do with the blocks; whereas InnoDB explicitly opens the files with O_SYNC and 
> bypasses the OS cache entirely, because it manages it's own buffer cache.
> 
>> If it writes to the Os cache, which leads to massive system invoking,
>> when the table is inserted a lot of rows one by one.
> 
> From the code's point of view, you simply request a read or a write. Wether 
> or not the OS cache gets in between is entirely a matter for the kernel to 
> decide, assuming you specified no specific options at file open time.
> 
> 
> -- 
> Bier met grenadyn
> Is als mosterd by den wyn
> Sy die't drinkt, is eene kwezel
> Hy die't drinkt, is ras een ezel
> 
> -- 
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe:    http://lists.mysql.com/mysql
> 


-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:    http://lists.mysql.com/mysql

Reply via email to