열 추가를 통해 생성 된 테이블과 마찬가지로 생성 된 테이블 사이에 성능 차이가 있습니까?

Question

빠른 질문, 한 번에 정의 된 데이터베이스 테이블과 시간이 지남에 따라 열이 추가 된 데이터베이스 테이블 사이에 차이가 있는지 궁금했습니다. 칼럼 성능이 추가 된 사람은 어전에서 어려움을 겪습니까?

어쨌든 데이터베이스 공급 업체는이 경우 공급 업체 차이가 없다면 여기서는 그리 관련이 없습니다.

감사

Answer 1

거기 ~이다 공급 업체 차이점. SQL 언어는 표준에 의해 정의되지만 스토리지 세부 사항은 각 공급 업체에게 맡겨져 구현할 수 있습니다.

예를 들어, MySQL에서 열을 추가 할 때 데이터베이스 엔진은 전체 테이블을 복사하여 각 행의 새 열을위한 공간을 만듭니다. 모든 행을 복사하면 테이블의 기존 사본이 떨어집니다. 따라서 새 테이블은 마치 새 테이블을 처음부터 새 열로 정의한 것처럼 저장됩니다. 하지만 사본이 끝날 때까지 기다려야합니다. ALTER TABLE 반환합니다 (테이블이 크면 오랜 시간이 걸릴 수 있습니다).

다른 브랜드의 데이터베이스에서 (마음이 없어도) 열을 추가하면 원래 테이블과 별도로 추가 열을 저장할 수 있습니다. 이렇게하면 새 열을 빠르게 추가하는 데 도움이되지만 데이터를 검색하면 연결이 끊어진 데이터 섹션의 영향을받습니다. 아마도 당신은 나중에 데이터베이스 엔진에 테이블을 "분해"하고 모든 열을 함께 가져 오도록 지시 할 수 있습니다.

Answer 2

Oracle에서는 기존 인구가있는 테이블에 빈 열을 추가 할 수 있으며 본질적으로 테이블 구조의 논리적 재정의 이외의 결과로 아무 일도 일어나지 않습니다. 그래도 열을 채우면 열이 추가 될 때 열광 할 수있는 열을 채우면 행이 확장되어야하며 포함 된 블록에 충분한 여유 공간이없는 일부 행에 문제가 발생할 수 있습니다. 그것들은 원래 위치에 포인터가 남은 상태에서 다른 블록으로 마이그레이션됩니다 (따라서 원래 위치를 계속 가리키기 때문에 인덱스는 영향을받지 않습니다).

이로 인해 행이있는 테이블에 인구가 많은 열을 추가하는 경우 원래 테이블의 이름을 바꾸고 새 버전을 작성하고 채우는 "Select As Select"를 수행 할 수 있습니다. 물론 인덱스, 트리거, 권한 등도 마이그레이션해야합니다. 그러나 테이블이 너무 크지 않으면 추적 된 열을 추가하여 행 마이그레이션으로 인해 성능이 적중 한 다음 테이블 이동을 수행하여 재구성 할 수 있습니다.

Answer 3

그것은 완전히 스토리지 엔진 의존적 일 것입니다. 일반적으로 나는 최적화 테이블을 던진 후 추가 된 열에 완벽하게 편안하다고 느낄 수 있습니다.