I have created a foreign key with NaviCat (a MySQL application), but the instant I create it, it disappears from the foreign key list and a new Index get added. Does that mean something went wrong or is that normal to happen?
I have tried using the information_schema How to check if a column is already a foreign key? but that resulted in Unknown table 'REFERENTIAL_CONSTRAINTS' in information_schema. Is it possible that query is for MsSQL and is different with MySQL?
The table you are probably creating the foreign key is MyISAM. Go to the Table Design view and go to the Options tab to change the table Engine to InnoDB
You can change all your tables to InnoDB following the steps at http://kevin.vanzonneveld.net/techblog/article/convert_all_tables_to_innodb_in_one_go/
Add default-storage-engine=innodb in the [mysqld] section of your MySQL configuration file (usually my.cnf) from http://dev.mysql.com/doc/refman/5.5/en/innodb-default-se.html
There are no flaws after all from MySQL 5.5 InnoDB is the default storage engine.
execute
SHOW CREATE TABLE myTable;
and then check for
ENGINE = InnoDB
if this is true, you can use foreign keys. check if it contains something like this:
FOREIGN KEY (customer_id) REFERENCES customer(id)
hope that helps !
Related
My server data .. Ubuntu - NGINX - MySQL
I need to create a table in wordpress database with a foreign key with wp_posts table .. but I noticed that to create a foreign key in the new table I must include ENGINE keyword into create table statement, I don't know why but creating foreign key failed when ENGINE keyword not included.
Of course I need this statement to be programmatically for my clients so I cannot include ENGINE='USER DB ENGINE' .. So Is there anyway to use the default database engine?
P.S. I should include ENGINE keyword.
MySQL supports foreign keys only for specific database engines. The two most commonly used and present in an installation are:
MyISAM
InnoDB
InnoDB supports foreign key constraints, MyISAM does not. It is somewhere on the to do list to implement foreign key constraints in MyISAM, however nobody got to that in the last 15 years (plus/minus a few).
I executed script related to create my database ..it executed successfully. but no foreign keys created . I am using cent os . mysql 5.0.
If the DB engine is one that does not support FK, it will show you no errors, but won't create them. For example, MyIsam.
Choose InnoDB as the table type to be able to create FK on it.
are the tables in MyISAM instead of InnoDB?
MyISAM don't support foreign keys.
Currently the storage type of table is innodb , i want to add full text search on the table which is only possible on MYISAM engine.
I tried using the command => alter table film engine = myisam;
and got the error:
1217 - Cannot delete or update a parent row: a foreign key constraint fails
Help Please!!
Thanks.
You must find the tables in the database that refer to this table through a FK constraint:
Identify the foreign key constraints for the table. Either use
SHOW CREATE TABLE `table_in_db_film`\G;
or
USE db_of_film_table;
SHOW TABLE STATUS LIKE 'film'\G
afterwards execute the necessary statements
ALTER TABLE film DROP FOREIGN KEY `ibfk_something`;
until you drop all constraints (of course replace ibfk_something with your constraint names). After this you should be able to alter the table engine.
You can't change the table's engine to MyISAM without removing the Foreign Key constraints and thus losing integrity.
It would be better to use both engines, MyISAM and InnoDB. Keep all data in InnoDB and duplicate the table (or just the columns you want to be full-text searching) in MyISAM. This will need some mechanism (triggers) for the data duplication to be automated.
Other options here: MySQL storage engine dilemma
I have an InnoDB table claims which has about 240 million rows. The table has a foreign key constraint: CONSTRAINT FK78744BD7307102A9 FOREIGN KEY (ID) REFERENCES claim_details (ID). I want to delete the table claim_details as quickly as possible.
Based on some experimentation it seems that if I use SET foreign_key_checks = 0; drop claim_details and then re-enable foreign keys, mysql will continue to enforce the constraint even though the table no longer exists. So, I believe I must drop the constraint from the table.
I have tried to use ALTER TABLE claims DROP FOREIGN KEY FK78744BD7307102A9 to drop the constraint and the query has been in a state of "copy to tmp table" for over 24 hours (on a machine with no other load). I don't understand why dropping a constraint requires making a copy of the table. Is there any way to prevent this?
mysql version 5.1.48.
Starting with MySQL 5.6, MySQL supports dropping of foreign keys in-place/without copying. Oracle calls this Online DDL.
This table lists all Online DDL operations and their runtime behavior.
From my experience, dropping foreign keys and the corresponding constraints on a 600GB table is almost instantaneous. With 5.5 it would probably have taken days.
The only disadvantage that I am aware of is, that 5.6 does not allow you to reclaim table space. I.e. if you are using innodb_file_per_table, that file will not shrink when you drop indices. Only the unused data in the file will grow. You can easily check using SHOW TABLE STATUS, and the Data_free column.
I think there is no a good way to drop that foreign key
http://dev.mysql.com/doc/refman/5.5/en/innodb-create-index-limitations.html
"MySQL 5.5 does not support efficient creation or dropping of FOREIGN KEY constraints. Therefore, if you use ALTER TABLE to add or remove a REFERENCES constraint, the child table is copied, rather than using Fast Index Creation." This probably refers also to older versions of mysql.
I think the best method will be to dump data from claims with mysqldump, recreate table without foreign key referencing to claim_details, disable key check with SET foreign_key_checks = 0; in case you have other foreign keys and import back data for claims. Just remember to make separate dumps for data and structure so you don't need to edit this huge file to remove foreign key from table creation syntax.
When I create a foreign key in MySQL workbench, a new entry appears on the "Indexes" tab with the exact same same as the foreign key that I just created.
Is this actually the foreign key, showing up on the "Indexes" tab for some reason? Or does MySQL Workbench try to be helpful and create an index for me, knowing that I'm likely to be selecting against that column, and give it (confusingly) the same name as the foreign key?
It's MySQL doing that, not workbench.
And yes, it is being helpful to create an index when you create a foreign key constraint.
Foreign keys in innodb require an index or a prefix of an index with the same fields as the constraint in the same order. It seems MySQL Workbench automatically creates these since they appear in the SQL script exported from MySQL Workbench.
This is helpful but the problem is that it does not recognize the prefix from other indexes so it always creates an index even when it is unnecessary.