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
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
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:
>
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
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,
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
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
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
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
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.
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
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
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 -
- 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
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
- 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
- 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
17 matches
Mail list logo