수색…


오류 코드 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=0CHANGE 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_limittable_open_cache 늘립니다.

5.6.8부터 open_files_limitmax_connections 기준으로 자동 크기 조정되지만 기본값에서 변경하는 것이 좋습니다.

1062 - 중복 입력

이 오류는 주로 다음 두 가지 이유로 인해 발생합니다.

  1. 중복 값 - 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);
  1. 고유 데이터 필드 - Error Code: 1062. Duplicate entry 'A' for key 'code'

    열을 고유 한 것으로 지정하고 해당 열의 기존 값이있는 새 행을 삽입하려고하면이 오류가 발생합니다.

이 오류를 극복하려면 일반적인 INSERT 대신 INSERT IGNORE 를 사용하십시오. 삽입하려는 새로운 행이 기존 레코드를 복제하지 않으면, MySQL은 평소대로 그것을 삽입합니다. 레코드가 중복되면 IGNORE 키워드는 오류를 생성하지 않고 무시합니다.

INSERT IGNORE INTO userDetails VALUES (NULL ,'John', 'Doe', 1);


Modified text is an extract of the original Stack Overflow Documentation
아래 라이선스 CC BY-SA 3.0
와 제휴하지 않음 Stack Overflow