Ok, OS cache.
> There isn't really a million of block writes. The record gets
added to the block, but that gets modified in OS cache if we assume
MyISAM tables and in the Innodb buffer if we assume InnoDB tables.
As i known, the mysql writes the data to disk directly but does not use the Os
c
Honestly, I did not understand that. I did not say anything about being
complicated. What does mysql not use, caching??
Judging by experience, creating a unique index on say, a 200G table could be a
bitter one.
On 07.05.2012, at 19:26, Zhangzhigang wrote:
> Karen...
>
> The mysql does
Karen...
The mysql does not use this approach what you said which is complicated.
I agree with ohan De Meersman.
发件人： Karen Abgarian
收件人： mysql@lists.mysql.com
发送日期： 2012年5月8日, 星期二, 上午 1:30
主题: Re: 回复： Why is creating indexes faster after inserting massive d
Hi,
> D.1.1. Changes in MySQL 5.1.63 (7th May, 2012)
>
> 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.
--
MySQL General Ma
Good point about key buffer. I was only thinking about the table updates for
MyISAM, not indexes. The being stuck waiting for buffer flush could also
happen. However, for the table blocks this would be the same issue as with
load followed by index rebuild, and for the indexes, it will have
Hi,
A couple cents to this.
There isn't really a million of block writes. The record gets added to the
block, but that gets modified in OS cache if we assume MyISAM tables and in the
Innodb buffer if we assume InnoDB tables. In both cases, the actual writing
does not take place and does
As a side note, TokuDB uses what it calls "fractal technology" to somewhat
improve the performance of incremental INDEXing. They delay some of the BTree
work so that they can better batch stuff. While waiting for that to finish,
queries are smart enough to look in more than one place for the i
* Batch INSERTs run faster than one-row-at-a-time, but this is unrelated to
INDEX updating speed.
* The cache size is quite important to dealing with indexing during INSERT; see
http://mysql.rjweb.org/doc.php/memory
* Note that mysqldump sets up for an efficient creation of indexes after
loading
- Original Message -
> From: "Zhangzhigang"
> Ok, Creating the index *after* the inserts, the index gets created in
> a single operation.
> But the indexes has to be updating row by row after the data rows has
> all been inserted. Does it work in this way?
No, when you create an index on
Dear MySQL users,
MySQL Server 5.1.63, a new version of the popular Open Source
Database Management System, has been released. MySQL 5.1.63 is
recommended for use on production systems.
For an overview of what's new in MySQL 5.1, please see
http://dev.mysql.com/doc/refman/5.1/en/mysql-nutshell
too nice not to share it!
http://www.youtube.com/watch?v=INHF_5RIxTE
2012/5/7 Zhangzhigang
> Thanks, i thought about this answer in the past, and i appreciate your
> reply.
>
>
>
>
> 发件人： Alex Schaft
> 收件人： mysql@lists.mysql.com
> 发送日期： 2012年5月7日, 星期一, 下午 4:
Thanks, i thought about this answer in the past, and i appreciate your reply.
发件人： Alex Schaft
收件人： mysql@lists.mysql.com
发送日期： 2012年5月7日, 星期一, 下午 4:59
主题: Re: 回复： Why is creating indexes faster after inserting massive data rows?
On 2012/05/07 10:53, Zhangzh
Ok, but my opinion is that the sorting algorithms is not impact this
difference, two ways all do B+ tree inserts.
发件人： Claudio Nanni
收件人： Zhangzhigang
抄送： Johan De Meersman ; "mysql@lists.mysql.com"
发送日期： 2012年5月7日, 星期一, 下午 5:01
主题: Re: 回复： Why is creatin
Creating the index in one time is one macro-sort operation,
updating the index at every row is doing the operation on and on again.
If you do not understand the difference I recommend you to read some basics
about sorting algorithms,
very interesting read anyway.
Claudio
2012/5/7 Zhangzhigang
>
On 2012/05/07 10:53, Zhangzhigang wrote:
johan
Plain and simple: the indices get updated after every insert statement,
whereas if you only create the index *after* the inserts, the index gets
created in a single operation, which is a lot more efficient..
Ok, Creating the index *after* t
johan
>Plain and simple: the indices get updated after every insert statement,
whereas if you only create the index *after* the inserts, the index gets
created in a single operation, which is a lot more efficient..
Ok, Creating the index *after* the inserts, the index gets created in a sin
- Original Message -
> From: "Zhangzhigang"
>
> Creating indexes after inserting massive data rows is faster than
> before inserting data rows.
> Please tell me why.
Plain and simple: the indices get updated after every insert statement, whereas
if you only create the index *after* the
Version : Mysql 5.1
Engine : MyISAM.
The indexes are normal but neither primary key or unique key.
I should describe mysql question clearly.
When inserting massive data rows to table which need to be created indexes, i
can create indexes before inserting data rows, anther way is that i can i
- Original Message -
> From: "Charles Brown"
>
> Interestingly, over the years, I've been reading your postings and
> threads - without a doubt you're a major contributor. You've been
> very resourceful and helpful to your peers. We may never know what
> caused you to violently snap this
which version of mysql are you using.
Is this secondary index.?
On Mon, May 7, 2012 at 12:07 PM, Zhangzhigang wrote:
> hi all:
>
> I have a question:
>
> Creating indexes after inserting massive data rows is faster than before
> inserting data rows.
> Please tell me why.
>
20 matches
Mail list logo
