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);