<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Some little known facts about Innodb Insert Buffer</title>
	<atom:link href="http://www.mysqlperformanceblog.com/2009/01/13/some-little-known-facts-about-innodb-insert-buffer/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.mysqlperformanceblog.com/2009/01/13/some-little-known-facts-about-innodb-insert-buffer/</link>
	<description>Percona&#039;s MySQL &#38; InnoDB performance and scalability blog</description>
	<lastBuildDate>Sat, 11 Feb 2012 16:45:54 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
	<item>
		<title>By: mz</title>
		<link>http://www.mysqlperformanceblog.com/2009/01/13/some-little-known-facts-about-innodb-insert-buffer/comment-page-1/#comment-787035</link>
		<dc:creator>mz</dc:creator>
		<pubDate>Wed, 15 Dec 2010 00:07:29 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/?p=587#comment-787035</guid>
		<description>Innodb locking problem with unique keys when inserting

CREATE TABLE `male_id` (
  `entry_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `jy_id` int(10) unsigned NOT NULL,
  PRIMARY KEY (`entry_id`),
  UNIQUE KEY `jy_id` (`jy_id`)
) ENGINE=InnoDB AUTO_INCREMENT=1

When 10 processes concurrently inserting rows to the above table, only the rows from one process are actually recorded in the table. I tested with autocommit=1 and even when transaction_isolation_level=seriazable. It seems Innodb is not doing locking properly. If I remove the primary key (entry_id), the problem remains. But the problem is gone if I change the unique key (jy_id) to be index (jy_id).</description>
		<content:encoded><![CDATA[<p>Innodb locking problem with unique keys when inserting</p>
<p>CREATE TABLE `male_id` (<br />
  `entry_id` int(10) unsigned NOT NULL AUTO_INCREMENT,<br />
  `jy_id` int(10) unsigned NOT NULL,<br />
  PRIMARY KEY (`entry_id`),<br />
  UNIQUE KEY `jy_id` (`jy_id`)<br />
) ENGINE=InnoDB AUTO_INCREMENT=1</p>
<p>When 10 processes concurrently inserting rows to the above table, only the rows from one process are actually recorded in the table. I tested with autocommit=1 and even when transaction_isolation_level=seriazable. It seems Innodb is not doing locking properly. If I remove the primary key (entry_id), the problem remains. But the problem is gone if I change the unique key (jy_id) to be index (jy_id).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Wagner Bianchi</title>
		<link>http://www.mysqlperformanceblog.com/2009/01/13/some-little-known-facts-about-innodb-insert-buffer/comment-page-1/#comment-674821</link>
		<dc:creator>Wagner Bianchi</dc:creator>
		<pubDate>Mon, 09 Nov 2009 17:30:07 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/?p=587#comment-674821</guid>
		<description>OK, Peter...thank you...I was missunderstood.</description>
		<content:encoded><![CDATA[<p>OK, Peter&#8230;thank you&#8230;I was missunderstood.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: peter</title>
		<link>http://www.mysqlperformanceblog.com/2009/01/13/some-little-known-facts-about-innodb-insert-buffer/comment-page-1/#comment-673887</link>
		<dc:creator>peter</dc:creator>
		<pubDate>Fri, 06 Nov 2009 16:41:27 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/?p=587#comment-673887</guid>
		<description>Wagner,

It is not pages but records which are being inserted.  Merged records are those which are in place on the pages where should be. Unmerged records are ones stored in insert buffer and so still to be merged.</description>
		<content:encoded><![CDATA[<p>Wagner,</p>
<p>It is not pages but records which are being inserted.  Merged records are those which are in place on the pages where should be. Unmerged records are ones stored in insert buffer and so still to be merged.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Wagner Bianchi</title>
		<link>http://www.mysqlperformanceblog.com/2009/01/13/some-little-known-facts-about-innodb-insert-buffer/comment-page-1/#comment-673868</link>
		<dc:creator>Wagner Bianchi</dc:creator>
		<pubDate>Fri, 06 Nov 2009 15:55:53 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/?p=587#comment-673868</guid>
		<description>Can you give me an explaination about `merged` and `unmerged` pages?</description>
		<content:encoded><![CDATA[<p>Can you give me an explaination about `merged` and `unmerged` pages?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dan Dascalescu</title>
		<link>http://www.mysqlperformanceblog.com/2009/01/13/some-little-known-facts-about-innodb-insert-buffer/comment-page-1/#comment-611017</link>
		<dc:creator>Dan Dascalescu</dc:creator>
		<pubDate>Thu, 09 Jul 2009 11:19:45 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/?p=587#comment-611017</guid>
		<description>Solid state drives are not the big revolution. The big revolution is nano-wire memory: &lt;a href=&quot;http://msmvps.com/blogs/harrywaldron/archive/2007/10/08/nanowire-storage-100-000-year-retention-with-terabyte-storage-capacities.aspx&quot; rel=&quot;nofollow&quot;&gt;1000 faster than Flash memory&lt;/a&gt;, terabyte capacity, and lower power consumption.

This will &lt;a href=&quot;http://wiki.dandascalescu.com/essays/databases_are_misguided&quot; rel=&quot;nofollow&quot;&gt;render databases obsolete&lt;/a&gt;, along with silly tricks involving hard disk rotation cycles.</description>
		<content:encoded><![CDATA[<p>Solid state drives are not the big revolution. The big revolution is nano-wire memory: <a href="http://msmvps.com/blogs/harrywaldron/archive/2007/10/08/nanowire-storage-100-000-year-retention-with-terabyte-storage-capacities.aspx" rel="nofollow">1000 faster than Flash memory</a>, terabyte capacity, and lower power consumption.</p>
<p>This will <a href="http://wiki.dandascalescu.com/essays/databases_are_misguided" rel="nofollow">render databases obsolete</a>, along with silly tricks involving hard disk rotation cycles.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Morgan Tocker</title>
		<link>http://www.mysqlperformanceblog.com/2009/01/13/some-little-known-facts-about-innodb-insert-buffer/comment-page-1/#comment-566842</link>
		<dc:creator>Morgan Tocker</dc:creator>
		<pubDate>Mon, 25 May 2009 20:07:55 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/?p=587#comment-566842</guid>
		<description>Pavel,

The 100k max writes refers to the cheaper MLC (Multi layer) Flash.  SLC (aimed more at the server end) can sustain a higher number of writes.</description>
		<content:encoded><![CDATA[<p>Pavel,</p>
<p>The 100k max writes refers to the cheaper MLC (Multi layer) Flash.  SLC (aimed more at the server end) can sustain a higher number of writes.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Pavel</title>
		<link>http://www.mysqlperformanceblog.com/2009/01/13/some-little-known-facts-about-innodb-insert-buffer/comment-page-1/#comment-461774</link>
		<dc:creator>Pavel</dc:creator>
		<pubDate>Mon, 02 Feb 2009 12:21:31 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/?p=587#comment-461774</guid>
		<description>Pat, will solid state disks survive database workload with their 100k possible writes only?</description>
		<content:encoded><![CDATA[<p>Pat, will solid state disks survive database workload with their 100k possible writes only?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: peter</title>
		<link>http://www.mysqlperformanceblog.com/2009/01/13/some-little-known-facts-about-innodb-insert-buffer/comment-page-1/#comment-446896</link>
		<dc:creator>peter</dc:creator>
		<pubDate>Fri, 16 Jan 2009 06:53:24 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/?p=587#comment-446896</guid>
		<description>Baron, 

I planned another post about it.  As I remember this patch is still in development, is not it ?</description>
		<content:encoded><![CDATA[<p>Baron, </p>
<p>I planned another post about it.  As I remember this patch is still in development, is not it ?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Baron Schwartz</title>
		<link>http://www.mysqlperformanceblog.com/2009/01/13/some-little-known-facts-about-innodb-insert-buffer/comment-page-1/#comment-446872</link>
		<dc:creator>Baron Schwartz</dc:creator>
		<pubDate>Fri, 16 Jan 2009 05:07:06 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/?p=587#comment-446872</guid>
		<description>You didn&#039;t mention that the Percona patches provide control over the insert buffer.</description>
		<content:encoded><![CDATA[<p>You didn&#8217;t mention that the Percona patches provide control over the insert buffer.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: peter</title>
		<link>http://www.mysqlperformanceblog.com/2009/01/13/some-little-known-facts-about-innodb-insert-buffer/comment-page-1/#comment-446841</link>
		<dc:creator>peter</dc:creator>
		<pubDate>Fri, 16 Jan 2009 03:17:31 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/?p=587#comment-446841</guid>
		<description>Pat, 

You&#039;re right. The storage industry is changed and I expect the best performance will be reached with systems which have not been written yet.  Storage engines as well as MySQL often has assumptions about disk being rotating disk.</description>
		<content:encoded><![CDATA[<p>Pat, </p>
<p>You&#8217;re right. The storage industry is changed and I expect the best performance will be reached with systems which have not been written yet.  Storage engines as well as MySQL often has assumptions about disk being rotating disk.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

