Juni's space

cd /Users/juni/Private/Git/MySQL-source/mysql-8.0.37/BUILD./bin/mysql -u root -p${PASSWORD}먼저 관련 패키지를 인스톨 한다.brew install opensslbrew install cmake source code를 다운로드 받는다.https://dev.mysql.com/downloads/file/?id=528066  cd /Users/uijun-lee/Private/Git/MySQL-sourcemv ~/Downloads/mysql-boost-8.0.37.tar.gz .tar zxvf mysql-boost-8.0.37.tar.gzmkdir BUILD ; cd BUILD cmake를 실행한다.cmake -DWITH_DEBUG=1 -DW..

최근 ULID(https://github.com/ulid/spec)가 팀 내에서 화제거리이다. ULID를 PK로 했을 때, auto_increment의 sequencial insert 패턴과 비교해 어떤 움직임이 있는 지, 그리고 어떤 영향을 예상할 수 있을까에 대해서 조금 이야기 해 보고 싶다. 우선 UUID의 이야기를 보면, UUID는 기본적으로 random성격의 ID가 발행되는 데, 이 것을 PK로 해서 MySQL에 insert할 때에는 random으로 들어갈 가능성이 높을 것으로 생각된다. 이 때 MySQL이 사용하고 있는 B-tree index는 어떤 동작을 할까? 많은 사람들은 B-tree index의 "B"는 Binary라고 생각하는 사람도 많은 것 같은데, 여기서 B는 "Balanced"의..

"Insert intention lock"은 레코드 인서트 전에 INSERT조작에 의해서 설정되는 Gap lock의 일종입니다. 이 락(잠금)은 동일한 인덱스 갭에 인서트된 여러 트랜잭션이 갭(간격) 내에서 동일한 위치에 인서트되지 않을 경우 서로 기다릴 필요가 없도록 인서트하려는 의도를 나타냅니다.값이 4와 7의 인덱스 레코드가 존재한다고 가정합니다. 각각 5와 6의 값을 인서트하려는 트랜잭션은 인서트된 행에 대한 단독 잠금을 얻기 전에 각각 4와 7 사이의 간격을 인서트 인텐션 락으로 잠그지만 행이 충돌하지 않으므로 서로 차단하지 않습니다. 다음 예에서는 인서트된 레코드에 대한 배타적 잠금을 얻기 전에 인서트 인텐션 락을 실행하는 트랜잭션을 보여 줍니다. 이 예에는 A와 B라는 두 고객이 포함됩니다...

mysql> show variables like "%ping%"; +---------------------------------+--------+ | Variable_name | Value | +---------------------------------+--------+ | mysql-monitor_ping_max_failures | 3 | | mysql-monitor_ping_timeout | 1000 | | mysql-monitor_ping_interval | 10000 | | mysql-ping_interval_server_msec | 120000 | | mysql-ping_timeout_server | 500 | +---------------------------------+--------+ 5..

---------- SEMAPHORES ---------- OS WAIT ARRAY INFO: reservation count 34862552 スレッドがセマフォの配列に入ったOS待ち（OS wait）の回数 OS WAIT ARRAY INFO: signal count 116266440 ＝＝＞signal countが配列に入ってOSからシグナルを受け取った回数です。後述しますが、この回数は少ないほど良いです。 Mutex spin waits 545963329, rounds 2602243608, OS waits 17985576 RW-shared spins 44035445, rounds 395257570, OS waits 8059822 RW-excl spins 19326255, rounds 500665340, OS waits 6..

read-ahead 란? 하나의 extent(64개 pages group)을 모두 buffer pool에 prefetch하는 작업. (asynchronous request임) 이들 페이지도 곧 읽혀질거라는 가정하에 모두 버퍼에 올리는 것 알고리즘 linear read-ahead technique: 버퍼풀 안에 순차적으로 읽혀진 페이지 개수로 판단 만약 하나의 extent내에서 순차적으로 읽혀진 페이지 개수가 innodb_read_ahead_threshold 이상이면 다음 extent전체 페이지를 read-ahead random read-ahead technique: 버퍼풀 안에 존재하는 페이지 개수로 판단(순차적인지 여부와 무관함) 만약 한 extent내의 13개의 연속된 페이지가 버퍼풀에 존재한다면, ..

일단 우선 엑터를 확인하자. mysql> SELECT * FROM performance_schema.setup_actors; +------+------+------+---------+---------+ | HOST | USER | ROLE | ENABLED | HISTORY | +------+------+------+---------+---------+ | % | % | % | NO | NO | +------+------+------+---------+---------+ 1 row in set (0.00 sec) 이 것을 활성화 해야 한다. mysql> UPDATE performance_schema.setup_instruments SET ENABLED = 'YES', TIMED = 'YES' WHERE ..

set global innodb_status_output = ON; set global innodb_status_output_locks = ON; mysql> show variables like "%innodb_status%"; +----------------------------+-------+ | Variable_name | Value | +----------------------------+-------+ | innodb_status_output | ON | | innodb_status_output_locks | ON | +----------------------------+-------+

innodb_fill_factor : Sorted index build를 할때 페이지의 충전율을 지정할 수 있다. innodb_tmpdir : ALTER TABLE의 영역을 별도로 지정할 수 있다.