回复: Why is creating indexes faster after inserting massive data rows?

2012-05-08 Thread Zhangzhigang
James... >* By doing all the indexes after building the table (or at least all the >non-UNIQUE indexes), "sort merge" can be used.  This technique had been highly >optimized over the past half-century, and is more efficient. I have a question about "sort merge": Why does it do the all "sort me

回复: 回复: 回复: 回复: Why is creating indexes faster after inserting massive data rows?

2012-05-08 Thread Zhangzhigang
 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 收件人: mysql@lists.mysql.com 发送日期: 2012年5月9日, 星期三, 上午 2:51 主题: Re: 回复: 回复: 回复: Why is creating indexes faster after inserting

Re: 回复: 回复: 回复: Why is creating indexes faster after inserting massive data rows?

2012-05-08 Thread Karen Abgarian
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: >

Re: One table gets locked by itself

2012-05-08 Thread Claudio Nanni
Right, Technically not a deadlock, Practically yes if hundreds of threads are waiting on the same mutex, Like key cache one or query cache or any other mutex. Claudio On May 8, 2012 7:51 PM, "nixofortune" wrote: > Few more things. You can't have a deadlock on Mylsam table. You can check > status

Re: One table gets locked by itself

2012-05-08 Thread nixofortune
Few more things. You can't have a deadlock on Mylsam table. You can check status of your tables in use with: SHOW OPEN TABLES WHERE IN_USE !=0 you might check mysqld error log ad well On 8 May 2012 18:42, "nixofortune" wrote: > You might run out of file desciptors. Check your open file limits,

Re: One table gets locked by itself

2012-05-08 Thread Darryle Steplight
My plan B was basically what Rick and Claudio said. Check your my.conf file for this variable LONG_QUERY_TIME . That determines how long a query will run before it's considered slow. You may need to adjust that setting, but that will just get rid of the symptom and not the problem at hand. Findi

Re: One table gets locked by itself

2012-05-08 Thread nixofortune
You might run out of file desciptors. Check your open file limits, open table limits vars and corresponding syatus values On 8 May 2012 15:05, "abhishek jain" wrote: > Hi > > I am facing a strange problem, from the last few days in one of my projects > in production, i find that one of my table f

RE: One table gets locked by itself

2012-05-08 Thread Claudio Nanni
Not really. If its a deadlock , they all are victims. (E.g. mutex wait) Or a long running query (sending data) might be the guy. Claudio On May 8, 2012 7:31 PM, "Rick James" wrote: > Also,... If it happens again, do SHOW FULL PROCESSLIST while it is > happening. Usually the non-"Locked" entry

RE: One table gets locked by itself

2012-05-08 Thread Rick James
Also,... If it happens again, do SHOW FULL PROCESSLIST while it is happening. Usually the non-"Locked" entry is the villain. > -Original Message- > From: Darryle Steplight [mailto:dstepli...@gmail.com] > Sent: Tuesday, May 08, 2012 7:32 AM > To: abhishek jain > Cc: mysql@lists.mysql.co

Re: One table gets locked by itself

2012-05-08 Thread Darryle Steplight
In your my.conf or configuration file look for an attribute that says "LOG_SLOW_QUERIES " , that should point to the path of your slow query log. On Tue, May 8, 2012 at 10:19 AM, abhishek jain wrote: > Hi > Thanks, > Where can i find query log for previous one,or i have to do some config in > my.

RE: One table gets locked by itself

2012-05-08 Thread abhishek jain
Hi Thanks, Where can i find query log for previous one,or i have to do some config in my.ini file, please let me know, Thanks Abhi -Original Message- From: Darryle [mailto:dstepli...@gmail.com] Sent: 08 May 2012 19:42 To: abhishek jain Cc: Subject: Re: One table gets locked by itself C

Re: One table gets locked by itself

2012-05-08 Thread Darryle
Chech your query log for queries hitting that tables. Myisam tables dont have row level locking. There is probably a slow query somewhere. Sent from my iPhone On May 8, 2012, at 10:04 AM, "abhishek jain" wrote: > Hi > > I am facing a strange problem, from the last few days in one of my proje

回复: 回复: 回复: 回复: Why is creating indexes faster after inserting massive data rows?

2012-05-08 Thread Zhangzhigang
Ok, thanks for your help. 发件人: Johan De Meersman 收件人: Zhangzhigang 抄送: mysql@lists.mysql.com; Karen Abgarian 发送日期: 2012年5月8日, 星期二, 下午 6:07 主题: Re: 回复: 回复: 回复: Why is creating indexes faster after inserting massive data rows? - Original Message -

Re: MySQL Community Server 5.1.63 has been released

2012-05-08 Thread Johan De Meersman
- Original Message - > From: "Baron Schwartz" > >> Bugs Fixed >> * Security Fix: Bug #64884 was fixed. >> * Security Fix: Bug #59387 was fixed. > > Anyone want to elaborate on the nature or severity of the security > problem? Both are private / inaccessible to me. Bug #64884

MySQL Community Server 5.5.24 has been released

2012-05-08 Thread Joerg Bruehe
Dear MySQL users, MySQL 5.5.24 is a new version of the 5.5 production release of the world's most popular open source database. MySQL 5.5.24 is recommended for use on production systems. MySQL 5.5 includes several high-impact enhancements to improve the performance and scalability of the MySQL D

Re: 回复: 回复: 回复: Why is creating indexes faster after inserting massive data rows?

2012-05-08 Thread Johan De Meersman
- Original Message - > From: "Zhangzhigang" > > 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 file

Re: 回复: 回复: Why is creating indexes faster after inserting massive data rows?

2012-05-08 Thread Johan De Meersman
- Original Message - > From: "Zhangzhigang" > > The mysql does not use this approach what you said which is > complicated. > > I  agree with ohan De Meersman. Umm... It's not a matter of who you agree with :-) Karen's technical detail is quite correct; I merely presented a simplified pic