테이블의 열 순서에 대해 걱정할 이유가 있습니까?

테이블의 열 순서에 대해 걱정할 이유가 있습니까?

---

FIRST 및 AFTER를 사용하여 MySQL에서 열 순서를 변경할 수 있다는 것을 알고 있지만 왜 귀찮게하고 싶습니까? 좋은 쿼리는 데이터를 삽입 할 때 명시 적으로 열의 이름을 지정하기 때문에 테이블에서 열이 어떤 순서로되어 있는지 신경 쓸 이유가 있습니까?

---

열 순서는 Sql Server, Oracle 및 MySQL에 걸쳐 내가 조정 한 일부 데이터베이스에 큰 성능 영향을 미쳤습니다. 이 게시물에는 좋은 경험 규칙이 있습니다 .

• 먼저 기본 키 열
• 다음은 외래 키 열입니다.
• 다음 자주 검색되는 열
• 나중에 자주 업데이트되는 열
• Nullable 열은 마지막에 있습니다.
• 더 자주 사용되는 nullable 열 이후 가장 적게 사용 된 nullable 열

성능 차이의 예는 인덱스 조회입니다. 데이터베이스 엔진은 인덱스의 일부 조건에 따라 행을 찾고 행 주소를 다시 가져옵니다. 이제 SomeValue를 찾고 있다고 가정하면 다음 표에 있습니다.

 SomeId int,
 SomeString varchar(100),
 SomeValue int

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

 SomeId int,
 SomeValue int,
 SomeString varchar(100)

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

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

---

최신 정보:

에서는 MySQL,이 작업을 수행 할 이유가있을 수 있습니다.

변수 데이터 유형 (예 :) VARCHAR은에 가변 길이로 저장 InnoDB되므로 데이터베이스 엔진은 각 행의 이전 열을 모두 탐색하여 주어진 항목의 오프셋을 찾아야합니다.

컬럼에 대한 영향은 17 % 까지 20클 수 있습니다.

자세한 내용은 내 블로그에서이 항목을 참조하십시오.

• 열 순서 선택

에서 Oracle, 후행 NULL열이 더 공간을 사용하지 당신은 항상 테이블의 끝에 넣어해야하는 이유, 그건.

또한에서 Oracle및에서 SQL Server큰 행의 경우 a ROW CHAINING가 발생할 수 있습니다.

ROW CHANING 하나의 블록에 맞지 않는 행을 분할하고 연결된 목록으로 연결된 여러 블록에 걸쳐 있습니다.

첫 번째 블록에 맞지 않는 후행 열을 읽으려면 연결 목록을 탐색해야하므로 추가 I/O작업 이 발생 합니다.

참조 이 페이지 의 그림 ROW CHAINING에서을 Oracle:

그렇기 때문에 자주 사용하는 열을 테이블의 시작 부분에 배치하고 자주 사용하지 않는 열 또는 인 경향이있는 열을 NULL테이블 끝에 배치해야합니다.

중요 사항:

이 답변이 마음에 들고 투표하고 싶다면 @Andomar의 답변에 투표하십시오 .

그는 똑같은 대답을했지만 아무런 이유없이 반대표를받은 것 같습니다.

---

이전 작업에서 Oracle 교육을 수행하는 동안 DBA는 nullable이 아닌 모든 열을 nullable 열 앞에 두는 것이 유리하다고 제안했습니다. TBH는 그 이유에 대한 자세한 내용을 기억하지 못합니다. 아니면 업데이트 될 가능성이있는 것만이 마지막에 가야할까요? (행이 확장되면 이동하지 않아도 될 수 있음)

일반적으로 아무런 차이가 없어야합니다. 말했듯이 쿼리는 "select *"의 순서에 의존하지 않고 항상 열 자체를 지정해야합니다. 나는 그것들을 변경할 수있는 DB를 모른다 ... 글쎄, 나는 당신이 그것을 언급 할 때까지 MySQL이 그것을 허용한다는 것을 몰랐다.

---

잘못 작성된 일부 응용 프로그램은 열 이름 대신 열 순서 / 인덱스에 종속 될 수 있습니다. 그렇게해서는 안되지만 발생합니다. 열 순서를 변경하면 이러한 응용 프로그램이 중단됩니다.

---

아니요, SQL 데이터베이스 테이블의 열 순서는 표시 / 인쇄 목적을 제외하고는 전혀 관련이 없습니다. 열 순서를 변경할 필요가 없습니다. 대부분의 시스템은이를 수행하는 방법도 제공하지 않습니다 (이전 테이블을 삭제하고 새 열 순서로 다시 만드는 경우 제외).

마크

편집 : 관계형 데이터베이스의 Wikipedia 항목에서 열 순서가 결코 문제 가 되지 않아야 함을 분명히 보여주는 관련 부분이 있습니다.

관계는 n- 튜플의 집합으로 정의됩니다. 수학 및 관계형 데이터베이스 모델 모두에서 집합은 항목 의 정렬되지 않은 컬렉션이지만 일부 DBMS는 데이터에 순서를 부과합니다. 수학에서 튜플은 순서를 가지며 복제를 허용합니다. EF Codd는 원래이 수학적 정의를 사용하여 튜플을 정의했습니다. 나중에 순서 대신 속성 이름을 사용하는 것이 관계 기반 컴퓨터 언어에서 (일반적으로) 훨씬 더 편리 할 것이라는 EF Codd의 훌륭한 통찰력 중 하나였습니다. 이 통찰력은 오늘날에도 여전히 사용되고 있습니다.

---

입력해야 할 때 출력의 가독성 :

select * from <table>

데이터베이스 관리 소프트웨어에서?

아주 가짜 이유지만 지금은 아무것도 생각할 수 없습니다.

---

The only reason I can think about is for debugging and fire-fighting. We have a table whose "name" column's appears about 10th on the list. It's a pain when you do a quick select * from table where id in (1,2,3) and then you have to scroll across to look at the names.

But that's about it.

---

As is often the case, the biggest factor is the next guy who has to work on the system. I try to have the primary key columns first, the foreign key columns second, and then the rest of the columns in descending order of importance / significance to the system.

---

If you're going to be using UNION a lot, it makes matching columns easier if you have a convention about their ordering.

---

Beyond the obvious performance tuning, I just ran into a corner case where reordering columns caused a (previously functional) sql script to fail.

From the documentation "TIMESTAMP and DATETIME columns have no automatic properties unless they are specified explicitly, with this exception: By default, the first TIMESTAMP column has both DEFAULT CURRENT_TIMESTAMP and ON UPDATE CURRENT_TIMESTAMP if neither is specified explicitly" https://dev.mysql.com/doc/refman/5.6/en/timestamp-initialization.html

So, a command ALTER TABLE table_name MODIFY field_name timestamp(6) NOT NULL; will work if that field is the first timestamp (or datetime) in a table, but not otherwise.

Obviously, you can correct that alter command to include a default value, but the fact that a query that worked stopped working due to a column reordering made my head hurt.

---

The only time you'll need to worry about column order is if your software specifically relies on that order. Typically this is due to the fact that the developer got lazy and did a select * and then referred to the columns by index rather than by name in their result.

---

In general what happens in SQL Server when you change column order through Management Studio, is that it creates a temp table with the new structure, moves the data to that structure from the old table, drops the old table and renames the new one. As you might imagine, this is a very poor choice for performance if you have a large table. I don't know if My SQL does the same, but it is one reason why many of us avoid reordering columns. Since select * should never be used in a production system, adding columns at the end is not aproblem for a well-designed system. Order of columns inthe table should in genral not be messed with.

---

As noted, there are numerous potential performance issues. I once worked on a database where putting very large columns at the end improved performance if you didn't reference those columns in your query. Apparently if a record spanned multiple disk blocks, the database engine could stop reading blocks once it got all the columns it needed.

Of course any performance implications are highly dependent not just on the manufacturer that you're using, but also potentially on the version. A few months ago I noticed that our Postgres could not use an index for a "like" comparison. That is, if you wrote "somecolumn like 'M%'", it wasn't smart enough to skip to the M's and quit when it found the first N. I was planning to change a bunch of queries to use "between". Then we got a new version of Postgres and it handled the like's intelligently. Glad I never got around to changing the queries. Obviously not directly relevant here but my point is that anything you do for efficiency considerations could be obsolete with the next version.

Column order is almost always very relevant to me because I routinely write generic code that reads the database schema to create screens. Like, my "edit a record" screens are almost always built by reading the schema to get the list of fields, and then displaying them in order. If I changed the order of columns, my program would still work, but the display might be strange to the user. Like, you expect to see name / address / city / state / zip, not city / address / zip / name / state. Sure, I could put the display order of the columns in code or a control file or something, but then every time we added or removed a column we'd have to remember to go update the control file. I like to say things once. Also, when the edit screen is built purely from the schema, adding a new table can mean writing zero lines of code to create an edit screen for it, which is way cool. (Well, okay, in practice usually I have to add an entry to the menu to call the generic edit program, and I've generally given up on generic "select a record to update" because there are too many exceptions to make it practical.)

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