Freesia

기본적으로 DataSource 커넥션은 @Transactional이 선언된 메서드가 호출될 때 획득되고, 메서드 실행이 끝나서 트랜잭션이 commit 또는 rollback 되면 커넥션도 반환된다. 그래서 일반적으로는 트랜잭션의 생애주기와 커넥션의 생애주기가 동일하게 간다고 봐도 무관하다.하지만 경계가 명확히 다른 두 트랜잭션이더라도, 같은 스레드 안에서 동일한 트랜잭션 매니저를 사용하고 전파 속성의 기본값( Propagation.REQUIRED)을 사용중이라면 상황이 달라진다. 이 경우 두 트랜잭션은 분명히 각각 커밋이 되더라도, 이미 ThreadLocal에 바인딩된 커넥션이 있다면 새로 열지 않고 커넥션을 그대로 재사용한다. 나는 이를 모른 체로 디버깅을 하다가 datasource.getConnecti..

예전에 TEXT vs LONG TEXT 에 대해서 다루고(https://glqdlt.tistory.com/504), varchar 로 한글 65355 개를 입력할수 있는지를 다룬 적(https://glqdlt.tistory.com/509)이 있다. 이 때 vs text 에 대한 내용도 살짝 다루었었는데, 오늘은 이를 주제로 다루어볼까 한다.어떠한 게임 서비스든 웹 서비스든 최초 진입점에 노출되는 공지 사항, 배너 같은 것들이 있을테고, 여기에 사용되는 이미지가 있긴 마련일테다. 이 이미지의 주소를 mysql 테이블에 저장해야한다면, VARCHAR 컬럼을 써야할지 TEXT 컬럼을 써야할지가 고민이 들 수 있다.이에 대해서는 관습적으로 '어쩔 수 없을 때 TEXT 컬럼을 써라' 라는 대답이 주를 이룬다. 청..

JPA 를 쓰면 사실 인덱스가 필요없다. 이건 또 무슨 헛소리일까, 7월의 무더위를 먹어버린 탓일까? 자 한번 내 얘기를 들어보시라.이 주장은 커버링인덱스와 관련이 있다. 커버링인덱스는 어떠한 쿼리보다도 가장 빠르게 응답 할수있는 현상을 말한다. 커버링인덱스는 select 쿼리의 결과 필드가 쿼리에 쓰인 인덱스인 경우에 커버링인덱스가 발동한다. 아래의 쿼리를 보자.select t.col1, t.col2 from tb_table as t where t.col1 = ? and t.col2 =?이 쿼리의 대상 tb_table 에는 복합인덱스 col1 과 col2 가 있다. 이 쿼리의 반환 결과는 col1 과 col2 만 반환한다. 이 경우에 커버링인덱스가 발동한다. 커버링인덱스는 mysql explain 실행..

서브쿼리의 결과가 정확히 1행 1열이라면, 이를 스칼라 서브쿼리(Scalar Subquery) 라고 부른다. 스칼라 서브쿼리는 이러한 단일 값을 SELECT 절, WHERE 절, HAVING 절 등에서 필드처럼 사용할 수 있는 서브쿼리를 의미한다. A scalar subquery is a simple operand, and you can use it almost anywhere a single column value or literal is legal, and you can expect it to have those characteristics that all operands have: a data type, a length, an indication that it can be NULL, and so ..

제목에 대한 대답은 JPA 에서는 integer 를 써야한다가 나의 대답이다, 그것도 확고하게. JPA 에서는, 더 나아가서 Java 에서는 int 를 사용하면 안된다.Java에서 정수를 표현하는 방법은 두 가지가 있다. int와 Integer. 전자는 primitive type이고, 후자는 wrapper type 이라 부른다. 이 정도는 JPA를 쓰는 Java 개발자라면 당연히 알고 있는 내용일테니 더 길게 설명하진 않겠다. 중요한 건 이 차이가 JPA에서 매우 중요한 문제가 된다는 거다.RDBMS에서는 null이란 개념이 존재한다. RDBMS에서 null 은 값이 아직 할당 되지 않은 상태를 나타내는 표현이며, 이는 RDBMS 에서 매우 중요하다. 그런데 java 세상에서는 int, long, boo..

제목이 참 자극적이다. 사실 이 말은 절반만 맞다. 상황마다 다르기 때문이다. 대체적으로 인덱스가 성능이 좋지만, 절대적으로 테이블 풀 스캔이 마냥 나쁘다는 선입견을 없애고자 이렇게 지었다.테이블 풀스캔이 무조건 나쁜 것으로 많이들 생각하지만 엄연히 말하면 나쁜 것은 아니다. 오히려 인덱스 보다 더 효율이 좋을 때가 많다. 인덱스를 깊게 공부를 해보면 인덱스가 생각보다 비효율적이란 걸 알 수 있는데, 이에 비해 풀스캔은 매우 효율적으로 동작한다.예를 들어서 PK 가 단순 증가 정수(auto increment) 로 되어 있는 테이블에 아래 쿼리를 날렸다 보자.select * from some_table where write_date between 오늘 and 다음주 limit 500,000이 때 write..

RDBMS 모델링에서는 키 에 대한 정의가 세분화 되어 있다. 논리 모델링과 물리 모델링 에서 쓰여지는 키가 각각 다름에도 통용적으로 얘기가 되다 보니 헷갈려 하는 사람이 많다. 적어도 나는 공부할 때 많이 헤맸었다. 각각의 키에 대해서는 따로 정리 해둔 글이 있음으로, 해당 글의 설명으로 대체하겠다. https://glqdlt.tistory.com/528개인적으로는 가상키를 PK로 많이 쓰는 편이다. 컬럼 이름은 id 이고 타입은 Integer 이며 auto increment 옵션을 둔다. 그냥 단순 증가 정수를 PK로 쓴다. 그런데 가끔은 클러스터링 군집화 때문에 복합PK를 정의해야할 때도 있다, 이럴 땐 단순 증가 정수 유니크컬럼을 추가로 만들고 JPA 엔티티 상에서는 ID 인 마냥 쓰기도 한다. ..

MySQL에서 테이블에 파티션을 걸면 성능이 빨라진다고들 한다. 특히 대용량 테이블에선 "파티션이 정답이다", "파티션만 걸면 빨라진다"는 맹신 하는 사람이 가끔 있다. 마치 파티션이 만병통치약인 마냥 말이다.그런데 정말 그럴까? 파티션이 만병통치약이라면, 왜 mysql 은 기본적으로 파티션을 강제화하지 않는걸까? 그 이유는 파티션은 잘 써야 약이고, 잘못 쓰면 독이기 때문이다, 만병통치약이 아니다파티션은 테이블을 물리적으로 분리하는 개념이다. 동일한 하드디스크에서 테이블 데이터가 적재되어있는 물리적 파일을 N개로 나눈다고 할지라도, 같은 하드디스크 IO 영향을 받는다. 만약 물리적으로 나뉜 N개의 파일을 각기 다른 하드디스크에 적재한다면 병렬 IO 의 이점으로 성능은 많이 올라갈 수 있다. 여기서는 병..

* 이 글은 mysql8 기준이다.흔히들 varchar 의 길이는 입력가능한 문자열의 최대값으로 알려져있다. 정말 그런걸까? 이는 반은 맞고 반은 틀린 말이다.지난 번(https://glqdlt.tistory.com/504)에 text 와 long text 에 대해 공부를 했었다. charset encoding 이 무엇이냐에 따라 text 에 입력가능한 글자수가 달라진다고 얘기한 바 있다. 이는 varchar 에서도 유효할까?varchar 컬럼은 한글 65535 개를 입력할 수 없다.varchar는 동적문자열이고, 최대 varchar(65535) 까지 지정이 가능하다. varchar 의 길이는 입력된 문자열의 길이와 같다고 알려져 있지만 정확히는 아니다. 테이블에 다른 컬럼이 몇개 있느냐와 charset..

* 이 글은 mysql8 기준이다.MYSQL 테이블을 모델링 하다 보면, INT 를 써야할지, BIGINT 를 써야할지. 또는 TEXT 를 써야할지 LONG TEXT 를 써야할지 고민이 될 때가 있다. 고민에 대한 나름의 답을 내고자,공식 문서를 참고하여 내용을 정리해 보았다.참고 문서(https://dev.mysql.com/doc/refman/8.0/en/storage-requirements.html)이번 글에서는 INT vs BIGINT, 그리고 TEXT vs LONGTEXT 각각의 차이를 설명할 예정이다.숫자와 문자는 성격이 전혀 다른 데이터 타입이므로, 설명도 구분해서 진행하겠다.먼저 숫자이다. 참고 문서 (https://dev.mysql.com/doc/refman/8.0/en/storage-r..