need help implementing InnoDB storage engine to existing database - mysql

I am trying to add primary keys to my tables, via Sequel Pro and it said "This table currently does not support relations. Only tables that use the InnoDB storage engine support them."
I went into phpMyAdmin and looked at the storage engines and saw InnoDB listed, highlighted in blue, then I selected it and it displayed this info: http://cl.ly/68Ph
It is enabled, but I am unsure how to implement it to my existing database, any help is appreciated.

You should tell your tables to use InnoDB:
ALTER TABLE mytable ENGINE=InnoDB
for existing tables,
CREATE TABLE mytable (…) ENGINE=InnoDB
for the new ones.
Note that InnoDB supports neither SPATIAL nor FULLTEXT indexes so don't use it if your application relies on them.

Related

Do tables with InnoDB engines can be corrupted when the default storage engine database is MyIsam?

I am developing a website for ecommerce and I'm using foreign keys for my tables relationship in my database. So I decided to use InnoDB engine for all of my tables in MySQL. But my hosting server used MyIsam for default storage engine databases and I cannot change it to InnoDB. One day, one table in my database with InnoDB engine is being corrupted and error. It says " table does not exists in engine ".
I have asked hosting customer service but they can't give me solutions.
Does my table cannot be accessed because of different engine between table and database? Because all of my tables are using InnoDB as engine but my database default storage engine is using MyIsam.
Please give me some explanation about how and maybe the solution to my problem. Thank you.
The default storage engine is relevant only if you create a table, but you don't declare the engine explicitly.
// uses the default storage engine:
CREATE TABLE mytable ( ... );
// uses innodb storage engine, regardless of default:
CREATE TABLE mytable ( ... ) ENGINE=InnoDB;
If you declare your table with ENGINE=InnoDB, it stays that way. Changing the default storage engine to MyISAM should not have any effect on existing tables. It only affects tables created subsequently, and only if they don't specify the engine.
The error "table does not exist in engine" happens when you try to query a table but the tablespace has been discarded with ALTER TABLE mytable DISCARD TABLESPACE, or if the .ibd file has been deleted from the filesystem.
This means someone destroyed your data. Unless you have a backup, there is no way to recover it now.
InnoDB has been the default storage engine since 2010. It's time to treat it as the primary way to take care of data in MySQL.
I hope you will find a new hosting provider.

MySQL:START TRANSACTION - UPDATE - ROLLBACK : Non-Transactional Tables

I'm attempting to run these queries to perform a ROLLBACK, and I'm not too sure what I'm doing wrong, but I get a warning:
Some non-transactional changed tables couldn't be rolled back.
After a bit of research I found that the most likely cause for this message is the false assumption that a table is transactional, but is actually not. How does one determine which tables are transactional?
I have to assume that the database I'm using uses rollback because it's in the assignment that I'm given for the class that requires us to use the database.
Tables that use the InnoDB storage engine, or those using the NDB cluster storage engine, support transactions; the other engines do not. (There's a comparison table somewhere in the documentation, but I can't find it right now.)
To check a specific table, use
SHOW CREATE TABLE <tablename>;
which will show you the complete CREATE TABLE statement, including the ENGINE clause.
To check which engines are installed in your database, use
SHOW ENGINES;
If you have InnoDB installed but it is not the default engine, you can either specify ENGINE=InnoDB in the CREATE TABLE statement or change it later with
ALTER TABLE <tablename> ENGINE = InnoDB;

Geodjango and Innodb, mixed innodb and myisam models

I keep hearing that InnoDB is better for data integrity, unfortunately as of MySQL 5.6 it has yet to support SPATIAL indexes. A fast SPATIAL index is pretty critical to my app, though what's nice about my model that it's pretty much results in a fairly static (write once, read many) table of (ID, POINT), so I could use MyISAM and not care too much.
I'd like to restrict the use of MyISAM to just that table, and migrate it over when InnoDB support for SPATIAL is ready. Problem is, if I ALTER TABLE after my models are migrated (by having an app/sql/app_model.sql) to switch the table to MyISAM, MySQL complains:
ERROR 1217 (23000): Cannot delete or update a parent row: a foreign key constraint fails
That makes sense, my other models refer to this one and Django automatically makes FOREIGN KEY constraints between those models and this one.
What's the best strategy here? Should I abandon InnoDB and switch everything back to MyISAM? Can I just drop all the FOREIGN KEY constraints?
I tried automating the FOREIGN KEY drops by looking in INFORMATION_SCHEMA.TABLE_CONSTRAINTS, but that only lists the tables that have the constraints, not the tables referred to by those constraints. I would have to do some fuzzy column name matching which feels very brittle.
To solve this I gave up on using InnoDB by default. Because Amazon RDS makes Inno the default, I did this by adding an init_command in my settings.py:
'default': {
'OPTIONS': {
'init_command' : 'SET storage_engine=MYISAM', # Can't make SPATIAL keys on InnoDB
},
}
Then for all but the table with a SPATIAL index I created a $modelname.sql file under the $appname/sql directory that changes the engine after it's created.
-- Alter to InnoDB so we can make concurrent insertions w/o full table lock.
ALTER TABLE <modeltable> ENGINE=INNODB;
Switching to MYISAM default means Django doesn't automatically create the FOREIGN KEY constraints for you for your Inno tables which isn't ideal. I wish there was a way to make Django create them after-the-fact.

MySQL change engine on tables with Foreign Keys

So, in the process of creating our tables, we weren't paying close enough attention to our system and all of the tables were created with the InnoDB engine. This is really only bad because we want to have a FULLTEXT index on a few of the columns.
So, now I want to convert. And while I'm at it, I just want to convert all the tables to MyISAM so that if we ever add columns in the future that we want to index, we have that option. So I've got my .sql file with the following:
ALTER TABLE tableName1 Engine = MyISAM;
ALTER TABLE tableName2 Engine = MyISAM;
However, when I try to run it, I get the following error:
Error Code: 1217 Cannot delete or update a parent row: a foreign key constraint fails
As you might have guessed, we have foreign keys in our tables. Not my style, but also not my department, nor my creation script.
My question boils down to, is there anyway for me to change the engine on these tables without having to wipe the DB?
Edit: Note that this will need to be done on multiple development and test copies of the database, so something I can script would definitely be preferred.
Well, to my knowledge, sort of but not really. mysqldump the database and edit out the foreign key constraints in the dumped sql file. And of course change the engine in the CREATE TABLE script.
InnoDB unlike MyISAM support foreign keys and has lots of great features like transactional system that ensures integrity across all tables. MyISAM tables tend to fail now and then when you have large data in tables or for many other reasons.
In the near future InnoDB will implement FullText search. I recommend not to change tables' engine but have something like Sphinx in place. Sphinx is much more powerful and much more flexible than Fulltext Search which works for InnoDB.
More about fulltext search in InnoDB:
InnoDB Fulltext search

MySQL shared hosting: db is MyISAM, although all created tables are InnoDB. Can I switch? Should I?

My question is about the Type of db that is on a shared hosting Linux server. phpMyAdmin shows that db has MyISAM Type. I don't think I can change it. I mean I don't know.
All tables in that db have InnoDB type.
Does it make sense to change db type to InnoDB? Should I? (I don't know if I can choose a db type on a shared hosting server).
Of course I can contact a customer support and ask them to switch if they can, but I don't know if it makes any sense and has any pros.
Should I take care of it?
Thank you.
Added: The image above is a screenshot from phpMyAdmin.
This is the default storage engine of the server. If you do not specify a storage engine when creating a table then the server picks MyISAM as the default
For example on my server InnoDB is the default.
mysql> show engines\G
*************************** 1. row ***************************
Engine: InnoDB
Support: DEFAULT
Comment: Supports transactions, row-level locking, and foreign keys
Transactions: YES
XA: YES
Savepoints: YES
Also in answer to your second question. Yes you can change the storage engine. You can do this with the ALTER TABLE command.
ALTER TABLE mytable ENGINE=MYISAM;
I suggest not to change storage engines unless you have a specific need for a feature in an engine.
You might misunderstanding, database does not have a storage engine.
The storage engine is meant for table.
You can only switch the storage engine for tables.
However, myisam does not support transactional,
and innodb (mysql version <5.6) does not support full-text search.
Without knowing which tables in which database,
my guess is you should not change the storage engine.
Example :-
http://demo.phpmyadmin.net/STABLE/index.php?lang=en&collation_connection=utf8_general_ci
The bottom row showing in phpmyadmin is the equivalent of :-
show create database YOUR_DATABASE;
when you create new table without specify a storage engine,
the default storage engine type on the database will apply to it.
for mysql version 5.5, default storage engine is change to innodb.
there is no direct way to change database default storage engine after you have create a database
the workaround is create a new database with you desired default storage engine,
then rename all the tables currently reside in the existing database to this database.