표의 열 순서를 걱정할 이유가 있나요?

표의 열 순서를 걱정할 이유가 있나요?

FIRST와 AFT로 MySQL의 컬럼 순서를 변경할 수 있는 것은 알고 있습니다만, 왜 번거롭게 하고 싶습니까?데이터를 삽입할 때 올바른 쿼리는 열 이름을 명시적으로 지정하므로 테이블에서 열이 어떤 순서로 정렬되어 있는지 신경쓸 필요가 있습니까?

컬럼 순서는 SQL Server, Oracle 및 MySQL에 걸쳐 튜닝한 일부 데이터베이스의 성능에 큰 영향을 미쳤습니다.이 게시물에는 좋은 경험칙이 있습니다.

• 기본 키 열 먼저
• 다음으로 외부 키 열입니다.
• 다음에 자주 검색되는 열
• 나중에 자주 업데이트되는 열
• nullable 열은 마지막에 표시됩니다.
• 더 자주 사용되는 nullable 열 다음에 가장 적게 사용된 nullable 열

성능 차이의 예로는 인덱스 룩업이 있습니다.데이터베이스 엔진은 인덱스의 몇 가지 조건에 따라 행을 찾아 행 주소를 반환합니다.Some Value를 찾고 있다고 가정해 보겠습니다.다음 표에 기재되어 있습니다.

 SomeId int,
 SomeString varchar(100),
 SomeValue int

SomeString의 길이를 알 수 없기 때문에 엔진은 SomeValue의 시작 위치를 추측해야 합니다.단, 순서를 다음과 같이 변경하는 경우:

 SomeId int,
 SomeValue int,
 SomeString varchar(100)

이제 엔진은 행 시작 후 4바이트 후에 SomeValue를 찾을 수 있음을 인식합니다.따라서 열 순서는 성능에 상당한 영향을 미칠 수 있습니다.

편집: SQL Server 2005는 행 시작 부분에 고정 길이 필드를 저장합니다.각 행에는 varchar의 시작을 나타내는 참조가 있습니다.이것은 내가 위에 열거한 효과를 완전히 부정한다.따라서 최근 데이터베이스의 경우 열 순서가 더 이상 영향을 미치지 않습니다.

업데이트:

»MySQL이렇게 하는 데는 이유가 있을 수 있습니다.

: " " " " " 등):VARCHAR됩니다.InnoDB데이터베이스 엔진은 각 행의 모든 이전 열을 통과하여 지정된 열의 오프셋을 확인해야 합니다.

그 영향은 최대 17%에 달할 수 있습니다.20컬럼을 클릭합니다.

상세한 것에 대하여는, 제 블로그의 다음의 엔트리를 참조해 주세요.

• 열 순서 선택

»Oracle, trailing(슬롯)NULL열은 공간을 차지하지 않으므로 항상 표의 끝에 배치해야 합니다.

도도에도 .Oracle 및에SQL Server큰 「」를 사용합니다.ROW CHAINING발생할 수 있습니다.

ROW CHANING해, 블록에 하는 것입니다.

해야 합니다. 됩니다.I/O★★★★★★ 。

의 설명에 대해서는, 이 페이지를 참조해 주세요.ROW CHAINING…에Oracle:

하지 않는 , 사용하지 않는 .NULL

중요사항:

이 답변이 마음에 들어 투표하고 싶은 경우는, 의 답변에도 투표해 주세요.

그는 같은 대답을 했지만, 아무 이유 없이 낙선한 것 같다.

이전 작업에서 Oracle 교육을 받을 때 DBA는 Null이 아닌 모든 열을 Null이 아닌 열보다 먼저 배치하는 것이 유리하다고 제안했습니다.TBH 자세한 이유는 기억나지 않습니다.아니면 업데이트될 것 같은 것만 마지막에 표시해야 할까요? (열은 확장되면 이동하지 않아도 됩니다.)

일반적으로, 그것은 아무런 차이가 없을 것입니다.말씀하신 바와 같이 쿼리는 항상 "select *"의 순서에 의존하지 않고 열 자체를 지정해야 합니다.변경할 수 있는 DB가 있는지...네가 말하기 전까지 MySQL이 허락한 줄 몰랐어

다음과 같이 입력해야 할 경우 출력의 가독성

select * from <table>

사용 중인 데이터베이스 관리 소프트웨어에 저장하시겠습니까?

매우 의아한 이유지만, 현재로서는 다른 것이 생각나지 않는다.

잘못 작성된 일부 응용프로그램은 열 이름 대신 열 순서/색인에 종속될 수 있습니다.그래선 안 되지만, 실제로 일어났어요.열의 순서를 변경하면 이러한 응용 프로그램이 중단됩니다.

아니요, SQL 데이터베이스 테이블의 열 순서는 표시/인쇄 목적 이외에는 전혀 관계가 없습니다.열을 재배치하는 것은 의미가 없습니다.대부분의 시스템에서는 이 방법을 제공하지 않습니다(오래된 테이블을 삭제하고 새 열 순서로 다시 작성하는 것 제외).

마크

편집: Wikipedia의 관계형 데이터베이스 엔트리에서 컬럼 순서는 전혀 문제가 되지 않는다는 것을 명확하게 알 수 있는 부분은 다음과 같습니다.

관계는 n개의 튜플 세트로 정의됩니다.수학 및 관계형 데이터베이스 모델에서 집합은 정렬되지 않은 항목 집합이지만 일부 DBMS는 데이터에 순서를 부여합니다.수학에서, 튜플은 순서가 있고 복사를 허용한다.E.F. Codd는 원래 이 수학적 정의를 사용하여 튜플을 정의했습니다.나중에, 그것은 E.F. 중 하나였다.Codd의 뛰어난 통찰력에서는, 순서 대신에 속성명을 사용하는 것이, 관계에 근거하는 컴퓨터 언어에서는 훨씬 편리합니다(일반적으로).이 통찰력은 오늘날에도 여전히 사용되고 있다.

명백한 퍼포먼스 튜닝 이외에도 컬럼 순서를 변경함으로써 (이전에는 기능했던) SQL 스크립트가 실패하는 코너 케이스에 부딪혔습니다.

문서 "TIMESTamp 및 DATETIME 열에는 명시적으로 지정되지 않는 한 자동 속성이 없습니다. 단, 이 예외는 다음과 같습니다.디폴트로는 첫 번째 TIMESTAMP 컬럼에는 DEFAULT CURRENT_TIMESTamp 와 ON UPDATE CURRENT_TIMESTamp 이 모두 명시적으로 지정되어 있지 않은 경우 모두 표시됩니다.https://dev.mysql.com/doc/refman/5.6/en/timestamp-initialization.html

'''는ALTER TABLE table_name MODIFY field_name timestamp(6) NOT NULL;이 필드가 테이블의 첫 번째 타임스탬프(또는 datetime)일 경우에는 동작하지만 그 이외의 경우에는 동작하지 않습니다.

이 alter 명령어를 디폴트값으로 수정할 수 있는 것은 분명합니다만, 컬럼 순서 변경으로 인해 동작하던 쿼리가 동작을 정지한 것이 머리를 아프게 했습니다.

흔히 있는 일이지만, 가장 큰 요인은 다음 번 시스템 작업을 해야 하는 사람입니다.프라이머리 키열, 외부 키열, 그리고 나머지 컬럼을 시스템에 대한 중요도/중요도 내림차순으로 설정하려고 합니다.

제가 생각할 수 있는 유일한 이유는 디버깅과 소방입니다."이름" 열이 리스트에서 10위 정도 되는 테이블이 있습니다.테이블에서 id(1, 2, 3)를 빠르게 선택한 후 스크롤하여 이름을 확인해야 하는 번거로움이 있습니다.

하지만 그게 다예요.

2002년, Bill Thorsteinson은 Hewlett Packard 포럼에 칼럼을 재정렬하여 MySQL 쿼리를 최적화하기 위한 제안을 게시했습니다.그의 게시물은 말 그대로 인터넷에 적어도 100번 이상 복사되어 붙여졌고 종종 인용도 없이 붙여졌다.그를 정확히 인용하자면...

일반적인 경험칙:

• 우선 프라이머리 키열.
• 다음으로 외부 키 열입니다.
• 다음으로 자주 검색되는 열입니다.
• 나중에 자주 업데이트되는 열.
• nullable 열은 마지막에 표시됩니다.
• 자주 사용되는 null 가능 열 다음에 가장 적게 사용되는 null 가능 열입니다.
• 다른 열이 거의 없는 자체 테이블에 블롭합니다.

출처: HP 포럼.

하지만 그 포스트는 2002년에 만들어졌어요!이 조언은 MySQL 5.1이 출시되기 6년 이상 전의 MySQL 버전 3.23을 위한 것이었다.그리고 언급이나 인용문도 없다.그래서, 빌이 옳았나요?그리고 스토리지 엔진은 이 수준에서 정확히 어떻게 작동합니까?

1. 네, 빌이 옳았어요.
2. 이 모든 것은 연쇄 행과 메모리 블록의 문제로 귀결됩니다.

Oracle 인증 전문가인 Martin Zahn을 인용하자면, "Oracle Row Chaining and Migration"에 대한 기사에서 인용하자면...

연결된 행은 우리에게 다른 영향을 미칩니다.여기에서는, 우리가 필요로 하는 데이터에 따라 다릅니다.두 블록에 걸쳐 두 개의 열이 있는 행이 있는 경우 쿼리는 다음과 같습니다.

SELECT column1 FROM table

여기서 column1은 블록1에 있으며 "table fetch continued row"는 발생하지 않습니다.실제로는 column2를 취득할 필요가 없습니다.또한 체인된 행을 끝까지 따라가지 않습니다.한편, 델이 요구하는 것은 다음과 같습니다.

SELECT column2 FROM table

행 체인에 의해 column2가 블록2에 있는 경우 실제로는 "table fetch continued row"가 표시됩니다.

그 기사의 나머지 부분은 꽤 좋은 읽을거리야!하지만 나는 단지 우리의 질문과 직접적으로 관련이 있는 부분을 인용하고 있을 뿐이다.

18년 이상 지난 후, 나는 이 말을 해야겠다: 고마워, 빌!

UNION을 많이 사용하는 경우, 주문에 관한 규약을 가지고 있으면 열을 매칭하기 쉬워집니다.

앞서 설명한 바와 같이 잠재적인 성능 문제가 많이 있습니다.쿼리에서 매우 큰 열을 참조하지 않으면 끝에 매우 큰 열을 배치하면 성능이 향상되는 데이터베이스 작업을 수행한 적이 있습니다.레코드가 여러 디스크 블록에 걸쳐 있는 경우 데이터베이스 엔진은 필요한 열을 모두 얻으면 블록 읽기를 중지할 수 있습니다.

물론 성능에 미치는 영향은 사용 중인 제조업체뿐만 아니라 잠재적으로 버전에 따라 크게 좌우됩니다.몇 달 전에 나는 우리의 Postgres가 "좋아요" 비교에 지수를 사용할 수 없다는 것을 알아차렸다.즉, 'M% 같은 컬럼'이라고 쓰면 M으로 건너뛰고 첫 번째 N을 발견했을 때 그만둘 만큼 똑똑하지 못한 것입니다.나는 "between"을 사용하도록 많은 쿼리를 변경할 계획이었다.그리고 나서 우리는 새로운 버전의 Postgres를 얻었고 그것은 이와 비슷한 것들을 지능적으로 처리했다.질문을 바꿀 시간이 없어서 다행이야여기서 직접적으로 관련이 있는 것은 아닙니다만, 효율성의 고려에 대해 실시하는 것은, 다음의 버전에서는 불필요하게 될 가능성이 있습니다.

화면 작성을 위해 데이터베이스 스키마를 읽는 범용 코드를 일상적으로 작성하기 때문에 열의 순서는 거의 항상 매우 관련이 있습니다.예를 들어, "레코드 편집" 화면은 거의 항상 스키마를 읽고 필드 목록을 가져온 다음 순서대로 표시합니다.열의 순서를 변경해도, 프로그램은 동작합니다만, 유저에게는 표시가 이상할 수 있습니다.예를 들어, 도시 / 주소 / zip / name / state가 아닌 이름 / 주소 / city / state / zip이 표시됩니다.물론 열 표시 순서를 코드나 제어 파일이나 뭐 그런 것에 넣을 수 있지만, 열을 추가하거나 제거할 때마다 제어 파일을 업데이트해야 합니다.나는 한 번 말하는 것을 좋아한다.또, 편집 화면이 스키마로부터만 작성되고 있는 경우, 새로운 테이블을 추가하는 것은, 코드의 0 행을 써 편집 화면을 작성하는 것을 의미할 수 있습니다(실제로, 저는 일반적인 편집 프로그램을 호출하기 위해서 메뉴에 엔트리를 추가해야 합니다.또한 일반적으로 갱신할 레코드 선택을 포기했습니다.너무 많은 예외가 있기 때문에 실용화 할 수 없습니다.)

열 순서를 걱정할 필요가 있는 것은 소프트웨어가 해당 순서를 사용하는 경우뿐입니다.일반적으로 이는 개발자가 게으름을 피우고 작업을 수행했기 때문입니다.select *그런 다음 결과에서 이름이 아닌 인덱스로 열을 참조합니다.

일반적으로 Management Studio에서 열 순서를 변경하면 SQL Server에서 새 구조체의 임시 테이블이 생성되고 이전 테이블에서 해당 구조체로 데이터가 이동되며 이전 테이블이 삭제되고 새 테이블의 이름이 변경됩니다.상상하신 바와 같이 테이블이 클 경우 퍼포먼스에 있어서 매우 좋지 않은 선택입니다.My SQL도 같은 기능을 하는지 모르겠지만, 이것이 많은 사람들이 열의 순서를 변경하는 것을 꺼리는 이유 중 하나입니다.*를 선택하면 운영 시스템에서 절대 사용할 수 없으므로 올바르게 설계된 시스템에서는 마지막에 열을 추가하는 것이 문제가 되지 않습니다.테이블의 열 순서가 일반적으로 잘못되어서는 안 됩니다.

언급URL : https://stackoverflow.com/questions/894522/is-there-any-reason-to-worry-about-the-column-order-in-a-table