MySQL
오류 코드
수색…
오류 코드 1064 : 구문 오류
select LastName, FirstName,
from Person
메시지를 반환합니다.
오류 코드 : 1064. SQL 구문에 오류가 있습니다. MySQL 서버 버전에 해당하는 매뉴얼을 확인하여 올바른 구문이 2 번 줄의 'from Person'근처에서 사용할 수 있는지 확인하십시오.
MySQL에서 "1064 오류"메시지를받는 것은 구문 오류없이 쿼리를 구문 분석 할 수 없음을 의미합니다. 즉, 쿼리를 이해할 수 없습니다.
오류 메시지의 인용문은 MySQL이 구문 분석하는 방법을 알 수없는 쿼리의 첫 번째 문자로 시작합니다. 이 예제에서 MySQL은 문맥 상 from Person
의미를 갖지 못한다. 이 경우 from Person
바로 앞에 쉼표가 추가됩니다. 쉼표는 MySQL에게 SELECT
절에 다른 열 설명을 기대하도록 지시합니다.
구문 오류는 항상 ... near '...'
라고 말합니다. 따옴표의 시작 부분은 오류가있는 곳과 매우 가깝습니다. 오류를 찾으려면 따옴표의 첫 번째 토큰과 따옴표 앞에있는 마지막 토큰을 확인하십시오.
때로는 ... near ''
; 즉, 따옴표 안에 아무것도. 즉, MySQL이 알 수없는 첫 번째 문자는 명령문의 끝이나 시작 부분에 있습니다. 이는 쿼리에 불균형 따옴표 ( '
또는 "
) 또는 불균형 괄호가 포함되어 있거나 정확하게 전에 문을 종료하지 않았 음을 나타냅니다.
저장 루틴 (stored routine)의 경우 DELIMITER
를 올바르게 사용하는 것을 잊어 버렸을 수 있습니다.
따라서 오류 1064가 발생하면 쿼리의 텍스트를보고 오류 메시지에 언급 된 요점을 찾으십시오. 해당 지점 주변의 쿼리 텍스트를 시각적으로 검사하십시오.
누군가에게 오류 1064 문제를 해결하도록 도움을 청하면 전체 쿼리의 텍스트와 오류 메시지의 텍스트를 모두 제공하는 것이 가장 좋습니다.
오류 코드 1175 : 안전 업데이트
이 오류는 KEY
열을 사용하는 WHERE
절을 포함하지 않고 레코드를 업데이트하거나 삭제하려고 할 때 나타납니다.
삭제 또는 업데이트를 실행하려면 다음을 입력하십시오.
SET SQL_SAFE_UPDATES = 0;
안전 모드를 다시 사용하려면 다음을 입력하십시오.
SET SQL_SAFE_UPDATES = 1;
오류 코드 1215 : 외래 키 제약 조건을 추가 할 수 없습니다.
이 오류는 테이블이 개발자가 요구하는 외래 키 ( FK
) 요구 사항의 신속한 조회 검증을 처리 할 수 있도록 적절하게 구조화되지 않은 경우에 발생합니다.
CREATE TABLE `gtType` (
`type` char(2) NOT NULL,
`description` varchar(1000) NOT NULL,
PRIMARY KEY (`type`)
) ENGINE=InnoDB;
CREATE TABLE `getTogethers` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`type` char(2) NOT NULL,
`eventDT` datetime NOT NULL,
`location` varchar(1000) NOT NULL,
PRIMARY KEY (`id`),
KEY `fk_gt2type` (`type`), -- see Note1 below
CONSTRAINT `gettogethers_ibfk_1` FOREIGN KEY (`type`) REFERENCES `gtType` (`type`)
) ENGINE=InnoDB;
주 1 : 이와 같은 KEY는 필요한 경우 FK 정의에 따라 자동으로 생성됩니다. 개발자는이를 건너 뛸 수 있으며 필요한 경우 KEY (일명 색인)가 추가됩니다. 개발자가 건너 뛰는 예가 someOther
아래에 표시되어 있습니다.
지금까지 그렇게 좋았어.
CREATE TABLE `someOther` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`someDT` datetime NOT NULL,
PRIMARY KEY (`id`),
CONSTRAINT `someOther_dt` FOREIGN KEY (`someDT`) REFERENCES `getTogethers` (`eventDT`)
) ENGINE=InnoDB;
오류 코드 : 1215. 외래 키 제약 조건을 추가 할 수 없습니다.
이 경우 때문에 참조 된 테이블에서 인덱스의 부족으로 실패 getTogethers
의 신속한 조회를 처리 할 수 eventDT
. 다음 성명에서 해결 될 것입니다.
CREATE INDEX `gt_eventdt` ON getTogethers (`eventDT`);
테이블 getTogethers
가 수정되어 someOther
의 작성이 성공합니다.
MySQL 매뉴얼 페이지에서 FOREIGN KEY 제약 조건 사용하기 :
MySQL은 외래 키 검사가 빠르며 테이블 스캔이 필요하지 않도록 외래 키와 참조 키에 대한 인덱스가 필요합니다. 참조하는 테이블에는 외부 키 열이 같은 순서로 첫 번째 열로 나열되는 인덱스가 있어야합니다. 이러한 인덱스는 참조 테이블에 자동으로 작성됩니다 (존재하지 않는 경우).
외부 키와 참조 된 키의 해당 열은 유사한 데이터 유형을 가져야합니다. 정수 유형의 크기와 부호는 동일해야합니다. 문자열 유형의 길이는 동일 할 필요는 없습니다. 이항 (문자) 문자열 열의 경우 문자 집합과 데이터 정렬이 동일해야합니다.
InnoDB는 외래 키가 인덱스 열 또는 열 그룹을 참조 할 수있게합니다. 그러나 참조 된 테이블에는 참조 된 열이 같은 순서로 첫 번째 열로 나열되는 인덱스가 있어야합니다.
첫 번째 (맨 왼쪽) 열과 첫 번째 주요 요구 사항이 부족한 점에 대해 마지막 점을 지적하십시오.
참조 (하위) 테이블을 성공적으로 생성하면 자동으로 생성 된 모든 키가 다음과 같은 명령으로 표시됩니다.
SHOW CREATE TABLE someOther;
이 오류를 경험하는 다른 일반적인 경우는 문서에서 언급했듯이 다음과 같습니다. 강조해야합니다.
INT
와의 사소한 차이점이INT UNSIGNED
가리키며 서명되었습니다.개발자가 다중 열 (복합) KEYS 및 첫 번째 (가장 왼쪽) 주문 요구 사항을 이해하는 데 어려움이 있습니다.
1045 액세스가 거부되었습니다.
"GRANT"및 "root 암호 복구"의 토론을 참조하십시오.
1236 복제에서 "불가능한 위치"
대개 마스터가 충돌하고 sync_binlog
가 OFF 였음을 의미합니다. 해결 방법은 슬레이브의 다음 binlog 파일 (마스터 참조)의 CHANGE MASTER to POS=0
으로 CHANGE MASTER to POS=0
를 CHANGE MASTER to POS=0
하는 것입니다.
원인 : 마스터가 binlog로 플러시하기 전에 복제 항목을 슬레이브로 보냅니다 ( sync_binlog=OFF
). 플러시 전에 마스터가 충돌하면 슬레이브가 이미 논리적으로 파일 끝 부분을 지나서 이동합니다. 마스터가 다시 시작되면 새 binlog가 시작되므로 binlog의 시작 부분을 변경하면 사용 가능한 최상의 솔루션입니다.
여분의 I / O가 발생할 경우 sync_binlog=ON
하십시오.
(GTID를 사용하는 경우 ...?)
2002, 2003 연결할 수 없습니다.
방화벽 문제 차단 포트 3306을 확인하십시오.
가능한 진단 및 / 또는 솔루션
- 서버가 실제로 실행되고 있습니까?
- "service firewalld stop"및 "systemctl disable firewalld"
- 텔넷 마스터 3306
-
bind-address
확인 - check
skip-name-resolve
- 소켓을 확인하십시오.
1067, 1292, 1366, 1411 - 숫자, 날짜, 기본값 등의 값이 잘못되었습니다.
1067 이는 시간이 지남에 따라 변경된 TIMESTAMP
기본값과 관련이 있습니다. 날짜 및 시간 페이지의 TIMESTAMP defaults
을 참조하십시오. (아직 존재하지 않음)
1292/1366 DOUBLE / Integer 문자 또는 기타 구문 오류를 점검하십시오. 열이 정렬되는지 확인하십시오. 아마도 당신은 VARCHAR
넣고 있다고 생각 하겠지만 숫자로 된 열과 정렬됩니다.
1292 DATETIME 과거 또는 미래가 너무 먼지 확인하십시오. 일광 절약 시간이 변경된 오전 2 시부 터 새벽 3 시까 지 확인하십시오. +00
시간대와 같은 잘못된 구문을 확인하십시오.
1292 VARIABLE SET
하려고하는 VARIABLE
의 허용 값을 확인하십시오.
1292 LOAD DATA '나쁜'줄을보십시오. 이스케이프 기호 등을 확인하십시오. 데이터 유형을 확인하십시오.
1411 STR_TO_DATE 형식이 잘못 되었습니까?
126, 127, 134, 144, 145
MySQL 데이터베이스에서 레코드에 액세스하려고하면 이러한 오류 메시지가 나타날 수 있습니다. 이 오류 메시지는 MySQL 데이터베이스의 손상으로 인해 발생했습니다. 다음은 유형입니다.
MySQL error code 126 = Index file is crashed
MySQL error code 127 = Record-file is crashed
MySQL error code 134 = Record was already deleted (or record file crashed)
MySQL error code 144 = Table is crashed and last repair failed
MySQL error code 145 = Table was marked as crashed and should be repaired
MySQL의 버그, 바이러스 공격, 서버 충돌, 부적절한 종료, 손상된 테이블이 손상의 원인입니다. 손상되면 액세스 할 수 없으므로 더 이상 액세스 할 수 없습니다. 액세스 가능성을 얻으려면 업데이트 된 백업에서 데이터를 검색하는 가장 좋은 방법입니다. 그러나 업데이트 된 백업이나 유효한 백업이없는 경우 MySQL 복구를 수행 할 수 있습니다.
테이블 엔진 유형이 MyISAM
인 경우 CHECK TABLE
적용한 다음 REPAIR TABLE
을 적용하십시오.
그렇다면 InnoDB로 변환하는 것에 대해 진지하게 생각하십시오. 따라서이 오류는 다시 발생하지 않습니다.
통사론
CHECK TABLE <table name> ////To check the extent of database corruption
REPAIR TABLE <table name> ////To repair table
139
오류 139는 테이블 정의의 필드 수와 크기가 일부 제한을 초과 할 수 있음을 나타냅니다. 해결 방법 :
- 스키마를 다시 생각해보십시오.
- 일부 필드 정상화
- 테이블을 세로로 분할
1366 년
이것은 대개 문자 집합 처리가 클라이언트와 서버간에 일관성이 없음을 의미합니다. 추가 지원을 보려면 ...을 참조하십시오.
126, 1054, 1146, 1062, 24
(휴식을 취함)이 4 가지 오류 번호를 포함 시키면이 페이지는 사용자가 범하는 전형적인 오류의 약 50 %를 차지할 것으로 생각됩니다.
(예,이 '예'는 수정이 필요합니다.)
24 파일을 열 수 없습니다 (열려있는 파일이 너무 많음)
open_files_limit
는 OS 설정에서옵니다. table_open_cache
는 그보다 작을 필요가 있습니다.
다음과 같은 오류가 발생할 수 있습니다.
저장 프로 시저에서
DEALLOCATE PREPARE
실패.파티션이 많은 PARTITIONED 테이블과 innodb_file_per_table = ON. 주어진 테이블에 50 개 이상의 파티션이없는 것을 권장합니다 (다양한 이유로). ( "네이티브 파티션"을 사용할 수있게되면이 조언이 변경 될 수 있습니다.)
확실한 해결 방법은 OS 제한을 높이는 것입니다. 더 많은 파일을 허용하려면 ulimit
또는 /etc/security/limits.conf
변경하거나 sysctl.conf
(kern.maxfiles & kern.maxfilesperproc) 또는 다른 것 (OS에 따라 다름)을 변경하십시오. 그런 다음 open_files_limit
및 table_open_cache
늘립니다.
5.6.8부터 open_files_limit
는 max_connections
기준으로 자동 크기 조정되지만 기본값에서 변경하는 것이 좋습니다.
1062 - 중복 입력
이 오류는 주로 다음 두 가지 이유로 인해 발생합니다.
중복 값 -
Error Code: 1062. Duplicate entry '12' for key 'PRIMARY'
기본 키 열은 고유하며 중복 된 항목을 허용하지 않습니다. 따라서 이미 테이블에있는 새로운 행을 삽입하려고하면이 오류가 발생합니다.
이 문제를 해결하려면 기본 키 열을
AUTO_INCREMENT
로 설정하십시오. 새 행을 삽입 할 때 기본 키 열을 무시하거나NULL
값을 기본 키에 삽입하십시오.
CREATE TABLE userDetails(
userId INT(10) NOT NULL AUTO_INCREMENT,
firstName VARCHAR(50),
lastName VARCHAR(50),
isActive INT(1) DEFAULT 0,
PRIMARY KEY (userId) );
--->and now while inserting
INSERT INTO userDetails VALUES (NULL ,'John', 'Doe', 1);
고유 데이터 필드 -
Error Code: 1062. Duplicate entry 'A' for key 'code'
열을 고유 한 것으로 지정하고 해당 열의 기존 값이있는 새 행을 삽입하려고하면이 오류가 발생합니다.
이 오류를 극복하려면 일반적인
INSERT
대신INSERT IGNORE
를 사용하십시오. 삽입하려는 새로운 행이 기존 레코드를 복제하지 않으면, MySQL은 평소대로 그것을 삽입합니다. 레코드가 중복되면IGNORE
키워드는 오류를 생성하지 않고 무시합니다.
INSERT IGNORE INTO userDetails VALUES (NULL ,'John', 'Doe', 1);