# concurrent\_insert feature understanding

**URL:** <https://forums.percona.com/t/concurrent-insert-feature-understanding/556>\
**Category:** Other MySQL® Questions\
**Created:** [December 6, 2007, 6:39am UTC](https://forums.percona.com/t/concurrent-insert-feature-understanding/556 "2007-12-06T06:39:13Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Xuekun](https://avatars.discourse-cdn.com/v4/letter/x/b38774/32.png) [@Xuekun](https://forums.percona.com/u/Xuekun)\
**Post date:** [December 6, 2007, 6:39am UTC](https://forums.percona.com/t/concurrent-insert-feature-understanding/556/1 "2007-12-06T06:39:13Z")

</div>

Hi, peter

I happened to find your “Optimizing MySQL on source code level” slides for mysql conference 2006 ( [http://www.mysqlperformanceblog.com/files/presentations/UC20](http://www.mysqlperformanceblog.com/files/presentations/UC20) 06-Optimizing-MySQL-on-Source-Code-Level.pdf ). In your slides, you talked about key\_root\_lock rwlock that cause the bad scaling of MyISAM. And by disabling concurrent\_insert feature, the scaling is improved.

I recently used standard sysbench (read only mode, 14 reads) to test MySQL5.1.22. I found that the thread scaling is ~1.52x from 2 threads to 4 threads (maybe acceptable for some guys) with concurrent\_insert enabled. While with concurrent\_insert disabled, the thread scaling improved to ~1.9x from 2 threads to 4 threads. Wow, this scaling 1.9x is what I want. The test environment is 2 x Intel XEON Dual-Core processors and SuSE10 (2.6.16.46-0.12-smp).

From my understanding, disabling concurrent\_insert feature is only beneficial to read-intensive application. However for real read/write mix applications, I think still need to enable concurrent\_insert feature. Do you know how much benefit concurrent\_insert could give?

Thx, Xuekun

---

<div class="post-metadata">

**Author:** ![sterin](https://avatars.discourse-cdn.com/v4/letter/s/3ab097/32.png) [@sterin](https://forums.percona.com/u/sterin)\
**Post date:** [December 6, 2007, 7:42am UTC](https://forums.percona.com/t/concurrent-insert-feature-understanding/556/2 "2007-12-06T07:42:33Z")

</div>

Even though I’m not Peter I will try to answer your question to the best of my abilities (sorry Peter if I take your job )).

| [B]Xuekun wrote on Thu, 06 December 2007 13:09[/B] |
| From my understanding, disabling concurrent\_insert feature is only beneficial to read-intensive application. However for real read/write mix applications, I think still need to enable concurrent\_insert feature. Do you know how much benefit concurrent\_insert could give? |

The answer is as always that it depends.

In this case on how much concurrency you actually have in your application, how long the selects take to run and if it is OK for the inserting thread to wait until the table is available or if you possibly can use INSERT DELAYED instead.

But notice that this optimization is only working for INSERT’s, so if you also have a lot of UPDATE’s also then it’s an entirely other ballgame.

So I usually recommend switching to InnoDB and row level locks when I see someone having problem with read/write concurrency and MyISAM tables.

---

<div class="post-metadata">

**Author:** ![Xuekun](https://avatars.discourse-cdn.com/v4/letter/x/b38774/32.png) [@Xuekun](https://forums.percona.com/u/Xuekun)\
**Post date:** [December 6, 2007, 6:53pm UTC](https://forums.percona.com/t/concurrent-insert-feature-understanding/556/3 "2007-12-06T18:53:10Z")

</div>

Thanks for your suggestion. I will do more testing to understand them.