워드프레스 MySQL DB 최적화 방법 phpMyAdmin SSH WHM cPanel 호스팅별 정리

워드프레스가 느릴 때 많은 분들이 먼저 캐시 플러그인이나 이미지 압축부터 만집니다. 실제로 그것도 중요하지만, 오래 운영한 사이트라면 데이터베이스부터 한 번 점검하는 편이 훨씬 빠르게 체감이 오는 경우가 많습니다. 글과 댓글, 옵션, 세션, 장바구니, 액션 스케줄러, 통계, 로그, 플러그인 찌꺼기가 계속 쌓이면 관리자 화면이 굼떠지고 글 저장이 늦어지며, WooCommerce 주문 처리나 검색, 백업, 이전 작업까지 전부 느려집니다.

특히 요즘 워드프레스는 단순 블로그보다 쇼핑몰, 커뮤니티, 예약, LMS, 멀티사이트처럼 DB를 자주 읽고 쓰는 구조가 많아서 DB 최적화가 빠지면 캐시만으로는 한계가 분명합니다. 서버 사양이 충분한데도 관리자 화면이 버벅이거나, phpMyAdmin에서 테이블 열기만 해도 오래 걸리거나, 간헐적으로 데이터베이스 연결 오류가 뜬다면 DB 용량과 구조부터 보는 편이 맞습니다

이런 증상이 있으면 DB부터 보셔야 합니다.

• 워드프레스 관리자 진입은 되는데 글 목록, 주문 목록, 플러그인 화면이 유독 느림
• 백업 플러그인이 중간에 멈추거나 DB 덤프 파일이 지나치게 큼
• phpMyAdmin에서 export/import, optimize, search-replace 작업 중 timeout이 잦음
• WooCommerce 사용 중 wp_actionscheduler_actions, wp_postmeta, wp_options가 비정상적으로 커짐
• 디스크 용량은 남아 있는데 MySQL/MariaDB CPU 사용률이 높고 슬로우 쿼리가 계속 쌓임
• 사이트 헬스에서 autoloaded options 경고가 뜸

관련 내부글 보기 워드프레스 최적화 공식 문서 WP-CLI DB Optimize mysqlcheck 공식 문서 WHM DB 설정 문서

워드프레스 DB 최적화를 해야 하는 이유

워드프레스는 대부분의 핵심 데이터를 DB에 저장합니다. 글과 페이지는 물론이고 댓글, 메뉴, 위젯, 옵션, 사용자 세션, 플러그인 설정, WooCommerce 주문, 임시 캐시까지 거의 다 DB를 거칩니다. 그래서 DB가 비대해지거나 구조가 꼬이면 눈에 보이는 현상은 사이트 전체 속도 저하로 나타납니다.

특히 느려지기 쉬운 테이블

• wp_options : autoload 옵션이 과도하면 모든 페이지 로드 때마다 메모리를 잡아먹습니다.
• wp_postmeta : 쇼핑몰, 페이지빌더, SEO 플러그인이 오래 쌓이면 금방 비대해집니다.
• wp_actionscheduler_actions : WooCommerce, 예약, 메일 큐 플러그인이 많으면 급격히 커집니다.
• comments / commentmeta : 스팸 댓글이 많거나 댓글 플러그인 사용 시 커질 수 있습니다.
• plugin log / stats 테이블 : 보안, 통계, 방문자 추적, 로그 플러그인이 주범인 경우가 많습니다.

사이트 헬스에서 autoload 경고가 나오면 그냥 넘기면 안 됩니다.
워드프레스는 autoloaded options가 너무 크면 사이트가 느려질 수 있다고 직접 경고합니다. 플러그인 몇 개만 추가되어도 wp_options가 바로 문제 테이블이 되는 경우가 많습니다.

최적화 전에 꼭 해야 할 것

DB 백업부터 먼저

이건 무조건입니다. 최적화는 대부분 안전하지만, 대형 사이트나 오래된 테이블 구조, 손상된 테이블, 문자셋 충돌이 있는 경우에는 되돌려야 할 일이 생깁니다. 최소한 DB 덤프 파일 1개와 사이트 전체 파일 백업 1개는 먼저 챙겨두는 편이 맞습니다.

작업 시간대 선택

OPTIMIZE TABLE, CHECK TABLE, mysqlcheck 같은 작업은 테이블을 잠그거나 재구성하는 과정이 들어갈 수 있어서 트래픽이 많은 시간대에는 피하는 편이 좋습니다. 특히 주문이 들어오는 쇼핑몰이면 새벽이나 방문이 적은 시간으로 잡는 것이 안전합니다.

스토리지 엔진 확인

지금 워드프레스는 대부분 InnoDB를 씁니다. 이때 예전처럼 아무 테이블에나 무조건 REPAIR를 돌리면 해결되는 구조가 아닙니다. REPAIR TABLE은 특정 스토리지 엔진에서만 제한적으로 동작하므로, InnoDB라면 먼저 체크, 백업, 로그 확인, 필요 시 테이블 재구성 쪽으로 가는 편이 맞습니다.

중요
“최적화”는 만능 버튼이 아닙니다. DB가 큰 진짜 이유가 오래된 트랜지언트, 액션 스케줄러 누적, 스팸 댓글, 백업 플러그인 테이블, 로그 플러그인, autoload 옵션 과다라면, 원인을 먼저 줄이지 않으면 optimize만 반복해도 다시 커집니다.

가장 쉬운 방법은 phpMyAdmin 최적화

공유호스팅이나 일반 웹호스팅에서는 phpMyAdmin부터 보는 편이 가장 쉽습니다.

블루호스트처럼 cPanel 계열은 phpMyAdmin 접근이 비교적 단순하고, 가비아도 phpMyAdmin을 콘솔이나 직접 URL에서 열 수 있습니다.

다만 카페24는 상품과 PHP 버전에 따라 방식이 조금 다르고, 워드프레스 VPS 계열은 웹형 phpMyAdmin 대신 외부 클라이언트나 SSH를 더 자주 쓰게 됩니다.

 

 

phpMyAdmin에서 기본 점검 순서

01

1. 대상 DB를 선택합니다.
2. 아래에서 모두 체크를 누릅니다.
3. 드롭다운에서 먼저 Check table 또는 검사를 실행합니다.
4. 이상 없는 테이블만 Optimize table을 실행합니다.
5. 손상 의심 테이블이 있을 때만 Repair table을 검토합니다.

여기서 중요한 점은, 현재 워드프레스 대부분이 InnoDB 기반이라 복구가 필요한 상황에서도 무조건 Repair를 누르는 것보다 먼저 체크와 백업이 더 우선이라는 점입니다. Optimize도 사이트 전체를 빠르게 만드는 마법 버튼이라기보다, 조각난 공간 회수와 테이블 재정리에 가까운 작업이라고 생각하는 편이 정확합니다.

최적화 버튼을 눌렀는데 오류가 나는 경우

1. phpMyAdmin timeout

DB가 너무 크면 브라우저 기반 작업은 쉽게 timeout이 납니다.

특히 수백 MB 이상이거나, 테이블 수가 많거나, 주문 테이블과 로그 테이블이 많은 사이트는 phpMyAdmin보다 SSH가 훨씬 안정적입니다.

2. InnoDB라서 Repair가 제대로 안 먹는 경우

이건 꽤 흔합니다. \오래된 글에서는 “모두 체크 → 복구 → 최적화”처럼 단순하게 설명하지만, 실제 운영 사이트는 InnoDB가 대부분이라 결과가 기대와 다를 수 있습니다. 이런 경우에는 아래 순서가 더 안전합니다.

1. DB 백업
2. CHECK TABLE 또는 wp db check
3. MySQL/MariaDB 에러 로그 확인
4. 슬로우 쿼리와 문제가 된 플러그인 확인
5. 불필요 테이블과 데이터를 먼저 줄인 뒤 다시 최적화

3. 디스크 용량 부족

최적화나 복구 작업은 임시 공간을 더 필요로 할 수 있습니다.

디스크 여유가 거의 없는 상태에서 DB 최적화를 반복하면 오히려 실패 확률이 높아집니다. 이럴 때는 먼저 백업 파일, 캐시, 오래된 로그, 중복 업로드, 임시 파일부터 정리해야 합니다.

4. DB 자체가 너무 큰 경우

이때는 단순 optimize보다 무슨 테이블이 큰지부터 확인하는 편이 맞습니다. 감으로 작업하면 시간만 쓰고 효과는 거의 없습니다.

SELECT table_name,
       ROUND((data_length + index_length) / 1024 / 1024, 2) AS size_mb,
       table_rows,
       engine
FROM information_schema.tables
WHERE table_schema = DATABASE()
ORDER BY (data_length + index_length) DESC;

이 쿼리를 phpMyAdmin의 SQL 탭에서 실행하면 어느 테이블이 큰지 바로 보입니다. wp_postmeta, wp_options, wp_actionscheduler_actions, 로그 테이블, 통계 테이블이 상단에 뜨면 방향이 꽤 분명해집니다.

DB가 너무 클 때 먼저 줄여야 하는 것

글 리비전과 자동 저장본

뉴스형 사이트, 리뷰형 사이트, 수정이 잦은 블로그는 리비전이 눈덩이처럼 쌓입니다.

글 수보다 리비전 수가 훨씬 많아지는 경우도 드물지 않습니다.

만료된 transient

많은 플러그인이 트랜지언트를 저장하고, 제대로 지우지 않는 경우도 있습니다. 만료된 transient는 대표적인 정리 대상입니다.

WooCommerce 액션 스케줄러

주문 메일, 웹훅, 예약 작업, 재시도 작업이 계속 남으면 액션 스케줄러 테이블이 크게 불어납니다. 주문이 많은 사이트라면 꼭 확인해야 합니다.

autoload options

사이트는 평소에도 느린데 DB 용량은 그렇게 크지 않다면, 오히려 wp_options의 autoload가 문제일 가능성이 높습니다.

SELECT option_name,
       LENGTH(option_value) AS bytes
FROM wp_options
WHERE autoload = 'yes'
ORDER BY bytes DESC
LIMIT 30;

테이블 접두사가 wp_가 아니라면 그 접두사에 맞게 바꿔야 합니다. 여기서 이상하게 큰 옵션이 있으면 해당 플러그인이나 테마를 먼저 점검하는 편이 좋습니다.

SSH로 최적화하는 방법

DB가 큰 경우, phpMyAdmin이 자꾸 멈추는 경우, 반복 작업을 자동화하고 싶은 경우에는 SSH가 훨씬 편합니다. 워드프레스 운영자는 결국 이 방법을 알아두는 편이 좋습니다.

먼저 wp-config.php에서 DB 정보 확인

FTP나 파일매니저, SFTP로 사이트 루트에 있는 wp-config.php를 열면 DB 접속 정보가 있습니다.

define( 'DB_NAME', 'dbname' );
define( 'DB_USER', 'dbuser' );
define( 'DB_PASSWORD', 'dbpassword' );
define( 'DB_HOST', 'localhost' );

SSH에서 직접 MySQL에 접속할 때나 외부 클라이언트로 접속할 때 이 정보가 필요합니다.

WP-CLI로 점검과 최적화

SSH가 된다면 WP-CLI부터 쓰는 편이 좋습니다.

워드프레스 경로에서 실행하면 wp-config.php의 DB 정보를 자동으로 가져옵니다.

cd /home/계정/public_html
wp db check
wp db optimize
wp transient delete --expired
wp db size --tables

wp db check, wp db optimize, wp db repair는 내부적으로 mysqlcheck를 활용합니다. 그래서 브라우저보다 안정적이고 반복 작업에도 잘 맞습니다.

mysqlcheck 직접 사용

워드프레스를 거치지 않고 MySQL이나 MariaDB 레벨에서 바로 처리하고 싶다면 mysqlcheck도 많이 씁니다.

mysqlcheck -u DBUSER -p --check DBNAME
mysqlcheck -u DBUSER -p --optimize DBNAME
mysqlcheck -u DBUSER -p --analyze DBNAME

손상 의심 테이블이 MyISAM 계열이면 아래처럼 repair를 고려할 수 있습니다.

mysqlcheck -u DBUSER -p --repair DBNAME

주의
mysqlcheck는 작업 중 테이블을 잠글 수 있고, 큰 테이블에서는 시간이 꽤 걸릴 수 있습니다. 방문이 많은 시간대에는 바로 체감 장애로 이어질 수 있으니 작업 시간대를 꼭 잡고 진행하는 편이 좋습니다.

백업부터 받고 싶다면

wp db export ~/backup-before-optimize.sql
mysqldump -u DBUSER -p DBNAME > ~/backup-before-optimize.sql

DB가 큰 사이트는 phpMyAdmin export보다 SSH 덤프가 훨씬 안정적입니다. 호스팅에 따라 브라우저 export가 중간에 끊기는 경우가 흔합니다.

FTP나 SFTP만 가능할 때 할 수 있는 일

FTP만으로는 DB를 직접 optimize하지는 못합니다. 대신 아래 작업은 할 수 있습니다.

• wp-config.php에서 DB 정보 확인
• 오류를 유발하는 플러그인 폴더 이름 변경
• 백업 플러그인 덤프 파일, 로그 파일, 캐시 파일 정리
• 직접 설치형 phpMyAdmin 업로드
• WP_ALLOW_REPAIR 임시 활성화

워드프레스 자체 복구 모드

DB 손상 의심이 있고 관리자도 잘 안 열릴 때는 wp-config.php에 아래 한 줄을 잠깐 넣고 복구 페이지를 열 수 있습니다.

define( 'WP_ALLOW_REPAIR', true );

그 뒤 /wp-admin/maint/repair.php로 들어가 복구 또는 복구 및 최적화를 실행합니다. 끝나면 이 줄은 반드시 다시 지워야 합니다.

호스팅업체별 차이점도 꼭 알아야 합니다

블루호스트 계열

cPanel 접근이 가능한 플랜이라면 phpMyAdmin과 DB 관리가 비교적 익숙한 구조입니다. 공유호스팅에서는 phpMyAdmin으로 빠르게 확인하기 좋고, SSH가 되는 플랜이라면 WP-CLI나 mysqldump가 훨씬 편합니다. DB를 자주 만지는 편이라면 cPanel 접근성과 SSH 가능 여부부터 확인하는 것이 좋습니다.

카페24

카페24는 상품과 PHP 버전에 따라 phpMyAdmin 접근 방식이 다르고, 예전 웹어드민 방식 종료 이후에는 직접 phpMyAdmin을 설치하거나 외부 DB 클라이언트, SSH를 쓰는 흐름이 많습니다. 특히 워드프레스 VPS 가이드는 웹 기반 phpMyAdmin 대신 HeidiSQL, MySQL Workbench 같은 DB 클라이언트 사용을 안내하는 경우가 있습니다. 그래서 카페24에서는 “관리 콘솔에서 바로 optimize 한 번 누르면 끝”이라고 생각하면 실제와 다를 수 있습니다.

가비아

가비아는 phpMyAdmin 접근이 비교적 쉬운 편입니다. 관리 콘솔의 DB 서버 메뉴나 직접 URL로 들어가는 구조를 지원합니다. 다만 일부 가이드는 phpMyAdmin 파일 업로드가 20MB를 넘으면 SSH 작업을 권장하므로, 큰 DB는 브라우저보다 SSH가 낫습니다. 슬로우 쿼리 확인 메뉴나 DB 서버 메뉴가 잘 나뉘어 있어서 원인 추적도 비교적 편한 편입니다.

SiteGround

SiteGround는 cPanel이 아니라 Site Tools 구조를 주로 씁니다. MySQL, phpMyAdmin, SSH, 백업, 스테이징, 캐시 관리가 한 패널에서 정리돼 있는 편이라 DB 이전과 수동 관리가 비교적 쉽습니다. 공식 도움말도 DB가 큰 경우 SSH export/import를 권장하는 편이라 브라우저 방식보다 셸 쪽이 더 안정적입니다.

해외 매니지드 계열과 VPS 계열

Cloudways 같은 매니지드 클라우드 계열은 기본 phpMyAdmin 접근 외에도 WP-CLI, MySQL Workbench, 원격 DB, 서버 모니터링을 함께 쓰는 흐름이 많습니다. 반대로 VPS를 직접 운영하는 경우에는 패널보다 SSH와 my.cnf, PHP-FPM, OPcache, Redis 같은 서버 튜닝 비중이 더 커집니다.

cPanel에서 같이 보면 좋은 설정

1. MultiPHP Manager

워드프레스가 느린데 DB만 만지고 끝내면 아쉬운 경우가 많습니다.

클라우드웨이즈에서 PHP-FPM 완벽 구성하기 suphp, CGI 차이와 성능 비교

cPanel의 MultiPHP Manager에서는 도메인별 PHP 버전과 PHP-FPM 설정을 함께 확인할 수 있습니다.

워드프레스와 플러그인이 지원하는 범위 안에서 너무 낮은 PHP 버전을 오래 유지하면 체감 성능이 떨어질 수 있습니다.

2. PHP-FPM

같은 서버 사양에서도 PHP-FPM 사용 여부에 따라 응답이 달라지는 경우가 많습니다.

워드프레스 500 오류 원인 PHP-FPM 다운과 php-fpm.d 설정 복구

특히 동적 페이지가 많은 워드프레스는 PHP 핸들러와 FPM 설정이 중요합니다.

cPanel/WHM 계열이라면 PHP-FPM이 활성화되어 있는지 먼저 보는 편이 좋습니다.

3. OPcache

워드프레스는 PHP 파일을 많이 읽기 때문에 OPcache 효과가 큽니다.

WHM(EasyApache 4) PHP 8.4 OPcache + Redis Object Cache 구성 장애 복구후기

다만 cPanel 문서에서도 OPcache는 설치만으로 자동 최적화되지 않고 수동 설정이 필요하다고 안내합니다. 그래서 “OPcache가 깔려 있다”와 “제대로 쓰고 있다”는 다른 이야기입니다.

4. max_allowed_packet

백업 import, 큰 옵션값, 긴 문자열, 대형 쿼리, 일부 플러그인 설정 저장에서 자꾸 실패하면 이 값을 함께 봐야 합니다.

특히 cPanel WHM은 MySQL max_allowed_packet 값을 자동으로 산정하는 옵션도 제공합니다.

WHM에서 볼 설정과 시작값

루트 권한이 있는 VPS나 전용 서버라면 WHM과 my.cnf 조정까지 들어가야 체감 차이가 커집니다.

단, 아래 값은 정답이 아니라 시작점입니다. 같은 8GB 서버라도 웹서버, PHP, Redis, 메일, 모니터링, 백업까지 같이 돌리는지에 따라 적정값이 달라집니다.

가장 먼저 보는 핵심 변수

• innodb_buffer_pool_size : 가장 중요한 변수입니다.
• max_connections : 무작정 높이면 메모리만 늘고 오히려 불안정해질 수 있습니다.
• max_allowed_packet : 큰 import/export, BLOB, 긴 쿼리 이슈와 관련 있습니다.
• tmp_table_size, max_heap_table_size : 정렬과 임시 테이블 이슈를 볼 때 확인합니다.
• slow_query_log, long_query_time : 느린 원인을 찾을 때 꼭 필요합니다.

서버 성격	권장 시작점	설명
2GB 소형 VPS 웹+DB 같이 운영	innodb_buffer_pool_size 512M~768M max_connections 30~50 max_allowed_packet 64M	메모리가 적으므로 DB에 과도하게 몰아주면 웹서버와 PHP가 먼저 버겁습니다.
4GB 중형 VPS 워드프레스 1~3개	innodb_buffer_pool_size 1G~1.5G max_connections 50~100 tmp/max_heap 64M	일반적인 워드프레스 운영의 무난한 시작점입니다.
8GB 이상 VPS DB 비중 높은 사이트	innodb_buffer_pool_size 2G~4G max_connections 80~150 slow_query_log ON	WooCommerce나 게시판, 검색이 많은 사이트라면 슬로우 쿼리 로그를 꼭 켜는 편이 좋습니다.
전용 DB 서버	innodb_buffer_pool_size 50~75% 이상 검토	전용 DB 서버는 버퍼풀 비중을 더 높게 잡을 수 있지만, 웹+DB 혼합 서버와 기준이 다릅니다.

실무에서 제일 먼저 보는 값
웹과 DB를 한 서버에서 같이 돌리는 워드프레스라면, 저는 보통 innodb_buffer_pool_size와 PHP-FPM, OPcache, 슬로우 쿼리 로그부터 확인하는 편입니다.

여기만 바로잡아도 체감이 크게 좋아지는 경우가 많습니다.

예시 my.cnf 시작안

[mysqld]
max_connections=80
max_allowed_packet=64M
innodb_buffer_pool_size=1G
innodb_log_file_size=256M
tmp_table_size=64M
max_heap_table_size=64M
slow_query_log=1
long_query_time=1
log_output=FILE

이 값은 4GB 전후 혼합 서버 기준의 출발선에 가깝습니다. 실제로는 MariaDB/MySQL 버전, 트래픽, 사이트 수, PHP worker 수를 같이 보고 조정해야 합니다.

느린 원인을 찾는 쪽이 더 중요할 때도 많습니다

슬로우 쿼리 로그

DB 최적화는 결국 느린 쿼리를 찾아야 끝납니다.

슬로우 쿼리 로그를 켜고, 요약 도구로 어느 쿼리가 오래 걸리는지 확인해야 “무엇을 줄일지”가 보입니다. 플러그인 하나가 비효율적인 쿼리를 뿌리고 있으면 optimize를 여러 번 해도 체감은 거의 없습니다.

autoload options

워드프레스는 사이트 헬스 기준으로 autoloaded options가 너무 크면 경고를 띄웁니다.

작은 블로그인데도 관리자 체감이 느리다면 이쪽이 원인인 경우가 많습니다.

플러그인 로그와 통계 테이블

보안, 통계, 폼, 백업, SEO, 리다이렉트, 방문자 분석 플러그인은 오래 쌓이면 DB를 꽤 크게 만듭니다. 특히 삭제해도 테이블을 남기는 플러그인이 많아서 운영 연수가 길수록 누적이 심해집니다.

DB 최적화 외에 같이 해야 하는 워드프레스 최적화

캐시

워드프레스 공식 문서도 캐시를 가장 빠른 성능 개선 방법으로 봅니다. DB가 정리된 상태에서 페이지 캐시와 브라우저 캐시, 오브젝트 캐시가 같이 들어가야 체감이 확실히 올라갑니다.

오브젝트 캐시

멀티 서버 세션 저장소는 왜 Redis 많을까? Memcached 비교로 정리

Redis나 Memcached 같은 persistent object cache를 쓸 수 있는 환경이면 워드프레스 DB 부하를 크게 줄일 수 있습니다. 게시판, 쇼핑몰, 로그인 사용자 비중이 많은 사이트라면 더 체감이 큽니다.

PHP 버전

너무 오래된 PHP 버전은 속도와 보안 모두 불리합니다. 다만 무조건 최신으로 올리기보다 사용하는 테마와 플러그인 호환성을 먼저 보는 편이 좋습니다.

크론 정리

워드프레스 기본 WP-Cron이 과도하게 누적되면 DB와 PHP 모두에 부담을 줍니다.

• [IT 리뷰/블로그 SEO] - 워드프레스 서버 10년 간 쌓인 찌꺼기 데이터 정리 - 고어크론 예약 및 안쓰는 이미지 제거
• [IT 리뷰/블로그 SEO] - 알마리눅스 9.7 워드프레스 서버 느림 해결과 예약글 오류 정리

만약 방문이 많은 사이트라면 서버 크론으로 옮기는 쪽이 더 안정적입니다.

실전 점검 순서

1. 백업 파일부터 만듭니다.
2. DB 용량 상위 테이블을 확인합니다.
3. wp_options autoload, transient, 액션 스케줄러, 로그 테이블을 봅니다.
4. phpMyAdmin으로 check와 optimize를 가볍게 진행합니다.
5. 크거나 오류가 나는 DB는 SSH로 전환합니다.
6. wp db check, wp db optimize, mysqlcheck를 사용합니다.
7. WHM/cPanel이라면 PHP-FPM, OPcache, innodb_buffer_pool_size를 같이 봅니다.
8. 슬로우 쿼리 로그를 켜고 원인 플러그인을 찾습니다.

자주 묻는 질문

Q. phpMyAdmin에서 Optimize만 눌러도 빨라지나요

A. 일부는 좋아질 수 있지만, 근본 원인이 로그 테이블 누적이나 autoload 옵션 과다, 액션 스케줄러 폭증이면 효과가 오래 가지 않습니다. 큰 테이블이 왜 커졌는지 먼저 보는 편이 맞습니다.

Q. DB가 1GB가 넘으면 무조건 문제인가요

A. 사이트 종류에 따라 다릅니다. 쇼핑몰이나 커뮤니티는 1GB가 넘어도 이상하지 않습니다. 중요한 것은 총용량보다 어떤 테이블이 비정상적으로 커졌는지입니다.

Q. DB 최적화하다가 오류가 나면 제일 먼저 뭘 해야 하나요

A. 백업 상태를 확인하고, 브라우저 작업을 멈춘 뒤 SSH로 전환하는 편이 좋습니다. 동시에 MySQL/MariaDB 에러 로그와 디스크 여유공간도 같이 확인해야 합니다.

Q. 카페24나 가비아는 블루호스트처럼 바로 phpMyAdmin만 열면 끝인가요

A. 상품과 환경에 따라 다릅니다. 카페24는 직접 phpMyAdmin 설치나 외부 클라이언트, SSH를 더 자주 쓰는 구조가 있고, 가비아는 phpMyAdmin 접근은 쉬운 편이지만 큰 파일 import는 SSH가 더 안정적입니다.

Q. 워드프레스가 느린 게 꼭 DB 때문인가요

A. 아닙니다. PHP 버전, PHP-FPM, OPcache, 캐시, 외부 API, 이미지, DNS, 테마, 플러그인까지 전부 같이 봐야 합니다. 다만 오래 운영한 사이트는 DB부터 확인했을 때 바로 답이 나오는 경우가 많습니다.

워드프레스 DB 최적화는 단순히 phpMyAdmin에서 “최적화” 버튼을 한 번 누르는 작업으로 끝나지 않습니다. 오래된 사이트일수록 무엇이 쌓였는지 보고, 왜 느린지 잡고, phpMyAdmin으로 될 일과 SSH로 해야 할 일을 나누는 것이 훨씬 중요합니다.

공유호스팅이라면 phpMyAdmin과 간단한 check/optimize부터 시작하고, DB가 크거나 오류가 나면 SSH와 WP-CLI, mysqlcheck로 넘어가는 쪽이 안정적입니다.

VPS나 전용 서버라면 거기서 한 단계 더 들어가 WHM의 PHP-FPM, OPcache, MySQL/MariaDB 메모리 설정, 슬로우 쿼리 로그까지 같이 봐야 실제 체감이 좋아집니다. 제 기준에서는 DB 최적화는 따로 떼어 놓고 볼 일이 아니라, 워드프레스 전체 최적화의 출발점에 더 가깝습니다.