MySQL : 테이블을 만들 수 없음 (errno : 150)
.sql 파일을 가져 오려고하는데 테이블 생성에 실패합니다.
실패한 쿼리는 다음과 같습니다.
CREATE TABLE `data` (
`id` int(10) unsigned NOT NULL,
`name` varchar(100) NOT NULL,
`value` varchar(15) NOT NULL,
UNIQUE KEY `id` (`id`,`name`),
CONSTRAINT `data_ibfk_1` FOREIGN KEY (`id`) REFERENCES `keywords` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
동일한 데이터베이스에서 .sql을 내 보냈고 모든 테이블을 삭제하고 가져 오려고하는데 왜 실패합니까?
MySQL : './dbname/data.frm'테이블을 만들 수 없음 (errno : 150)
로부터 MySQL을 - FOREIGN KEY 제약 조건 문서 :
삭제 된 테이블을 다시 작성하는 경우 테이블을 참조하는 외래 키 제약 조건을 따르는 정의가 있어야합니다. 올바른 열 이름과 유형이 있어야하며 앞에서 언급 한대로 참조 된 키에 대한 색인이 있어야합니다. 이것들이 만족되지 않으면, MySQL은 오류 1005를 반환하고 오류 메시지에서 오류 150을 참조하는데, 이는 외래 키 제약 조건이 올바르게 형성되지 않았 음을 의미합니다. 마찬가지로 오류 150으로 인해 ALTER TABLE이 실패하면 변경된 테이블에 대해 외래 키 정의가 잘못 형성되었음을 의미합니다.
오류 150은 외래 키에 문제가 있음을 의미합니다. 외래 테이블의 키가 정확히 같은 유형이 아닐까요?
실행 SHOW ENGINE INNODB STATUS;
후 LATEST FOREIGN KEY ERROR
출력 을 찾아 실제 오류 메시지를 얻을 수 있습니다 .
출처 : 비슷한 질문에 다른 사용자의 답변
데이터 유형이 정확히 일치해야합니다. varchar 유형을 처리하는 경우 테이블은 동일한 데이터 정렬을 사용해야합니다.
나는 올바른 대답은 모두 질문으로 오도한다고 생각합니다.
외래 키로 덤프 파일을 복원하는 경우 복원을 시작하기 전에 실제 대답은 다음과 같습니다.
SET FOREIGN_KEY_CHECKS=0;
당연히 외부 테이블이 존재하기 전에 복원이 일부 제한 조건을 작성하기 때문입니다.
관련 테이블간에 엔진이 다른 경우이 오류 메시지가 표시 될 수 있습니다. 예를 들어, 테이블은 InnoDB를 사용하고 다른 테이블은 MyISAM을 사용합니다. 둘 다 같아야합니다
오류 번호 150은 외래 키 제약 조건 실패를 의미합니다. 외래 키가 의존하는 테이블 (table keywords
) 전에이 테이블을 생성하고있을 것입니다 . 해당 테이블을 먼저 작성하면 제대로 작동합니다.
그렇지 않은 경우 외래 키 문을 제거하고 테이블을 만든 후에 추가하십시오. 특정 제약 조건 실패에 대한보다 의미있는 오류 메시지가 나타납니다.
errno 150을 유발할 수있는 몇 가지 사항이 있으므로이 주제를 검색하는 사람들을 위해 다음은 철저한 목록에 가까운 것으로 생각되는 것입니다 (출처 : Errno 150 ).
errno 150 또는 errno 121의 경우 SHOW ENGINE INNODB STATUS에 간단히 입력하면 "LATEST FOREIGN KEY ERROR"라는 섹션이 있습니다. 그 아래에는 매우 유용한 오류 메시지가 표시되며 일반적으로 문제가 무엇인지 즉시 알려줍니다. 이를 실행하려면 SUPER 권한이 필요하므로이를 보유하지 않은 경우 다음 시나리오를 테스트하기 만하면됩니다.
1) 데이터 유형이 일치하지 않음 : 열 유형이 같아야합니다
2) 상위 열이 색인화되지 않음 (또는 잘못된 순서로 색인화 됨)
3) 열 데이터 정렬이 일치하지 않습니다
4) NOT NULL 열에 SET NULL 사용
5) 테이블 데이터 정렬이 일치하지 않음 : 일부 데이터 정렬 버전에서는 열 데이터 정렬이 일치하더라도 문제가 될 수 있습니다.
6) 부모 열이 실제로 부모 테이블에 존재하지 않습니다. 철자 검사 (및 열의 시작 또는 끝에 공백)
7) 열 중 하나의 색인 중 하나가 불완전하거나 열이 너무 길어서 완전한 색인을 작성할 수 없습니다. MySQL을 조정하지 않는 한 최대 단일 열 키 길이는 767 바이트입니다 (varchar (255) UTF 열에 해당).
오류 번호가 121 인 경우 다음과 같은 두 가지 원인이 있습니다.
1) 선택한 구속 조건 이름이 이미 사용되었습니다.
2) 명령문 및 테이블 이름에 대소 문자가 다른 경우 일부 시스템에서. 한 대의 서버에서 다른 대 / 소문자 처리 규칙이있는 다른 서버로 갈 경우이 문제가 발생할 수 있습니다.
때때로 MySQL은 매우 어리석은 일입니다. 외래 키의 원인을 이해할 수 있습니다.하지만 제 경우에는 전체 데이터베이스를 삭제했지만 여전히 오류가 발생합니다. 왜? 내 말은, 더 이상 데이터베이스가 없습니다 ... 그리고 사용중인 SQL 사용자가 서버의 다른 DB에 액세스 할 수 없습니다 ... 즉, 서버가 현재 사용자에 대해 "비어있다"고 여전히 얻습니다. 이 오류? 미안하지만 MySQL이 나에게 거짓말을하고 있다고 생각하지만 ... 내가 처리 할 수 있습니다 :) 성가신 문장 주위 에이 두 줄의 SQL을 추가하십시오.
SET FOREIGN_KEY_CHECKS = 0;
# some code that gives you errno: 150
SET FOREIGN_KEY_CHECKS = 1;
이제 sql을 실행해야합니다 ... 실제로 외래 키 문제가있는 경우 검사를 다시 활성화 할 수있는 라인별로 표시됩니다. 그런 다음 실패합니다 ..하지만 내 서버는 조용합니다 :)
위의 답변을 검토하고 약간의 실험을 한 후에 이것은 MySQL의 외래 키 오류를 해결하는 효과적인 방법입니다 (1005-오류 150).
외래 키를 올바르게 만들려면 모든 MySQL에서 요청하는 내용은 다음과 같습니다.
- 참조 된 모든 키에는 PRIMARY 또는 UNIQUE 인덱스가 있어야합니다.
- 참조 열은 반드시 참조 열과 동일한 데이터 유형을 가져야합니다.
이러한 요구 사항을 충족하면 모든 것이 잘 될 것입니다.
I experienced this error when have ported Windows application to Linux. In Windows, database table names are case-insensitive, and in Linux they are case-sensitive, probably because of file system difference. So, on Windows table Table1
is the same as table1
, and in REFERENCES
both table1
and Table1
works. On Linux, when application used table1
instead of Table1
when it created database structure I saw error #150; when I made correct character case in Table1
references, it started to work on Linux too. So, if nothing else helps, make you sure that in REFERENCES
you use correct character case in table name when you on Linux.
Change the engines of your tables, only innoDB supports foreign keys
If the PK table is created in one CHARSET and then you create FK table in another CHARSET..then also you might get this error...I too got this error but after changing the charset to PK charset then it got executed without errors
create table users
(
------------
-------------
)DEFAULT CHARSET=latin1;
create table Emp
(
---------
---------
---------
FOREIGN KEY (userid) REFERENCES users(id) on update cascade on delete cascade)ENGINE=InnoDB, DEFAULT CHARSET=latin1;
This error can occur if two tables have a reference, for example, one table is Student and another table is Education, and we want the Education table to have a foreign key reference of Student table. In this instance the column data type for both tables should be same, otherwise it will generate an error.
In most of the cases the problem is because of the ENGINE dIfference .If the parent is created by InnoDB then the referenced tables supposed to be created by MyISAM & vice versa
In my case. I had problems with engine and charset because my Hosting server change settings and my new tables was MyISAM but my old tables are InnoDB. Just i changed.
usually, the mismatch between foreign key & primary key causes the error:150.
The foreign key must have the same datatype as the primary key. Also, if the primary key is unsigned then the foreign key must also be unsigned.
I had same issue. It was related to table's column Collation and Character Set. Make sure Character Set and Collation must be same for both columns on two tables. If you want to set a foreign key on that. Example- If you put foreign key on userID column of userImage table referencing userID column of users table.Then Collation must be same that is utf8_general_ci and Character set utf8 for both columns of tables. Generally when you create a table mysql takes these two configuration from server settings.
Please make sure both your primary key column and referenced column have the same data types and attributes (unsigned, binary, unsigned zerofill etc).
A real edge case is where you have used an MySQL tool, (Sequel Pro in my case) to rename a database. Then created a database with the same name.
This kept foreign key constraints to the same database name, so the renamed database (e.g. my_db_renamed) had foreign key constraints in the newly created database (my_db)
Not sure if this is a bug in Sequel Pro, or if some use case requires this behaviour, but it cost me best part of a morning :/
I had the same error. In my case the reason for the error was that I had a ON DELETE SET NULL statement in the constraint while the field on which I put the constraint in its definition had a NOT NULL statement. Allowing NULL in the field solved the problem.
I faced this kind of issue while creating DB from the textfile.
mysql -uroot -padmin < E:\important\sampdb\createdb.sql
mysql -uroot -padmin sampdb < E:\important\sampdb\create_student.sql
mysql -uroot -padmin sampdb < E:\important\sampdb\create_absence.sql
mysql -uroot -padmin sampdb < E:\important\sampdb\insert_student.sql
mysql -uroot -padmin sampdb < E:\important\sampdb\insert_absence.sql
mysql -uroot -padmin sampdb < E:\important\sampdb\load_student.sql
mysql -uroot -padmin sampdb < E:\important\sampdb\load_absence.sql
I just wrote the above lines in Create.bat
and run the bat file.
My mistake is in the sequence order of execution in my sql files. I tried to create table with primary key and also foreign key. While its running it will search for the reference table but tables are not there. So it will return those kind of error.
If you creating tables with foreign key then check the reference tables were present or not. And also check the name of the reference tables and fields.
I had a similar problem but mine was because i was adding a new field to an existing table that had data , and the new field was referencing another field from the parent table and also had the Defination of NOT NULL and without any DEFAULT VALUES. - I found out the reason things were not working was because
- My new field needed to autofill the blank fields with a value from the parent table on each record, before the constraint could be applied. Every time the constraint is applied it needs to leave the Integrity of the table data intact. Implementing the Constraint (Foreign Key) yet there were some database records that did not have the values from the parent table would mean the data is corrupt so MySQL would NEVER ENFORCE YOUR CONSTRAINT
It is important to remember that under normal circumstances if you planned your database well ahead of time, and implemented constraints before data insertion this particular scenario would be avoided
The easier Approach to avoid this gotcha is to
- Save your database tables data
- Truncate the table data (and table artifacts i.e indexes etc)
- Apply the Constraints
- Import Your Data
I Hope this helps someone
Perhaps this will help? The definition of the primary key column should be exactly the same as the foreign key column.
Make sure that the all tables can support foreign key - InnoDB engine
The column of PARENT table to which you are referring to from child table has to be unique. If it is not, cause an error no 150.
I had a similar problem when dumping a Django mysql database with a single table. I was able to fix the problem by dumping the database to a text file, moving the table in question to the end of the file using emacs and importing the modified sql dump file into the new instance.
HTH Uwe
I've corrected the problem by making the variable accept null
ALTER TABLE `ajout_norme`
CHANGE `type_norme_code` `type_norme_code` VARCHAR( 2 ) CHARACTER SET utf8 COLLATE utf8_general_ci NULL
I got the same problem when executing a series of MySQL commands. Mine occurs during creating a table when referencing a foreign key to other table which was not created yet. It's the sequence of table existence before referencing.
The solution: Create the parent tables first before creating a child table which has a foreign key.
Create the table without foreign key, then set the foreign key separately.
참고URL : https://stackoverflow.com/questions/4061293/mysql-cant-create-table-errno-150
'programing tip' 카테고리의 다른 글
UNIX 소켓 파일에 대한 mysqld_safe 디렉토리 '/ var / run / mysqld'가 존재하지 않습니다. (0) | 2020.06.10 |
---|---|
안드로이드에서 원형 ProgressBar를 만드는 방법은 무엇입니까? (0) | 2020.06.10 |
실행 : stdout“live”표시 (0) | 2020.06.10 |
오류 1045 (28000) : 사용자 'root'@ 'localhost'에 대한 액세스가 거부되었습니다 (암호 사용 : 예). (0) | 2020.06.10 |
pm2가 'npm start'스크립트를 실행할 수 있습니까 (0) | 2020.06.10 |