misc/firestuff
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

InnoDB as the default table type

Browse Source
This commit is contained in:
Ian Gulliver
2019-04-15 03:44:08 +00:00
parent c06104b589
commit 0c621f8bc5
4 changed files with 37 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
2011-08-09-innodb-as-the-default-table-type.html Normal file
View File

@@ -0,0 +1,18 @@
<!--# set var="title" value="InnoDB as the default table type" -->
<!--# set var="date" value="August 9, 2011" -->
<!--# include file="include/top.html" -->
<p>We recently switched from MyISAM to InnoDB as the default table type. This affects CREATE TABLE without an explicit ENGINE=, as well as implicitly-created tables for sorting and such. Mark had previously discussed issues with this <a href="http://mysqlha.blogspot.com/2009/06/what-could-possibly-go-wrong.html">here</a>, but we thought it was worth giving another try.</p>
<p>We've found a far more basic problem: KILL takes a long time. Consider the following:</p>
<pre><code>CREATE TABLE scratch.MyShortLivedTable
SELECT * FROM A JOIN B JOIN C....;
</code></pre>
<p>There's no ENGINE= there, so it uses the default table type. It seems to run at about the same speed as it did with MyISAM, but then you kill it. If it's MyISAM, the KILL takes effect immediately. If it's InnoDB, the CREATE is non-transactional and stays, but the implicit INSERTs have to be rolled back. If that query took 10 minutes, it may take 10 minutes to roll back, during which time the query is unkillable and MySQL won't shut down cleanly.</p>
<p>Our failovers rely on being able to kill all connections to a slave that they're promoting to master. Our backups rely on being able to shut down MySQL. We don't have a good answer for this, short of hardwiring ENGINE=MyISAM onto writes we know are going to be large.</p>
<!--# include file="include/bottom.html" -->

1
index.html
View File

@@ -20,6 +20,7 @@
<li>2016-Feb-15: <a href="2016-02-15-cable-modem-channel-party.html">Cable modem channel party</a></li>
<li>2016-Feb-01: <a href="2016-02-01-how-to-enrage-your-cable-modem.html">How to enrage your cable modem</a></li>
<li>2016-Feb-01: <a href="2016-02-01-hall-of-2-4-ghz-shame-2016-edition.html">Hall of 2.4 GHz Shame, 2016 Edition</a></li>
<li>2011-Aug-09: <a href="2011-08-09-innodb-as-the-default-table-type.html">InnoDB as the default table type</a></li>
<li>2011-Aug-08: <a href="2011-08-08-database-best-practices-for-future-scalability.html">Database best practices for future scalability</a></li>
<li>2011-Jul-12: <a href="2011-07-12-converting-subselects-to-joins.html">Converting subselects to joins</a></li>
<li>2011-Apr-22: <a href="2011-04-22-avoid-mysql-round-trips.html">Avoid MySQL round trips</a></li>

17
markdown/2011-08-09-innodb-as-the-default-table-type.md Normal file
View File

@@ -0,0 +1,17 @@
<!--# set var="title" value="InnoDB as the default table type" -->
<!--# set var="date" value="August 9, 2011" -->
<!--# include file="include/top.html" -->
We recently switched from MyISAM to InnoDB as the default table type. This affects CREATE TABLE without an explicit ENGINE=, as well as implicitly-created tables for sorting and such. Mark had previously discussed issues with this [here](http://mysqlha.blogspot.com/2009/06/what-could-possibly-go-wrong.html), but we thought it was worth giving another try.
We've found a far more basic problem: KILL takes a long time. Consider the following:
CREATE TABLE scratch.MyShortLivedTable
SELECT * FROM A JOIN B JOIN C....;
There's no ENGINE= there, so it uses the default table type. It seems to run at about the same speed as it did with MyISAM, but then you kill it. If it's MyISAM, the KILL takes effect immediately. If it's InnoDB, the CREATE is non-transactional and stays, but the implicit INSERTs have to be rolled back. If that query took 10 minutes, it may take 10 minutes to roll back, during which time the query is unkillable and MySQL won't shut down cleanly.
Our failovers rely on being able to kill all connections to a slave that they're promoting to master. Our backups rely on being able to shut down MySQL. We don't have a good answer for this, short of hardwiring ENGINE=MyISAM onto writes we know are going to be large.
<!--# include file="include/bottom.html" -->

1
markdown/index.md
View File

@@ -19,6 +19,7 @@
1. 2016-Feb-15: [Cable modem channel party](2016-02-15-cable-modem-channel-party.html)
1. 2016-Feb-01: [How to enrage your cable modem](2016-02-01-how-to-enrage-your-cable-modem.html)
1. 2016-Feb-01: [Hall of 2.4 GHz Shame, 2016 Edition](2016-02-01-hall-of-2-4-ghz-shame-2016-edition.html)
1. 2011-Aug-09: [InnoDB as the default table type](2011-08-09-innodb-as-the-default-table-type.html)
1. 2011-Aug-08: [Database best practices for future scalability](2011-08-08-database-best-practices-for-future-scalability.html)
1. 2011-Jul-12: [Converting subselects to joins](2011-07-12-converting-subselects-to-joins.html)
1. 2011-Apr-22: [Avoid MySQL round trips](2011-04-22-avoid-mysql-round-trips.html)