sungucklee2062

안녕하세요.&nbsp;페이징에서 <code>user_id</code> 컬럼 뿐만 아니라 <code>id</code> 컬럼을 추가해서 복합 인덱스를 생성하는 것은, 중복된 <code>user_id</code>로 인해서 중간에 레코드가 짤리는 경우를 피하기 위해서 <code>id</code> 컬럼을 마지막에 추가한 것입니다. 아래와 같은 경우를 고려해보시면, 중간에 데이터가 사라지는 현상이 생길 수 있다는 것을 예상하실 수 있을 거에요. (첫번째 페이지의 마지막 <code>user_id='esther'</code> 일때, 다음 페이지는 <code>user_id>'esther'</code> 조건으로 검색해야 하는데, 이때 <code>id = 11</code> 인 레코드는 건너 뛸 위험이 있는거죠.<pre><code>user_id id
-------------
 esther 9
 esther 10
 esther 11
 matt 12
-------------</code></pre>&nbsp;만약 <code>user_id</code> 가 중복이 없다면 (UNIQUE 하다면), 굳이 <code>id</code> 컬럼을 마지막에 추가하지 않고 <code>user_id</code> 컬럼만으로 인덱스를 생성해도 될듯 합니다.&nbsp;감사합니다.

복합 index 문의

안녕하세요.&nbsp;1차적으로는 페이지의 데이터를 컴팩션해서 빈 공간을 만들어보고,그래도 공간이 부족하면 페이지를 스플릿(split)하게 됩니다.&nbsp;감사합니다.

레코드 수정시 저장공간이 부족하면

결과적으로 <code>SELECT COUNT(*)</code> 를 사용하면, MySQL 서버는 내부적으로 <code>SELECT COUNT(1)</code> 과 같은 상수값으로 카운트만 하도록 바꿔줍니다. 즉 성능적인 차이는 없다고 볼 수 있습니다.&nbsp;다만, <code>SELECT COUNT(*)</code> 를 권장드린 이유는 가독성에 있습니다. <code>SELECT COUNT(1)</code> 또는 <code>SELECT SUM(1)</code> 또는 <code>SELECT COUNT(column1)</code> 등과 같이 다양한 표현식이 사용되면 처음 작성자와 이후 코드를 읽는 사람의 코드 가독성에 혼란이 생길 수 있어서,, <code>COUNT()</code> 함수내에 사용되는 값을 그냥 <code>*</code> 로만 통일해서 사용하는 것을 말씀드렸던 것입니다. 관련해서 자칫 실수해서 성능상 문제가될 수도 있는 케이스도 이미 동영상 강의에서 언급드리고 있으니, 같이 참고해주시면 좋을 듯 해요.&nbsp;감사합니다.

ep.12 count(*) 질문

안녕하세요. Real MySQL 강의에 관심가져 주셔서 감사합니다. 안타깝게도, 아직 해당 이슈가 해결되지 않아서 여전히 공개가 어려운 상황입니다. 이 부분은 제가 결정할 수 있는 부분이 아니었기에, 예전 답변 글에서 안내드렸던 내용에서 언제까지 오픈해드리겠다는 안내를 드리진 않았던 것입니다. 최대한 도움을 드리지 못한 부분 다시 한번 죄송스러운 마음입니다. 감사합니다.

강의

김상형님 안녕하세요.&nbsp;만약 쿼리가 <code>ix_userid_id</code> 인덱스를 사용한다면, 말씀하신 것처럼 id 컬럼으로 정렬된 결과를 반환할 것이라고 예상할 수 있습니다. 즉 이 경우에는 <code>ORDER BY id</code> 를 명시하지 않아도 정렬 효과를 얻을 수 있는거죠.그런데, 이 쿼리가 <code>ix_userid_id</code> 인덱스를 사용하지 못하는 경우에는, (쿼리에 <code>ORDER BY id</code> 가 명시되지 않았다면) 결과가 id 컬럼 값으로 정렬되지 않을 수도 있어요. 그런데 특정 힌트를 지정하지 않는 이상 실행 계획은 항상 유동적이라고 가정해야 합니다. 그래서 정렬된 결과가 필요하다면, ORDER BY 절을 명시하는 것이 권장됩니다.

ORDER BY가 필요한 이유

안녕하세요.&nbsp;아래 예제에서와 같이, MySQL 서버의 <code>avg_row_legnth</code> 는 <code>data_length / rows</code> 값의 결과일뿐입니다. 그리고 <code>data_length</code> 값은 테이블의 <code>데이터가 저장된 페이지의 개수 * 페이지크기(16KB)</code> 입니다.마지막으로 <code>데이터가 저장된 페이지의 개수</code> 에는 Off-page 또는 Inline으로 저장된 TEXT/BLOB 컬럼들도 모두 포함됩니다.<pre><code class="language-sql">CREATE TABLE table_stats (id int primary key, fd text);
INSERT INTO table_stats VALUES (1, REPEAT('한글',10000));
SELECT id, length(fd) FROM table_stats;
+----+------------+
| id | length(fd) |
+----+------------+
| 1 | 60000 |
+----+------------+

ANALYZE TABLE table_stats;
+------------------+---------+----------+----------+
| Table | Op | Msg_type | Msg_text |
+------------------+---------+----------+----------+
| matt.table_stats | analyze | status | OK |
+------------------+---------+----------+----------+

SHOW TABLE STATUS LIKE 'table_stats' \G
*************************** 1. row ***************************
 Name: table_stats
 Engine: InnoDB
 Version: 10
 Row_format: Dynamic
 Rows: 1
 Avg_row_length: 81920
 Data_length: 81920
Max_data_length: 0
 Index_length: 0
 Data_free: 0
 Auto_increment: NULL
 Create_time: 2025-02-02 07:06:31
 Update_time: 2025-02-02 07:06:59
 Check_time: NULL
 Collation: utf8mb4_0900_ai_ci
 Checksum: NULL
 Create_options:
 Comment:
1 row in set (0.00 sec)
 </code></pre>&nbsp;설명이 길었는데, 결론은 <code>TEXT/LONGTEXT</code> 타입 컬럼도 모두 <code>avg_row_length</code> 에 영향을 미치게 됩니다.

Mysql table  avg_row_length

안녕하세요.&nbsp;NULL이 저장될 수 있는 컬럼에 인덱스가 있다 하더라도, MySQL 서버의 인덱스는 (Oracle DBMS와 는 다르게) NULL 값을 인덱스에 포함하기 때문에, 인덱스만 읽어도 정확한 레코드 건수를 확인할 수 있다는 의미입니다.&nbsp;감사합니다.

Real MySQL 시즌1 part 2 에피소드 16의 인덱스가 null인 컬럼을 포함한다는 것에 대한 질문

안녕하세요.&nbsp;PostgreSQL 서버와는 달리, MySQL 서버는 데이터 페이지 공간이 부족해지는 시점에 페이지 단위로 Record Reorganize 작업을 하게 됩니다. 그래서 이 작업을 명시적으로 실행할 수 있는 방법은 optimize table 명령밖에 없는데,,, 이 작업을 굳이 명시적으로 하실 필요는 그렇게 많지 않습니다.&nbsp;감사합니다.

1강. delete marking된 데이터의 정리 주기는 어느 정도인가요?

안녕하세요.&nbsp;실제 실행 계획을 수립하는데 있어서는, WHERE 조건절에 나열된 조건의 순서는 영향을 미치지 않습니다.쿼리의 성능과 100% 무관하다고 말씀드리긴 어렵지만, MySQL 서버를 공부하시는 수준에서는 영향이 없다고 알고 계셔도 무리는 없어 보입니다. &nbsp;감사합니다.

MySQL Where절 내 조건의 순서

안녕하세요&nbsp;<blockquote>unique index는 s-lock을 꼭 필요로 한다면,delete가 선행되지 않는 상황에서도 deadlock이 발생해야되는거 아닌가? 싶습니다.</blockquote>넵, 맞습니다. 이 예제에서 첫번째 트랜잭션이 DELETE를 실행하는 건, 두번째와 세번째 트랜잭션이 동시에 시작되면서 두번째와 세번째 트랜잭션이 시점이 딱 맞아 떨어지도록 해주는 트리거 역할을 해주는 것입니다. 그래서 실제 Deadlock은 첫번째 트랜잭션에서 COMMIT을 실행하는 시점에 발생하게 되는 것입니다.&nbsp;감사합니다.

sungucklee2062

投稿