非専門家でも理解できるMySQL性能最適化入門/実践（SQLチューニング編）

<img src="https://cdn.inflearn.com/public/files/posts/aaae73e8-0da2-48d5-8484-1955d4e98412/1e85d487-3684-4a1c-9ab1-c937e8b89019.png" media-type="img"

강사님 안녕하세요. 😁강사님의 MySQL 성능 최적화 강의를

강사님 안녕하세요! 프로젝트를 끝내고 리팩토링을 하고이 있는데요.inner join 으로 3~4 개 정도의 테이블을 조인할 때, where 절이 과연 필요한가? 라는 궁금증이 생겼습니다.<p style="text

CREATE INDEX idx_name ON users (name); EXPLAIN SELECT * FROM users <p style="text-alig

강

안녕하세요 강사님 좋은 강의 정말 감사드립니다. 실습 따라면서 튜닝을 익혀가고있는데 이번 강의에서 이해되지 않는 부분이 있어 질문 남깁니다.일단 저는 MariaD

게시판 비슷한 기능을 구현중인데 아무래도 커서기반보다는 페이지를 원하는대로 넘나들 수 있는 페이지기반 페이지네이션을 구현하고 싶어서 구현은 했는데 대용량 데이터에는 맞지 않은 듯해서 어떻게 최적화를 하면 좋을지 고민하고

안녕하세요. 성능을 측정해보며 궁금증이 생겨 질문 드립니다. 같은 크기의 데이터에 대해 강사님께서 측정하신 시간이랑(강의에선 약 170ms) 제가 데이터그립으로 측정한 시간(약 80ms)에 꽤 차이가 있는데, 컴퓨터 사양이나 측정 툴에 따라 이 정도 차이가 있어도

-- 높은 재귀(반복) 횟수를 허용하도록 설정-- (아래에서 생성할 더미 데이터의 개수와 맞춰서 작성하면 된다.)SET SESSION cte_max_recursion_depth = 1000000; -- 더미 데이터 삽입 쿼리<

<img src="https://cdn.inflearn.com/public/files/posts/9130a30c-1e3d-4b08-9c26-2e716c8cdfa4/241df7e0-83e3-44e1-ae7f-c0f0d9f8a675.png" media-type="img"

만약 응답해야 되는 데이터는 "많은" 데이터인데데이터베이스에서 조회할 때는 LIMIT, WHERE로 나눠서 가져오고 애플리케이션 로직에서 합쳐서 응답하는게 나은가요?아니면 네트워크를 여러번 타는 것 보다는 이런 경우에는 한번에 가져오는게 더 나

EXPLAIN ANALYZE SELECT * FROM users ORDER BY salary LIMIT 100; -> Limit: 100 row(s)  (cost=100569 rows=100) (actual time

having에 있는 쿼리문을 where문으로 바꿔서 최적화 시키는 것은 이해가 갔습니다. 강의에는 인덱스 사용이 없어서 제가 한번 적용시켜보려고 멀티 컬럼(year, semester) 이렇게 넣고 explain 해보니 ref와 eq_ref가 떴는데도

-- 테이블 A: 인덱스가 없는 테이블CREATE <stro

MariaDB 사용하고 있고 버전은 아래와 같은데 회사 DB로 버전 변경은 불가능한 상태입니다. 버전 : 10.4.12-6-MariaDB-enterprise-log EXPLAIN ANALYZE 사

안녕하세요 선생님강의 잘 듣고 실무에서 배운 대로 인덱스를 좀 더 적극적으로 사용하려고 하는데, 평소에 깊은 고민하지 않다가 이제 해보려고 하니까 많이 고통스러운 시기를 지나고 있는 것 같습니다. 혹시 선생님께서 튜닝

강의 너무 잘 보았습니다.혹시 힌트 도 주요 튜닝 방법중 하나인데.이쪽은 강의계획이 없으신지 여쭤보고싶습니다.

안녕하세요 강의 잘 듣고 있습니다!jpa를 사용해서 프로젝트를 진행하면 쿼리 메서드를 사용할텐데 select * jpql로 다 작성해주어야 하나요?jpa로 프로젝트 진행할때 팁이나 검

안녕하세요, 좋은 강의 감사합니다. 제공해 주신 쿼리에 대해 질문이 있는데요,제 생각에는 아래 쿼리가 특정 부서에서 최대 연봉을 가진 사용자를 조회하는게 아닌,전체 부서에서 최대 연봉이 x 라고 하면,</

안녕하세요, 좋은 강의 감사합니다. created_at 에 index 를 걸어서 order by 와 같은 문제를 해결하는 것을 보았는데요, 데이터가 지속적으로 증가하고 밀리초 단위로 들어오는 created_at 이 있다면, 이것들