tag:blogger.com,1999:blog-58871127230049401472024-02-18T23:37:48.263-08:00into MySQLMySQL, InnoDB, MyISAMUnknownnoreply@blogger.comBlogger83125tag:blogger.com,1999:blog-5887112723004940147.post-52696821572926031982011-01-30T18:58:00.000-08:002011-01-30T18:58:26.526-08:00MySQL 5.1.42 SELECT 쿼리의 SharedLock 관련 버그
MySQL 5.1.42 버전에서 SELECT 쿼리가 Shared(Read) Lock을 거는 버그가 있었다.
모든 쿼리가 그런 것이 아니라, 확인된 쿼리는 아래 형태의 SubQuery로 Counting하는 쿼리이다.
간단히 재현하는 방법은 아래와 같다.
-------------------------------------------------------------
Session 1
-------------------------------------------------------------
CREATE TABLE lock_test (
fd1 int not null,
fd2 int not null,
fd3 int not null,
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5887112723004940147.post-2638063060677989852011-01-13T01:54:00.000-08:002011-01-14T00:38:06.123-08:00MySQL 5.5 GA 버전 릴리즈 : 새로운 기능(New Features) 소개조금은 지난 일이지만, MySQL 5.5의 GA(General Available) 버전이 릴리즈 되었다.
이번 버전은 MySQL이 Oracle로 인수되고 난 이후 처음 릴리즈된 버전이다라는 것이
나름 Oracle 입장에서는 큰 의미를 주고 있는 듯 하며,
그 때문인지 이런 저런 새로운 기능들과 성능 향상을 WhitePaper에서 이야기하고 있다.
하지만, 대 부분은 InnoDB 가 플러그인 버전으로 변경되는 MySQL 5.1 수준에서
적용된 내용들이 재탕으로 이야기되고 있는 부분이 많고,
기존 버전에 비해 Linux는 370%, Windows는 1500%가 향상되었다고 이야기하고 있는데,
간단히 그래프를 보면, 개인적으로는 성능 향상이라고 하기보다는 동시성 처리가 상당히 개선되었다고
생각된다.
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5887112723004940147.post-65048997509845383682011-01-11T22:34:00.000-08:002011-01-11T22:34:10.724-08:00MySQL의 버전별 기능(Features) 변경 이력
VersionFeatures
추가변경삭제
5.5
MyISAM 대신 InnoDB가 MySQL의 기본 스토리지 엔진으로 채택
5.4.2
Plugin버전의 InnoDB가 Builtin 버전으로 다시 적용
5.1.38
InnoDB Plugin
5.1.24
(Enterprise version)
"SHOW PROFILE"
5.1.12
"general_log" 파라미터
General query log를 동적으로 변경 가능
5.1.8
"Mixed" 복제 모드
5.1.6
Partition pruning 기능
5.1.5
EXPLAIN PARTITIONS(파티션 테이블의 실행 계획) 지원Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-5887112723004940147.post-85345184877844856652011-01-03T22:12:00.000-08:002011-01-03T22:14:34.776-08:00JOIN DELETE (Multiple-table Delete)두개의 테이블을 조인하여 UPDATE를 실행하는 것(JOIN UPDATE)과 같이,
두개의 테이블을 조인하여 그 결과 레코드를 삭제하는 것도 가능하다.
이를 JOIN DELETE 또는 Multiple-Table DELETE라고 하는데,
JOIN DELETE는 아래 두 가지 문법으로 작성할 수 있다.
DELETE와 FROM 절 사이에 삭제할 테이블 명시DELETE t1, t2 FROM test1 t1 INNER JOIN test2 t2 INNER JOIN test3 t3WHERE t1.id=t2.id AND t2.id=t3.id;
FROM과 USING 절 사이에 삭제할 테이블 명시DELETE FROM t1, t2 USING test1 Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5887112723004940147.post-90998070034101962722011-01-03T21:47:00.000-08:002011-01-03T21:47:30.009-08:00JOIN UPDATE (Multiple-table Update)MySQL에서도 두개 이상의 테이블을 조인하여,
어떤 테이블의 필드 값을 또 다른 테이블의 컬럼에 업데이트하는 것이 가능하다.
물론, 이때 2개 이상의 테이블의 레코드를 상호 업데이트하는 것도 가능하다.
이러한 형태의 작업을 JOIN UPDATE 또는 Multiple table Update라고 표현한다.
아래의 쿼리를 한번 살펴보자.
UPDATE test1 t1, test2 t2
SET t1.target_fd=t2.source_fd
WHERE t1.fdpk=t2.fdpk;
이 쿼리는 test1 테이블과 test2 테이블을 fdpk 컬럼으로 조인한 뒤,
test2 테이블의 source_fd 컬럼의 값을 test1 테이블의 target_fd 컬럼에 업데이트를 실행하게 된다.
이 예제는 하나의 Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-5887112723004940147.post-31147927797381794412011-01-03T20:34:00.000-08:002011-01-03T20:35:09.266-08:00유용한 VI 명령어 모음저장 및 파일 읽기 명령
vi -r <파일명> : VI가 비정상 종료되었을 때, 작성중이던 파일을 복구한다. (Vi가 아닌 Shell명령)
:1,4w <파일명> : 1부터 4줄까지를 지정된 파일명으로 저장한다.
:r <파일명> : 현재 편집중인 내용에 <파일명> 파일의 내용을 읽어서 덧붙인다.
라인 삭제
d1G : 문서의 첫번째 줄부터 현재 이전 줄까지 삭제
dG : 문서의 현재 줄부터 끝까지 삭제
문서의 영역 선택 및 위치 마킹
mx : 현재 라인을 "x" 라는 이름으로 마킹 ('m' 다음 문자의 이름으로 현재 라인을 마킹)
v : Visual 영역 선택
명령 반복
. : 마지막 실행했던Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5887112723004940147.post-81013252816118633372011-01-03T07:22:00.000-08:002011-01-03T07:26:09.360-08:00DISTINCT 와 GROUP BY의 차이DISTINCT는 주로 UNIQUE한 컬럼이나 튜플(레코드)을 조회하는 경우 사용되며,
GROUP BY는 데이터를 그룹핑해서 그 결과를 가져오는 경우 사용되는 쿼리 형태이다.
하지만 두 작업은 조금만 생각해보면 동일한 형태의 작업이라는 것을 쉽게 알 수 있으며,
일부 작업의 경우 DISTINCT로 동시에 GROUP BY로도 처리될 수 있는 쿼리들이 있다.
그래서 DISTINCT를 사용해야 할지, GROUP BY를 사용해서 데이터를 조회하는 것이
좋을지 고민되는 경우들이 가끔 있다.
간단하게 아래 예를 살펴 보자
1. SELECT DISTINCT fd1 FROM tab;
2. SELECT DISTINCT fd1, fd2 FROM tab;
위의 두개 쿼리는 간단히 GROUP BY로 Unknownnoreply@blogger.com14tag:blogger.com,1999:blog-5887112723004940147.post-62479246307197395572011-01-02T01:18:00.000-08:002011-01-02T01:18:23.554-08:00PASSWORD()와 OLD_PASSWORD() 함수 그리고 old_passwords 설정
MySQL에서 사용자의 로그인 보안 수준을 높이기 위해서,
MySQL 4.0.x 이하 버전과 MySQL 4.1.x 이상 버전의 PASSWORD() 함수의 구현 알고리즘이 달라졌다.
사실 아주 오래전 이야기이지만, 아직도 MySQL 4.0.x를 사용하는 사이트가 많고,
최근 들어서 MySQL 5.1이나 5.5 버전으로 업그레이드를 준비하면서 이런 내용이
업그레이드에 걸림돌이 되는 경우가 많은 것으로 보인다.
MySQL 4.0.x 이하 버전
- PASSWORD()
- OLD_PASSWORD() 함수는 없음
mysql> SELECT PASSWORD('mypass');
+--------------------Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-5887112723004940147.post-89768627144935475582011-01-02T00:29:00.000-08:002011-01-02T00:30:51.171-08:00MySQL에서 MINUS와 INTERSECT 집합 연산INTERSECT 집합 연산 사용
INTERSECT 는 두개 집합에서 SELECT되는 튜플들을 모두 INNER JOIN의 조인 조건으로 포함시켜서 실행하면 쉽게 동일한 결과를 얻을 수 있다.
예제 쿼리)
SELECT member_id as uid, member_name as uname FROM member
INTERSECT
SELECT emp_id as uid, emp_name as uname FROM emp;
(이 형태의 쿼리는 MySQL에서는 지원되지 않음)
위의 쿼리에서 SELECT되는 튜플들이 uid와 uname이므로
이 두개의 컬럼을 INNER JOIN의 조건으로 포함시켜서 아래와 같이 작성해주면 된다.
SELECT member_id as uid, member_name as Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-5887112723004940147.post-33247020390801592432011-01-01T05:50:00.000-08:002011-01-01T05:58:24.282-08:00UNION과 UNION ALL 의 차이 및 주의 사항ANSI SQL에서 제안하는 집합 연산 "UNION", "INTERSECT", "MINUS" 중에서MySQL에서는 UNION 집합 연산만 제공하고 있다. (하지만 MySQL에서 INTERSECT나 MINUS를 다른 형태의 쿼리로 풀어서 사용할 수 있다.)
이 글에서는 UNION 에 대해서 좀 더 자세히 알아 보고자 한다.
UNION 집합 연산은 다시 아래와 같이 두가지 종류로 나누어진다. - UNION ALL - UNION DISTINCT
우리가 일반적으로 사용하는 방식인 아무런 추가 키워드 없이 UNION 만 사용하는 것은UNION DISTINCT 를 줄여서 사용하고 있는 것이다.
UNION ALL과 UNION DISTINCT를 레코드가 많은 결과에 대해서 적용해본 사람은 아마도Unknownnoreply@blogger.com5tag:blogger.com,1999:blog-5887112723004940147.post-76878552830532566152010-12-31T23:07:00.000-08:002010-12-31T23:12:12.997-08:00MySQL 서버의 주요 버그
MySQL 서버에서 발생되는 버그는 모두 http://bugs.mysql.com 을 통해서 보고되며,
버그인지 아니면 사용자 실수인지 그리고 버그인 경우, 패치 진행 현황까지 모두 관리되고 있다.
하지만, 한번이라도 그 내용을 찾아본 사용자는 그 어려움을 절감 하고 있을 것이다.
MySQL 의 보고되었고, 현재 해결되지 않은 버그가 300개 가량이다. 어떤 버그가 있는지 어느 버전에 해결되었는지 알아낸다는 것은 적지 않은 시간을 요하는 작업임에는 틀림이 없다.
하지만, 주요 버그들에 대해서는 알아 두는 것이 MySQL의 버전을 선택할 때 또는 개발을 할 때 많은 도움이 될 것이라 생각한다.
l JOIN UPDATE와 ALTER TABLE 의 충돌로 인한 MySQL server Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5887112723004940147.post-60221529294395622262010-12-30T18:34:00.000-08:002011-01-03T07:27:52.038-08:00CHAR vs VARCHAR ?
CHAR를 사용할지 VARCHAR를 사용할 지의 문제는
문자열
데이터의 타입을 선정할 때,
항상 고민하는 부분이 아닐까
생각된다.
CHAR와 VARCHAR의 장단점을 확인해보고, 그 장단점에 맞게 선택하는 것이 최적일 것이라 생각한다.
1.
CHAR
1.1
특징
1.1.1
Disk에 저장 시, 고정 길이로 저장된다.
1.1.2
고정 길이이기 때문에, 별도의 유효(실질) 데이터 길이를 관리하지 않는다.
1.2
장점
1.2.1
고정 길이이기 때문에, 이 컬럼의 변경으로 인해서 Record의 위치 이동(Row migration)이 필요한 Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-5887112723004940147.post-31977061544668665542010-12-30T01:15:00.000-08:002011-03-07T03:00:53.615-08:00Tritonn을 이용한 MySQL 서버의 전문 검색 엔진 구현MySQL의 전문 검색 엔진 (Fulltext search
engine)은 테이블의 레코드
건수나
Fulltext 인덱스 건수에
따라서 성능 저하 현상이 심한 편이다.
또한, 전문 인덱스의 인덱싱 방식이 Stopword 기반이기 때문에 LIKE와 비슷한 패턴의 검색(Partial search)이 불가능하며, 검색의 목적에 맞게 전문 인덱스를 여러 개 만들어야 할 경우도 있다.
MySQL
5.1에서 Fulltext engine Parser를 플러그 인으로 만들어서 끼워 넣을 수 있지만, 현재로써는 적당한 오픈 소스 Parser가 없으며, 직접 만든다는 것은 더더욱 어려운 것이 사실이다.
이러한 이유들로 인해서, 일본에서 MySQL 전문 검색의 단점을 보완하고, 아시아권 언어를 위한 Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5887112723004940147.post-74504726075322641822010-12-29T22:19:00.000-08:002011-01-03T07:28:58.107-08:00문자열 (CHAR, VARCHAR) 타입의 비교 및 정렬 방식
DBMS
종류별로 CHAR 타입의 데이터를 읽어 오고 비교하는 방식에서 조금씩의
차이가 있다.
가끔
오라클과 같은 타
DBMS에 익숙한 사용자는
자주 이런 부분을 혼동하는 경우가 많다.
우선 CHAR 타입이 고정 길이로 관리된다는 것은 타 DBMS와 동일하다.
하지만, CHAR 타입의 필드를JDBC나 PHP 또는 C api를 이용하는 Application에서 읽어 왔을 때, 오라클과는 달리 지정된 길이만큼 공백으로 채워져 있지 않다는 것이다.
즉, CHAR(10)이라는 컬럼에 "ABC"라는 값을 저장해 두었다고 가정했을 때, Application에서 그 필드를 Fetch해 보면, 오라클은 "ABC "와 같이 필드 값을 Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5887112723004940147.post-19314126326674145232010-12-29T03:29:00.000-08:002010-12-29T03:29:30.804-08:00Stored function의 NOT DETERMINISTIC 옵션은 무엇이고 쿼리에 어떤 영향을 미칠까?
Procedure나 Function의 생성시에 사용되는 키워드 중에서 DETERMINISTIC 또는 NOT DETERMINISTIC이라는 키워드를 본 적이 있을 것이다.
여기서 DETERMINISTIC이 의미하는 것이 무엇일까 ?. 그리고 이 옵션으로 인해서 어떤 차이가 생기는 것일까 ?.
이 글에서는 DETERMINITIC하고 그러지 않은 함수의 차이를 알아보고자 한다.
우선, 아래와 같은 예제 함수를 하나 만들었다고 가정해보자.
CREATE FUNCTION
getKeyValue() RETURNS BIGINT
NOT DETERMINISTIC
BEGIN
return 99999999;
END;;
이 함수는 NOT Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5887112723004940147.post-11696918272553175822010-12-29T03:05:00.000-08:002010-12-29T03:10:08.318-08:00MySQL에서 해시(Hash) 인덱스 구현
MySQL에는 기본적으로 해시 인덱스가 제공되지 않는다.
물론, InnoDB의 Adaptive Hash 인덱스라는 기능이 있지만, 이 기능은 사용자가 조작 가능한 형태가 아니라 InnoDB 엔진에서 자주 접근되는 인덱스 데이터들에 대해서 자동적으로 Hash 인덱스를 생성하는 기능이므로 사용자 테이블에 명시적으로 Hash 인덱스를 적용할 수 는 없다.
Hash 인덱스의 장점은 인덱싱할 필드 값들을 Hash 함수를 통해서 계산된 Hash 값으로 인덱스를 만들기 때문에 검색 대상이 되는 필드 값의 길이에 관계 없이 빠른 검색 기능을 제공할 수 있다.
물론, 단점도 있는데 Hash 인덱스는 이미 한번 가공된 값으로 인데싱을 구현하기 때문에 정확히 일치하는 값만 검색이 Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5887112723004940147.post-63665610790042154732010-12-29T01:13:00.000-08:002011-01-28T03:38:31.831-08:00GIS 위치 기반 비교를 위한 유틸리티 함수
MySQL의 GIS Extension을 사용하거나,
아니면, 기본 숫자형의 타입을 이용하여 위치 정보를 관리하는 경우,
특정 GPS 좌표로부터 반경 몇Km 이내의 좌료 정보를 검색하는 경우가 많이 발생한다.
그러한 조작들을 위해서 몇 가지 유용한 MySQL Stored function을 만들어 보았다.
(각 함수의 DETERMINISTIC 옵션은 절대 빼면 안됨)
-- // ------------------------------------------------------------------------------
-- // 두 GPS 좌표간의 실제 거리를 Km 단위로 리턴해주는 함수 ------------------------
DELIMITER ;;
CREATE
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5887112723004940147.post-586985640957625212010-12-28T06:42:00.000-08:002010-12-28T23:25:03.695-08:00EXPLAIN EXTENDED 로 쿼리 최적화 결과 확인MySQL에서 쿼리의 실행 계획을 확인하는 방법은 EXPLAIN 명령을 이용해서 확인할 수 있다.하지만 쿼리 실행계획에 나오는 결과만으로는 부족할 때가 가끔 있는데,대표적인 경우가 MySQL 옵티마이져가 최종적으로 변환한 쿼리의 형태가 어떤 형태인지 확인하고자 할 경우가 대표적이다.
이런 경우에 EXPLAIN EXTENDED 명령을 이용해서 MySQL Optimizer에 의해서 최종적으로 어떻게 쿼리가 변환되었는지를 알 수 있다.아래 테스트 결과는 MySQL 5.1 버전대에서 보여진 결과이며, MySQL 4.1 또는 MySQL 5.0에서 확인하는 방법은 조금 다른데, 이 경우 확인 방법은 최 하단에 추가하겠다.
우선, 간단한 단일 테이블 쿼리와 조인 쿼리 몇개를 실행해서 변환된 쿼리의 내용을 확인해보자.(Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5887112723004940147.post-63072113706383114042010-12-28T01:10:00.000-08:002011-01-03T07:29:36.720-08:00트리거(Trigger)와 이벤트(Event)의 생성 및 실행 권한
이번에는 Trigger와 Event의 권한 설정에 대해서 알아보도록 하겠다.
MySQL
5.0 버전에서는 Trigger를 위한 권한이 조금 부족한 상황이다.
그래서 MySQL 5.0에서는 일반 사용자가 Trigger를 생성 및 호출하기 위해서는 ROOT 유저 (그 외, SUPER 권한을 가진 사용자)의 도움이 필요하다.
--
// 트리거 (Trigger) 생성 문장
CREATE
DEFINER = { user | CURRENT_USER }
TRIGGER backup_record AFTER UPDATE
ON member FOR EACH ROW
BEGIN
..Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5887112723004940147.post-59117819863767597052010-12-28T00:00:00.000-08:002011-01-03T07:29:58.204-08:00Stored procedure 와 Stored function 그리고 View 의 권한 처리
MySQL에서 Procedure나 Function 및 Trigger를 정의하고 호출하는 권한 방식은 조금 익숙하지 않은 방식으로 처리된다.
여기에서는 Procedure 와 Function의 권한 처리에 대해서 알아보고, Trigger는 다음 기회에 더 알아보도록 하겠다.
(Trigger의 권한 방식은 Procedure나 Function과는 조금 다르기 때문에...)
View의 생성 및 사용 권한은 Procedure나 Function과 거의 비슷하기 때문에 여기서 같이 언급하고자 한다.
(여기 내용은 주로 Routine에 기준해서 작성되었기 때문에 호출 방식이나 사용법은 View에 적용되지 않을 수 있다.)
--
// 프로시져 (Stored procedure) 생성 문장
CREATE
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5887112723004940147.post-39088562984007243482010-12-27T21:35:00.000-08:002010-12-28T23:31:27.917-08:00MySQL Builtin Full Text Search Engine과 Tritonn의 기능 비교
MySQL Builtin Full Text
Search Engine과 Tritonn의 기능 비교
MySQL Builtin
Tritonn
MySQL
Version dependency
All Enterprise, Community Version
Specific Community version
UTF-8
Support
Yes
Yes
Support
Table Engine Type
MyISAM
MyISAM
Indexing
Method
Stop Word
Stop Word and Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5887112723004940147.post-24841382316060763062010-12-27T21:28:00.000-08:002010-12-28T23:31:54.288-08:00전문 검색 엔진(Full text search engine)의 검색 방식 및 인덱싱
검색 방식
자연어 검색자연어 검색이란, 문자 그대로 검색어를 일반적으로 인간이 사용하는 문장이나 절로(자연스러운 문장의 구문) 가정하여 그대로 Matching해서 검색을 실행하는 방법을 의미한다. 별도의 연산자를 사용할 수 없으며, StopWord 가 적용되며, 50% 이상의 레코드에 존재하는 단어는 일반적인 단어로 간주하여 검색에서 배제한다. 또한, 검색 결과 Match율은 Percentage로 표시된다. MySQL에서는 별도의 옵션을 제공하지 않으면, 자연어 검색을 실행하게 된다.(MySQL Built-in 전문 검색엔진을 포함한 대부분의 전문 검색 도구가 지원한다.)
Boolean 검색자연어와 달리 검색어의 단어 단위로 특별한 예약어 (+-* 등)를 사용하여 검색 Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-5887112723004940147.post-28181987917544449312010-12-27T03:01:00.000-08:002011-03-10T01:26:14.424-08:00Stored routine (Procedure, Function, Trigger)에서의 예외 처리 방법Stored routine (Procedure, Function, Trigger)는 다른 절차적인 프로그램 언어와 같이
여러가지 에러 상황에 대한 Exception handling이 필수적이다.
여기에서는 MySQL Stored routine에서의 예외 처리를 한번 알아보고자 한다.
우선 MySQL의 예외처리는 DECLARE ... HANDLER 구문을 이용하여
각 예외 케이스의 이벤트가 발생하면 그 Handler가 작동하는 형태로 구현이 가능하다.
HANDLER 정의 구문
DECLARE handler_type HANDLER
FOR condition_value [, condition_value] ...
Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-5887112723004940147.post-41825065368692933882010-12-27T00:06:00.000-08:002010-12-28T23:32:45.024-08:00MySQL ErrorNo와 SqlState 는 무엇을 의미할까?
PHP나 JDBC로 MySQL 데이터베이스를 이용하는 프로그램을 작성하다 보면 ErrorNo와 SqlState라는 말이나 값들을 자주 접하게 된다.
그러면, "왜 MySQL은 에러나 상태 코드를 이렇게 ErrorNo와 SqlState라는 것으로 따로 분리해서 사용할까"라는 의문이 들 것이다.
이 글에서는 ErrorNo와 SqlState의 차이점과 대표적인 ErrorNo와 SqlState값을 확인 해보자.
mysql> SELECT * FROM not_found_table;
ERROR 1146 (42S02): Table 'test.not_found_table' doesn't exist
위의 예제에서와 같이 mysql client를 이용해서 쿼리를 실행하면, 에러나 경고 발생시에 콘솔에Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5887112723004940147.post-52891670783868326012010-12-26T22:13:00.000-08:002010-12-28T23:33:18.521-08:00InnoDB 테이블 손상(깨어진)시 강제 복구
MyISAM과 달리 InnoDB 테이블들은 매우 안정적이며, 왠만해서는 데이터 파일이 깨어지는 경우는 거의 경험하지 못했다.
하지만, 데이터 파일이 깨어진다면 어떻게 해야 할까 ?. DBMS 벤더를 불문하고 손상된(깨어진) 데이터 파일을 복구한다는 것은 쉽지 않은 문제이며 위험도 크다.
이런
비 정상적인 현상은 어느
DBMS에서나 발생할 수 있는
현상이며, 이를 위해서 우리는 데이터베이스를 그렇게 열심히 백업하고
있었던 것이다.
만약, 백업마저도 복구가 안 된다면, 결국 지금의 깨어진 데이터 파일이라도 어떻게든 복구를 해야 한다.
하지만, InnoDB는 myisamchk와 같은 별도의 복구 도구를 제공하지 않는다.
손상된 InnoDB 테이블의 복구는 우선 MySQL을 기동시켜서 데이터를 덤프Unknownnoreply@blogger.com0