12분 20초 경에 "복잡한 분석을 하는 경우에 엄청난 쿼리를 전송하는 경우도 있고~" 라는 말씀을 해주시는데요. 여기서 말하는 엄청난 쿼리는 어떤 쿼리인지 잘 모르겠습니다. 데이터베이스에 굉장히 많은, 혹은 복잡한 연산을 야기하는 쿼리일까요? 쿼리가 길고 뚱뚱해서 대체 어떤 걸하는 쿼리인지 사람이 읽고 파악하기 어려운 쿼리를 말하는 걸까요?
13강 7분 30초 경부터 말씀해주시는 내용을 정리해보면 "커서 기반 페이징 조건 대상은 순차적인 값이어야 한다. AUTO_INCREMENT 설정 컬럼은 순차성이 깨질 수 있는 가능성이 있기에 그보다는 ULID가 권장된다." 라는 이야기로 정리해볼 수 있는데요. 여기서 Hong님께서 순차적인 값이어야 한다고 알려주신 이유가 무엇인지 궁금합니다. 커서 기반 페이징을 하기 위해서는 조건 대상이 다음과 같은 사항만 만족하면 되지 않을까요? 유니크해야 한다 - 같은 값이 여러 행에 있으면 커서가 모호해짐 정렬 가능해야 한다 - > , < 비교 연산이 의미 있어야 함
안녕하세요. 좋은 강의 감사합니다. 강의와 직접적으로 관련 있는 내용은 아니지만 궁금한 점이 있어 질문드립니다. 클라이언트에서 MySQL 서버로 아래와 같이 요청할 텐데 BEGIN 쿼리 COMMIT 3번에서 MySQL 서버가 클라이언트의 Commit 요청을 받고 처리 완료 후, 클라이언트에게 응답하려는 순간 네트워크가 단절되면 Commit은 되었지만 클라이언트는 실패로 인지할 텐데 이런 경우 어떻게 대응해야 하는지 궁금합니다. 아니면 MySQL 서버에 네트워크 전송 실패를 감지하고 해당 트랜잭션을 보정하는 동작이 있을까요? 감사합니다.
EXPLAIN SELECT * FROM accounts WHERE YEAR(created_at) = 2023; MySQL 9.5부터 explain plan 출력 방식이 바뀌어서 위 explain문을 사용하면 결과가 다르게 나옵니다 EXPLAIN FORMAT = TRADITIONAL SELECT * FROM accounts WHERE YEAR(created_at) = 2023; 위처럼 FORMAT = TRADITIONAL로 변경하시면 기존처럼 출력되어 해결됩니다 간단하게 docker로 해보려다가 이런 변경점을 알고가네요
애플리케이션단에서 범위조건 사용할때 2024-01-02 00:00:00 값을 어떻게 넘겨야줘야되나요? 말씀하신 내용 토대로 보면 라스트 finished_at : 2024-01-01 00:00:02 id : 8 두가지정도만 넘길수 있을꺼 같은데요 그래서 애플리케이션 파라미터는 두가지값남 넘기고 처리 해야되지 않나 싶어서 여쭤봅니다. 그래서 해당쿼리로 날려도 상관 없을지 질문드립니다. SELECT * FROM posts WHERE (created_at < '2024-01-01 00:00:02') OR (created_at = '2024-01-01 00:00:02' AND id < 8) ORDER BY created_at DESC, id DESC
안녕하세요 HikariCP maxLifetime 에 궁금한게 있어서 질문드려요, mysql 에 직접적인 질문은 아닌 것 같지만 혹시 답변을 받을 수 있을까해서요 아래 같은 상황에서 HikariCP maxLifetime 이 connection pool 부족과 직접적인 연관이 있을 가능성이 있는지 궁금합니다. 상황 reader, writer ds의 connection pool 고갈 이슈가 잦은 서버 (50개씩 세팅, pod 5) HikariCP maxLifetime 은 30s 로 세팅되어있음 (디폴트는 30분)
인덱스가 아래와 같을때 idx_orders_user_status(user_id, status, created_at) 아래 쿼리문이 왜 문제인지 궁금합니다. select * from orders where 1=1 and status = 'pending' and user_id = 123 강의 내용(11분 30초)에서는 인덱스의 컬럼 순서와 조건문(where)의 컬럼 순서가 틀려 효율적이지 못하다고 설명해 주시는 거 같습니다. 하지만 이는 옵티마이저에 의해 where절의 컬럼 순서를 재계획 하는 걸로 알 고 있습니다. 강의의 의도는 left prefix index rule 때문에 인덱스 순서를 조심해야 한다는 내용인 거 같은데... 혹시 꼭 순서를 지켜야 하는 이유가 있을까요?? (첫 번째 인덱스 미사용, 중간 컬럼 미사용, 커버링 인덱스 등의 특정 상황 제외)
안녕하세요. 항상 영상 잘 시청하고 있습니다. 이번에 강의를 시청과 실무에서 업무를 하면서 궁금한 사항이 있어서 질문을 작성합니다. 실무에서 인덱스 및 DB에 대해서 최근에 고민이 있습니다. 하나의 테이블에 어쩔 수 없이 컬럼이 많아지는 경우 인덱스가 많아지는 경우가 있어 고민이 됩니다. 물론 상황마다 다르겠지만 강사님의 의견이 궁금하여 질문을 드립니다. 질문 인덱스 : 조회의 다양한 경우가 있어서 인덱스가 과도하게 많아지는 경우가 있습니다. ex) 복합 인덱스 (A,B,C)가 있다고 가정하면 선행 인덱스가 포함되지 않는 경우에 그냥 인덱스를 추가를 하시는지 궁금합니다. 간단하게 강의에서 post를 기준으로 (title, content)의 인덱스에서 나중에 content만 필터를 해야 되는 경우 ( 실제로 content에 인덱스는 적절하지 않다고 생각하지만 예시 ) 1-1. 만약에 추가를 하게 된다면 하나의 Table에 최대 인덱스 개수는 몇개로 지정을 하시는지 궁금합니다. 너무 많아지게 되면 Write작업에 대해서 부화를 가지기 때문에 측정을 하시는 기준점이 있는지 궁금합니다. ( 상황마다 다르겠지만 일반적으로 생각하시는 기준 ) MySQL에서 집계에 대한 아키텍처 하나의 재고를 row로 표현하는 테이블이 있다고 가정하면 특정 상품의 재고를 구하기 위해서 count를 사용을 해야됩니다. (하나의 row는 상품 1개) 캐싱을 처리하면 데이터의 정합성에 문제가 생기고 매번 쿼리를 실행하면 성능 및 DB에 부화가 발생합니다. 이것을 개선하기 위해서 만약에 집계 테이블을 만들어 Redis, Kafka에서 이벤트가 발생하면 집계 테이블에 개수를 수정하는 방식으로 실무에서 많이 사용되는지 궁금합니다. 만약에 많이 사용이 된다면 주의사항이 어떤게 있을까요??
안녕하세요 (2) LEFT JOIN 사용 방법 준수 - 오타 질문 (3:58 부근) 에서 첫 번째 SQL이 아래와 같이 써있는데요 select u.id, u.name, ua.value from user u left join user_attribute ua on ua.user_id=u.id where ua.name='address' where 조건에 ua.name 이 아니고, ua.value가 아닐까 의미적으로 맞는게 아닌가 싶어서 질문드립니다. 전체 스키마가 있는게 아니다보니 제가 오해한 걸수도 있어서, user, user_attribute 테이블 전체 스키마를 주시면 감사하겠습니다!
안녕하세요, 강의 잘 듣고 있습니다. 04 페이징 쿼리 작성 강의 > 데이터 개수 기반 방식 (동등 조건 사용 시) (9:36 부근) 에 나온 예시에 대한 질문입니다. KEY index_userid_id (user_id, id)로 인덱스가 있는데요, user_id +id 가 아닌, user_id만 인덱스로 걸어도 N회차 쿼리가 잘 동작 할까요? where 절에 user_id, id를 사용하고, ORDER BY 에 id가 있기 때문에 user_id + id 인덱스가 필요한 걸까요? 조금 더 자세히 알려주시면 감사하겠습니다.
문자열 형식의 숫자를 정렬하는 팁을 알려주셨는데, ORDER BY a=1 ASC; 가 어떻게 숫자를 정렬시킬 수 있는걸까요? 결국 결과는 boolean으로 a가 1인 컬럼은 true가 되면서 맨위로 오고 나머지는 모두 false가 되고 정렬은 옵티마이저 선택에 따라 뒤죽박죽일꺼같은데 설명 한번 부탁드립니다.
