innodb_index_stats가 데이터를 가져올 때 테이블 기본 키 충돌 오류에 대한 자세한 설명
다음 편집기에서는 innodb_index_stats가 백업 데이터를 가져올 때 테이블 기본 키 충돌 문제를 해결하는 방법에 대한 기사를 제공합니다. 에디터가 꽤 좋다고 생각해서 지금 공유해서 참고용으로 올려보겠습니다. 에디터를 따라가서 살펴보겠습니다.
오류 설명
percona5.6, mysqldump 전체 백업, 백업 데이터를 가져올 때 오류 'PRIMARY'
실패 원인
확인 결과, 이 기본 키 MySQL 시스템 라이브러리 아래에 있어야 합니다. 시스템 테이블 innodb_index_stats
mysql> show create table innodb_index_stats\G *************************** 1. row *************************** Table: innodb_index_stats Create Table: CREATE TABLE `innodb_index_stats` ( `database_name` varchar(64) COLLATE utf8_bin NOT NULL, `table_name` varchar(64) COLLATE utf8_bin NOT NULL, `index_name` varchar(64) COLLATE utf8_bin NOT NULL, `last_update` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, `stat_name` varchar(64) COLLATE utf8_bin NOT NULL, `stat_value` bigint(20) unsigned NOT NULL, `sample_size` bigint(20) unsigned DEFAULT NULL, `stat_description` varchar(1024) COLLATE utf8_bin NOT NULL, PRIMARY KEY (`database_name`,`table_name`,`index_name`,`stat_name`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin STATS_PERSISTENT=0 1 row in set (0.00 sec) mysql> select * from innodb_index_stats where database_name='hoc_log99' and table_name='item_log_27' and stat_name='n_diff_pfx01' and index_name='PRIMARY'; +---------------+-------------+------------+---------------------+--------------+------------+-------------+------------------+ | database_name | table_name | index_name | last_update | stat_name | stat_value | sample_size | stat_description | +---------------+-------------+------------+---------------------+--------------+------------+-------------+------------------+ | hoc_log99 | item_log_27 | PRIMARY | 2016-10-07 18:44:06 | n_diff_pfx01 | 823672 | 20 | redid | +---------------+-------------+------------+---------------------+--------------+------------+-------------+------------------+ 1 row in set (0.00 sec)
그런 다음 당시 백업 파일 sql의 기록을 확인한 결과 이 테이블을 다시 가져오기 전에 테이블이 다시 빌드된다는 것을 발견했습니다. 이는 작업 기록을 제외합니다. 이 테이블을 가져오기 전에 item_log_27 테이블의 innodb_index_stats 가능성.
-- Table structure for table `innodb_index_stats` DROP TABLE IF EXISTS `innodb_index_stats`; CREATE TABLE `innodb_index_stats` ( -- Dumping data for table `innodb_index_stats` LOCK TABLES `innodb_index_stats` WRITE; /*!40000 ALTER TABLE `innodb_index_stats` DISABLE KEYS */;
그래서 최근 binlog 기록을 확인해 보니 실제로 이 테이블을 재구축하는 작업이 있었네요
DROP TABLE IF EXISTS `innodb_index_stats` /* generated by server */ CREATE TABLE `innodb_index_stats` ( /*!40000 ALTER TABLE `innodb_index_stats` DISABLE KEYS */
결론
MySQL 5.6 버그, 다른 동료들도 같은 오류 발생
www .percona.com/forums/questions-discussions/mysql-and-percona-server/31971-mysql-innodb_index_stats-duplication-entry-error-on-restore
bugs.mysql.com /bug .PHP?id=71814
솔루션
1 mysqldump가 이 테이블의 백업을 무시하도록 매개변수를 추가합니다
2 변경 대체할 백업 파일에 이 테이블 삽입
3 mysql -f force import
[관련 권장 사항]
2.MySQL에서 새로운 사용자 권한을 추가하는 자세한 예
3.MySQL에서 비밀번호 및 액세스 제한을 변경하는 자세한 예
4.정규식을 사용하여 데이터베이스의 내용을 바꾸는 자세한 예 해결방법
5.mysql에 이미지를 저장하는 PHP의 예에 대한 자세한 설명
위 내용은 innodb_index_stats가 데이터를 가져올 때 테이블 기본 키 충돌 오류에 대한 자세한 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!

핫 AI 도구

Undresser.AI Undress
사실적인 누드 사진을 만들기 위한 AI 기반 앱

AI Clothes Remover
사진에서 옷을 제거하는 온라인 AI 도구입니다.

Undress AI Tool
무료로 이미지를 벗다

Clothoff.io
AI 옷 제거제

Video Face Swap
완전히 무료인 AI 얼굴 교환 도구를 사용하여 모든 비디오의 얼굴을 쉽게 바꾸세요!

인기 기사

뜨거운 도구

메모장++7.3.1
사용하기 쉬운 무료 코드 편집기

SublimeText3 중국어 버전
중국어 버전, 사용하기 매우 쉽습니다.

스튜디오 13.0.1 보내기
강력한 PHP 통합 개발 환경

드림위버 CS6
시각적 웹 개발 도구

SublimeText3 Mac 버전
신 수준의 코드 편집 소프트웨어(SublimeText3)

뜨거운 주제











index.html은 웹 페이지의 홈 페이지 파일을 나타내며 웹 사이트의 기본 페이지입니다. 사용자가 웹사이트를 방문하면 일반적으로 index.html 페이지가 먼저 로드됩니다. HTML(HypertextMarkupLanguage)은 웹 페이지를 만드는 데 사용되는 마크업 언어이며 index.html도 HTML 파일입니다. 여기에는 웹페이지의 구조와 콘텐츠는 물론 서식 지정과 레이아웃에 사용되는 태그와 요소도 포함됩니다. 다음은 index.html 코드의 예입니다. <

InnoDB는 MySQL의 데이터베이스 엔진 중 하나이며 현재 MySQL AB의 바이너리 릴리스 표준 중 하나입니다. InnoDB는 이중 트랙 인증 시스템을 채택합니다. 하나는 GPL 인증이고 다른 하나는 독점 소프트웨어입니다. 권한 부여. InnoDB는 트랜잭션 데이터베이스에 선호되는 엔진이며 트랜잭션 보안 테이블(ACID)을 지원합니다. InnoDB는 최대 범위의 동시성을 지원할 수 있는 행 수준 잠금을 지원합니다.

InnoDB는 디스크의 테이블에 데이터를 저장하는 스토리지 엔진이므로 종료하고 다시 시작한 후에도 데이터가 계속 존재합니다. 실제 데이터 처리 과정은 메모리에서 일어나므로 디스크에 있는 데이터를 메모리에 로드해야 하며, 쓰기나 수정 요청을 처리하는 경우에도 메모리에 있는 내용을 디스크에 새로 고쳐야 합니다. 그리고 우리는 디스크를 읽고 쓰는 속도가 매우 느리다는 것을 알고 있습니다. 이는 메모리에서 읽고 쓰는 것과는 몇 배 정도 다릅니다. 따라서 테이블에서 특정 레코드를 얻으려면 InnoDB 스토리지 엔진이 읽어야 합니다. 디스크의 레코드가 하나씩? InnoDB가 채택한 방식은 데이터를 여러 페이지로 나누고, 디스크와 메모리 간 상호 작용의 기본 단위로 페이지를 사용하는 것입니다. InnoDB의 페이지 크기는 일반적으로 16입니다.

1. mysql을 롤백하고 다시 설치합니다. 다른 위치에서 이 데이터를 가져오는 문제를 방지하려면 먼저 현재 라이브러리의 데이터베이스 파일(/var/lib/mysql/location)을 백업합니다. 다음으로 Perconaserver5.7 패키지를 제거하고 원래의 이전 5.1.71 패키지를 다시 설치하고 mysql 서비스를 시작했는데 Unknown/unsupportedtabletype:innodb 메시지가 표시되어 정상적으로 시작할 수 없었습니다. 11050912:04:27InnoDB:버퍼풀 초기화 중, 크기=384.0M11050912:04:27InnoDB:완료

MySQL 스토리지 엔진 선택 비교: InnoDB, MyISAM 및 메모리 성능 지수 평가 소개: MySQL 데이터베이스에서 스토리지 엔진의 선택은 시스템 성능과 데이터 무결성에 중요한 역할을 합니다. MySQL은 다양한 스토리지 엔진을 제공하며, 가장 일반적으로 사용되는 엔진으로는 InnoDB, MyISAM 및 Memory가 있습니다. 이 기사에서는 이 세 가지 스토리지 엔진의 성능 지표를 평가하고 코드 예제를 통해 비교합니다. 1. InnoDB 엔진 InnoDB는 나의 것

1. Mysql 트랜잭션 격리 수준 이 네 가지 격리 수준은 여러 트랜잭션 동시성 충돌이 있는 경우 더티 읽기, 반복 불가능 읽기 및 팬텀 읽기 문제가 발생할 수 있으며 innoDB는 반복 읽기 격리 수준 모드에서 이를 해결합니다. 2. 팬텀 읽기란 동일한 트랜잭션에서 첫 번째 트랜잭션에서 범위 쿼리를 실행한 것처럼 전후에 동일한 범위를 두 번 쿼리했을 때 얻은 결과가 일치하지 않는 것을 의미합니다. 이때 조건에 맞는 데이터는 1개뿐이며, 두 번째 트랜잭션에서는 데이터 행을 삽입하여 제출합니다. 첫 번째 쿼리입니다. 첫 번째 트랜잭션의 첫 번째 쿼리와 두 번째 쿼리는 모두 동일합니다.

InnoDB의 전체 텍스트 검색 기능은 매우 강력하여 데이터베이스 쿼리 효율성과 대량의 텍스트 데이터를 처리 할 수있는 능력을 크게 향상시킬 수 있습니다. 1) InnoDB는 기본 및 고급 검색 쿼리를 지원하는 역 색인화를 통해 전체 텍스트 검색을 구현합니다. 2) 매치 및 키워드를 사용하여 검색, 부울 모드 및 문구 검색을 지원합니다. 3) 최적화 방법에는 워드 세분화 기술 사용, 인덱스의 주기적 재건 및 캐시 크기 조정, 성능과 정확도를 향상시키는 것이 포함됩니다.

MySQL은 널리 사용되는 데이터베이스 관리 시스템이며, 다양한 스토리지 엔진이 데이터베이스 성능에 서로 다른 영향을 미칩니다. MyISAM과 InnoDB는 MySQL에서 가장 일반적으로 사용되는 두 가지 스토리지 엔진으로 서로 다른 특성을 갖고 있으며 부적절한 사용은 데이터베이스 성능에 영향을 미칠 수 있습니다. 이 기사에서는 이 두 가지 스토리지 엔진을 사용하여 MySQL 성능을 최적화하는 방법을 소개합니다. 1. MyISAM 스토리지 엔진 MyISAM은 MySQL에 가장 일반적으로 사용되는 스토리지 엔진으로, 빠른 속도와 작은 저장 공간이 장점입니다. 마이ISA
