Database

개요 테이블 이름 변경은 ALTER TABLE로도 가능하지만, RENAME TABLE을 쓰면 다수 테이블을 한 번에 처리 가능하며 같은 서버 내 다른 데이터베이스로 이동까지 가능함 핵심 차이 ALTER TABLE RENAME은 단일 테이블 대상 RENAME TABLE은 여러 테이블을 한 문장으로 변경 가능 스키마 간 이동 지원 current_db.table에서 other_db.table로 변경 가능 동일 트랜잭션처럼 동작하는 원자성 제공, 다중 변경 중 하나라도 실패 시 전체 미적용 권한 요구 사항 존재, 원본 테이블에 ALTER와 DROP, 대상 스키마에 CREATE 권한 필요 트리거와 외래키 메타데이터는 함께 유지되나, 뷰나 저장 프로시저의 하드코딩된 참조는 자동 갱신되지 않음 사용법 단일 테이블 이름 변경 RENAME TABLE old_table TO new_table; 단일 테이블 이름 변경 ALTER 사용 ALTER TABLE old_table RENAME new_table; 다수 테이블 이름 일괄 변경 RENAME TABLE old_table1 TO new_table1, old_table2 TO new_table2, old_table3 TO new_table3; 다른 데이터베이스로 이동 같은 서버 내 RENAME TABLE current_db.table_name TO other_db.table_name; 주의 사항 대상 이름이 이미 존재하면 실패 교차 서버 이동 불가, 같은 서버 인스턴스 내 스키마 간 이동만 가능 실행 시 메타데이터 락 획득, 짧은 구간 동안 읽기나 쓰기 대기 가능 배치 변경 전 사전 검증 권장, 이름 충돌 여부와 권한 확인 뷰나 프로시저 참조는 수동 점검 필요, 린트나 간단한 탐색 쿼리로 영향 범위 확인 권장 정리 단일 변경만 필요하면 ALTER로 충분하나, 다수 변경이나 스키마 이동까지 고려하면 RENAME TABLE이 더 실용적 선택 원자적 일괄 변경과 스키마 간 이동을 활용하되, 권한과 의존성 영향 검증을 선행할 것 ...

기본 문법 LIMIT는 SELECT 결과에서 반환할 행 수를 제한하는 구문 WHERE와 ORDER BY 뒤, 즉 SELECT 문 끝에 위치 두 가지 형태 사용 SELECT 컬럼명 FROM 테이블명 LIMIT 개수 SELECT 컬럼명 FROM 테이블명 LIMIT 개수 OFFSET 시작_인덱스 일부 dialect에서는 아래 축약형도 존재 -- MySQL, SQLite SELECT 컬럼명 FROM 테이블명 LIMIT 시작_인덱스, 개수 1. LIMIT 개수 LIMIT 뒤 숫자는 인덱스가 아닌 개수 SELECT * FROM Book LIMIT 1 현재 정렬 기준에서 맨 위 행 1개만 반환 ORDER BY가 없으면 반환되는 행은 비결정적일 수 있음 ...

개요 EXPLAIN은 SELECT가 어떤 경로로 데이터를 읽는지 드러내는 도구 병목 파악과 인덱스 전략 점검에 사용 핵심 개념 select_type SIMPLE 단순 SELECT, 서브쿼리나 UNION 없음 PRIMARY 가장 바깥쪽 SELECT SUBQUERY 서브쿼리 DERIVED FROM 절의 서브쿼리 UNION UNION의 두 번째 이후 SELECT type 실행 품질 지표, 위에서 아래로 유리 system 테이블에 단 하나의 행 const PRIMARY KEY 또는 UNIQUE 인덱스 단건 조회 eq_ref 조인에서 PRIMARY KEY 또는 UNIQUE로 정확히 1행 매칭 ref 인덱스를 사용한 동등 조건 검색 range 인덱스를 사용한 범위 검색 index 인덱스 전체 스캔 ALL 테이블 전체 스캔, 최악 possible_keys 사용 가능한 인덱스 목록, NULL이면 후보 없음 key 실제 사용된 인덱스, NULL이면 인덱스 미사용 rows 옵티마이저가 읽을 것으로 추정한 행 수, 낮을수록 유리 filtered 조건 후 남는 행 비율 추정치, 높을수록 유리 Extra 추가 단서 Using index 커버링 인덱스 사용, 유리 Using where WHERE 조건으로 필터링 수행 Using filesort 추가 정렬 필요, 비용 큼 Using temporary 임시 테이블 사용, 비용 큼 해석 기준 type이 const, ref, range 범주에 위치 key가 NULL이 아니고 적절한 인덱스 선택 rows 추정치가 작고 filtered 비율이 높음 Extra에 Using filesort, Using temporary 부재 예시와 해석 type: ALL possible_keys: NULL rows: 3527425 Extra: Using where; Using filesort 테이블 전체 스캔으로 많은 행을 읽게 됨 인덱스 후보와 실제 사용 인덱스가 없음 WHERE로 필터링하고 추가 정렬까지 수행하여 비용 상승 현재 계획은 인덱스 설계와 조건식 재검토 필요 주의와 팁 rows와 filtered는 통계 기반 추정치라 실제와 오차 가능 filtered는 대략 rows × filtered%로 남는 행 규모 가늠에 사용 Using filesort가 항상 나쁜 것은 아님, 결과 집합이 매우 작으면 영향 미미할 수 있음 인덱스 생성 시 조건 컬럼의 선택도와 정렬·조인 키 우선 고려 커버링 인덱스 구성 시 Extra의 Using index로 확인 가능 마무리 EXPLAIN은 증상 관찰 도구, 원인은 스키마 설계와 조건식, 인덱스 전략에서 찾기 위 지표를 기준으로 스캔 범위를 줄이고 불필요한 정렬과 임시 테이블을 제거하는 방향으로 개선 시도 권장 ...