Database Performance Tuning Guide — คู่มือปรับแต่งประสิทธิภาพฐานข้อมูล

Categories

ประสิทธิภาพของฐานข้อมูลเป็นปัจจัยสำคัญที่ส่งผลโดยตรงต่อความเร็วของแอปพลิเคชัน เมื่อระบบเติบโตขึ้น Query ที่เคยทำงานเร็วอาจกลายเป็นคอขวด การ Tune ฐานข้อมูลอย่างถูกวิธีจะช่วยให้ระบบรองรับผู้ใช้งานได้มากขึ้นโดยไม่ต้องเพิ่มฮาร์ดแวร์ทันที

บทความนี้รวบรวมเทคนิค Performance Tuning สำหรับ MySQL, PostgreSQL และ MongoDB ตั้งแต่การปรับค่า Configuration, การออกแบบ Index, การวิเคราะห์ Slow Query ไปจนถึงการ Optimize ในระดับ OS พร้อมตัวอย่างคำสั่งที่ใช้ได้จริง

หลักการพื้นฐานของ Database Performance Tuning

ก่อนเริ่ม Tune สิ่งสำคัญคือต้องวัดผลก่อนเสมอ (Measure First, Tune Later) การปรับค่าโดยไม่รู้ว่าปัญหาอยู่ตรงไหนอาจทำให้เสียเวลาโดยเปล่าประโยชน์ ขั้นตอนที่แนะนำคือ ระบุปัญหาด้วย Monitoring → วิเคราะห์ Slow Query → ตรวจสอบ Execution Plan → ปรับ Index → ปรับ Configuration → วัดผลอีกครั้ง

ทรัพยากรหลักที่ส่งผลต่อประสิทธิภาพฐานข้อมูล ได้แก่ CPU สำหรับประมวลผล Query, RAM สำหรับ Buffer/Cache, Disk I/O สำหรับอ่านเขียนข้อมูล และ Network สำหรับรับส่งข้อมูลกับ Application ปัญหาส่วนใหญ่เกิดจาก Disk I/O ที่ช้า หรือ Query ที่ไม่ได้ใช้ Index

วิเคราะห์ Slow Query

MySQL Slow Query Log

เปิด Slow Query Log เพื่อบันทึก Query ที่ใช้เวลานานเกินกำหนด แล้ววิเคราะห์ด้วยเครื่องมือ mysqldumpslow หรือ pt-query-digest

# เปิด Slow Query Log ใน my.cnf
[mysqld]
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1
log_queries_not_using_indexes = 1

# เปิดแบบ runtime (ไม่ต้อง restart)
SET GLOBAL slow_query_log = 1;
SET GLOBAL long_query_time = 1;
SET GLOBAL log_queries_not_using_indexes = 1;

# วิเคราะห์ด้วย mysqldumpslow
mysqldumpslow -t 10 -s t /var/log/mysql/slow.log

# วิเคราะห์ด้วย pt-query-digest (แนะนำ)
pt-query-digest /var/log/mysql/slow.log --limit=20

PostgreSQL Slow Query

PostgreSQL ใช้ pg_stat_statements เป็น Extension สำหรับติดตาม Query ที่ใช้ทรัพยากรมาก

# เปิด pg_stat_statements ใน postgresql.conf
shared_preload_libraries = 'pg_stat_statements'
pg_stat_statements.track = all

# Log slow queries
log_min_duration_statement = 1000  # log query ที่ใช้เวลาเกิน 1 วินาที

# สร้าง extension
CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

# ดู Top 10 slow queries
SELECT query,
       calls,
       round(total_exec_time::numeric, 2) AS total_ms,
       round(mean_exec_time::numeric, 2) AS avg_ms,
       rows
FROM pg_stat_statements
ORDER BY mean_exec_time DESC
LIMIT 10;

MongoDB Slow Query

MongoDB มี Database Profiler สำหรับบันทึก Operation ที่ช้า

# เปิด Profiler (level 1 = log slow operations)
db.setProfilingLevel(1, { slowms: 100 })

# ดู slow operations
db.system.profile.find().sort({ ts: -1 }).limit(10).pretty()

# ดูเฉพาะ query ที่ช้าที่สุด
db.system.profile.find({
  op: "query",
  millis: { $gt: 500 }
}).sort({ millis: -1 }).limit(5)

# ดู current operations ที่กำลังทำงานอยู่
db.currentOp({ "secs_running": { "$gt": 5 } })

การใช้ EXPLAIN วิเคราะห์ Execution Plan

EXPLAIN เป็นเครื่องมือสำคัญที่สุดสำหรับ Performance Tuning ช่วยให้เห็นว่าฐานข้อมูลเลือกใช้วิธีใดในการประมวลผล Query รวมถึงใช้ Index หรือไม่

MySQL EXPLAIN

# ดู Execution Plan
EXPLAIN SELECT * FROM orders WHERE customer_id = 123 AND status = 'pending';

# ดูแบบละเอียด (MySQL 8.0+)
EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 123;

# ดู format JSON (ข้อมูลละเอียดกว่า)
EXPLAIN FORMAT=JSON SELECT * FROM orders WHERE customer_id = 123;

# สิ่งที่ต้องดู:
# - type: ALL = Full Table Scan (แย่), ref/range = ใช้ Index (ดี)
# - key: Index ที่ถูกใช้ (NULL = ไม่ใช้ Index)
# - rows: จำนวน rows ที่ต้องสแกน (ยิ่งน้อยยิ่งดี)
# - Extra: Using filesort, Using temporary = ควรปรับปรุง

PostgreSQL EXPLAIN

# ดู Execution Plan
EXPLAIN SELECT * FROM orders WHERE customer_id = 123 AND status = 'pending';

# ดูแบบ ANALYZE (รัน query จริง แล้วแสดงเวลาจริง)
EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT)
SELECT * FROM orders WHERE customer_id = 123;

# สิ่งที่ต้องดู:
# - Seq Scan = Full Table Scan (ควรหลีกเลี่ยงกับ table ใหญ่)
# - Index Scan / Index Only Scan = ใช้ Index (ดี)
# - actual time = เวลาจริงที่ใช้
# - Buffers: shared hit = อ่านจาก cache, shared read = อ่านจาก disk

การออกแบบ Index ที่มีประสิทธิภาพ

Index เป็นหัวใจของ Performance Tuning การมี Index ที่เหมาะสมช่วยลดเวลา Query จากหลักวินาทีเหลือหลักมิลลิวินาที แต่ Index ที่มากเกินไปก็ทำให้การ INSERT/UPDATE ช้าลง

หลักการเลือก Index

  • สร้าง Index บนคอลัมน์ที่ใช้ใน WHERE, JOIN, ORDER BY บ่อย ๆ
  • ใช้ Composite Index เมื่อ Query มีหลายเงื่อนไข โดยเรียงคอลัมน์ตามลำดับ Selectivity สูงไปต่ำ
  • หลีกเลี่ยง Index บนคอลัมน์ที่มี Cardinality ต่ำ เช่น status ที่มีแค่ 3-4 ค่า (ยกเว้นใช้เป็น Composite Index)
  • ใช้ Covering Index (Index ที่ครอบคลุมทุกคอลัมน์ที่ Query ต้องการ) เพื่อหลีกเลี่ยงการอ่านข้อมูลจาก Table
  • ตรวจสอบ Index ที่ไม่ได้ใช้และลบออก เพราะ Index ที่ไม่ได้ใช้จะเปลืองพื้นที่และทำให้ Write ช้าลง

ตัวอย่าง Index ที่มีประสิทธิภาพ

# MySQL — Composite Index
# ถ้า Query มักจะเป็น: WHERE customer_id = ? AND status = ? ORDER BY created_at
CREATE INDEX idx_customer_status_date
ON orders (customer_id, status, created_at);

# Covering Index — ไม่ต้องอ่าน Table เลย
CREATE INDEX idx_orders_covering
ON orders (customer_id, status, created_at, total_amount);

# Partial Index (PostgreSQL) — Index เฉพาะข้อมูลที่ต้องการ
CREATE INDEX idx_orders_pending
ON orders (customer_id, created_at)
WHERE status = 'pending';

# ตรวจสอบ Index ที่ไม่ได้ใช้ (MySQL)
SELECT s.table_name, s.index_name, s.seq_in_index, s.column_name
FROM information_schema.statistics s
LEFT JOIN sys.schema_unused_indexes u
  ON s.table_schema = u.object_schema
  AND s.table_name = u.object_name
  AND s.index_name = u.index_name
WHERE u.index_name IS NOT NULL;

# ตรวจสอบ Index ที่ไม่ได้ใช้ (PostgreSQL)
SELECT schemaname, relname, indexrelname, idx_scan, idx_tup_read
FROM pg_stat_user_indexes
WHERE idx_scan = 0
ORDER BY pg_relation_size(indexrelid) DESC;

MongoDB Index

# สร้าง Compound Index
db.orders.createIndex({ customer_id: 1, status: 1, created_at: -1 })

# Covered Query — ไม่ต้องอ่าน Document จริง
db.orders.find(
  { customer_id: 123, status: "pending" },
  { _id: 0, customer_id: 1, status: 1, created_at: 1 }
).hint({ customer_id: 1, status: 1, created_at: -1 })

# ตรวจสอบ Index ที่ไม่ได้ใช้
db.orders.aggregate([{ $indexStats: {} }])

# วิเคราะห์ Query ด้วย explain
db.orders.find({ customer_id: 123 }).explain("executionStats")
# ดู: totalDocsExamined vs nReturned (ยิ่งใกล้กันยิ่งดี)

ปรับ Configuration สำหรับ MySQL

การปรับค่า Configuration ของ MySQL ให้เหมาะสมกับทรัพยากรเซิร์ฟเวอร์เป็นขั้นตอนที่สำคัญ ค่าหลัก ๆ ที่ควรปรับมีดังนี้

# /etc/mysql/my.cnf — ค่าที่ควรปรับสำหรับ InnoDB

[mysqld]
# === Buffer Pool ===
# กำหนดให้ 70-80% ของ RAM ทั้งหมด (สำหรับ dedicated DB server)
innodb_buffer_pool_size = 6G          # เซิร์ฟเวอร์ RAM 8 GB
innodb_buffer_pool_instances = 4       # แยก pool เป็น 4 ส่วน (ลด lock contention)

# === Log File ===
innodb_log_file_size = 1G             # ใหญ่ขึ้น = write performance ดีขึ้น
innodb_log_buffer_size = 64M
innodb_flush_log_at_trx_commit = 1    # 1 = safe, 2 = faster but less safe

# === I/O ===
innodb_io_capacity = 2000             # SSD ใช้ 2000-10000
innodb_io_capacity_max = 4000
innodb_read_io_threads = 8
innodb_write_io_threads = 8

# === Connection ===
max_connections = 200
thread_cache_size = 50
table_open_cache = 4000

# === Query Cache (MySQL 5.7 เท่านั้น, 8.0 ถูกลบแล้ว) ===
# query_cache_type = 0                # ปิดถ้าใช้ MySQL 5.7

# === Temp Table ===
tmp_table_size = 256M
max_heap_table_size = 256M

# === Sort / Join ===
sort_buffer_size = 4M
join_buffer_size = 4M
read_rnd_buffer_size = 4M

ตรวจสอบประสิทธิภาพของ Buffer Pool ด้วยคำสั่งต่อไปนี้ ค่า Hit Rate ควรอยู่เหนือ 99%

# ดู Buffer Pool Hit Rate
SHOW STATUS LIKE 'Innodb_buffer_pool_read%';

# คำนวณ Hit Rate
SELECT
  (1 - (Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests)) * 100
  AS buffer_pool_hit_rate
FROM (
  SELECT
    VARIABLE_VALUE AS Innodb_buffer_pool_reads
  FROM performance_schema.global_status
  WHERE VARIABLE_NAME = 'Innodb_buffer_pool_reads'
) a,
(
  SELECT
    VARIABLE_VALUE AS Innodb_buffer_pool_read_requests
  FROM performance_schema.global_status
  WHERE VARIABLE_NAME = 'Innodb_buffer_pool_read_requests'
) b;

# ดู Connection usage
SHOW STATUS LIKE 'Threads_%';
SHOW STATUS LIKE 'Max_used_connections';

ปรับ Configuration สำหรับ PostgreSQL

PostgreSQL มี Memory Model ที่แตกต่างจาก MySQL ค่าสำคัญที่ควรปรับมีดังนี้

# postgresql.conf — ค่าที่ควรปรับ

# === Memory ===
shared_buffers = 2GB                  # 25% ของ RAM (เซิร์ฟเวอร์ 8 GB)
effective_cache_size = 6GB            # 75% ของ RAM
work_mem = 64MB                       # ต่อ operation (ระวังถ้า concurrent สูง)
maintenance_work_mem = 512MB          # สำหรับ VACUUM, CREATE INDEX

# === WAL ===
wal_buffers = 64MB
checkpoint_completion_target = 0.9
max_wal_size = 2GB
min_wal_size = 512MB

# === Planner ===
random_page_cost = 1.1                # SSD ใช้ 1.1 (default 4.0 สำหรับ HDD)
effective_io_concurrency = 200        # SSD ใช้ 200

# === Connection ===
max_connections = 200

# === Autovacuum (สำคัญมากสำหรับ PostgreSQL) ===
autovacuum = on
autovacuum_max_workers = 4
autovacuum_naptime = 30s
autovacuum_vacuum_scale_factor = 0.05
autovacuum_analyze_scale_factor = 0.02

# === Parallel Query (PostgreSQL 10+) ===
max_parallel_workers_per_gather = 4
max_parallel_workers = 8
max_worker_processes = 10

ปรับ Configuration สำหรับ MongoDB

MongoDB ใช้ WiredTiger เป็น Storage Engine หลัก ค่าที่สำคัญคือ Cache Size และ Compression

# /etc/mongod.conf

storage:
  engine: wiredTiger
  wiredTiger:
    engineConfig:
      # cache = 50% ของ RAM - 1 GB (default)
      # ปรับตามความเหมาะสม
      cacheSizeGB: 4
    collectionConfig:
      blockCompressor: snappy    # snappy (เร็ว) หรือ zstd (บีบอัดดีกว่า)
    indexConfig:
      prefixCompression: true

operationProfiling:
  slowOpThresholdMs: 100
  mode: slowOp

# ตรวจสอบ Cache Usage
db.serverStatus().wiredTiger.cache

# ค่าที่ควรดู:
# "bytes currently in the cache" — ควรไม่เกิน cacheSizeGB
# "pages read into cache" — ถ้าสูง = cache ไม่พอ
# "maximum bytes configured" — cache ที่ตั้งไว้

Query Optimization Techniques

นอกจากการสร้าง Index แล้ว ยังมีเทคนิคอื่น ๆ ที่ช่วยให้ Query เร็วขึ้นอย่างมาก

หลีกเลี่ยง SELECT *

การใช้ SELECT * ทำให้ฐานข้อมูลต้องอ่านข้อมูลทุกคอลัมน์ รวมถึง BLOB หรือ TEXT ที่อาจมีขนาดใหญ่ ควร SELECT เฉพาะคอลัมน์ที่ต้องการเท่านั้น

# ❌ ช้า — อ่านทุกคอลัมน์
SELECT * FROM orders WHERE customer_id = 123;

# ✅ เร็วกว่า — อ่านเฉพาะที่ต้องการ
SELECT id, status, total_amount, created_at
FROM orders WHERE customer_id = 123;

ใช้ Pagination อย่างถูกวิธี

OFFSET ที่มีค่าสูงทำให้ฐานข้อมูลต้องสแกนข้อมูลจำนวนมากก่อนจะข้ามไป ควรใช้ Keyset Pagination แทน

# ❌ ช้าเมื่อ OFFSET สูง (ต้องสแกน 100,000 rows แล้วข้าม)
SELECT * FROM orders ORDER BY id LIMIT 20 OFFSET 100000;

# ✅ Keyset Pagination — เร็วเสมอไม่ว่าหน้าที่เท่าไหร่
SELECT * FROM orders WHERE id > 100000 ORDER BY id LIMIT 20;

Batch Operations

การ INSERT หรือ UPDATE ทีละแถวจำนวนมากทำให้เกิด Overhead จากการเปิดปิด Transaction ซ้ำ ๆ ควรใช้ Batch แทน

# ❌ ช้า — INSERT ทีละแถว
INSERT INTO logs (message, level) VALUES ('msg1', 'info');
INSERT INTO logs (message, level) VALUES ('msg2', 'warn');
INSERT INTO logs (message, level) VALUES ('msg3', 'error');

# ✅ เร็วกว่ามาก — Batch INSERT
INSERT INTO logs (message, level) VALUES
  ('msg1', 'info'),
  ('msg2', 'warn'),
  ('msg3', 'error');

# ✅ Batch UPDATE ด้วย CASE
UPDATE orders
SET status = CASE
  WHEN id = 1 THEN 'shipped'
  WHEN id = 2 THEN 'delivered'
  WHEN id = 3 THEN 'cancelled'
END
WHERE id IN (1, 2, 3);

OS Level Tuning

การปรับค่าระดับ OS ช่วยให้ฐานข้อมูลใช้ทรัพยากรของเซิร์ฟเวอร์ได้อย่างเต็มประสิทธิภาพ

# /etc/sysctl.conf — ค่าที่ควรปรับสำหรับ Database Server

# Shared Memory (สำหรับ PostgreSQL)
kernel.shmmax = 8589934592
kernel.shmall = 2097152

# Virtual Memory
vm.swappiness = 1                    # ลดการ swap (0 = ไม่ swap เลย อาจ OOM)
vm.dirty_ratio = 15
vm.dirty_background_ratio = 5
vm.overcommit_memory = 2             # ป้องกัน OOM killer

# Network (สำหรับรองรับ connection จำนวนมาก)
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535

# File Descriptors
fs.file-max = 2097152

# Apply
sysctl -p
# I/O Scheduler — ใช้ noop หรือ none สำหรับ SSD
echo "none" > /sys/block/sda/queue/scheduler

# ตรวจสอบ scheduler ปัจจุบัน
cat /sys/block/sda/queue/scheduler

# Disable Transparent Huge Pages (THP) — สำคัญสำหรับ MongoDB และ Redis
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

# เพิ่ม limits สำหรับ user ที่รัน database
# /etc/security/limits.conf
# mysql    soft    nofile    65535
# mysql    hard    nofile    65535
# postgres soft    nofile    65535
# postgres hard    nofile    65535

Connection Pooling

การเปิด Connection ใหม่ทุกครั้งที่มี Request เข้ามาเปลืองทรัพยากรมาก การใช้ Connection Pool ช่วยลด Overhead ได้อย่างมาก

PgBouncer สำหรับ PostgreSQL

# /etc/pgbouncer/pgbouncer.ini

[databases]
mydb = host=127.0.0.1 port=5432 dbname=mydb

[pgbouncer]
listen_addr = 0.0.0.0
listen_port = 6432
auth_type = md5
auth_file = /etc/pgbouncer/userlist.txt

# Pool Mode
pool_mode = transaction    # transaction = แนะนำสำหรับ web app
                           # session = เหมือน direct connection

# Pool Size
default_pool_size = 25
max_client_conn = 1000
max_db_connections = 100

# Timeout
server_idle_timeout = 300
client_idle_timeout = 600

# ตรวจสอบสถานะ
psql -h 127.0.0.1 -p 6432 -U admin pgbouncer -c "SHOW POOLS;"
psql -h 127.0.0.1 -p 6432 -U admin pgbouncer -c "SHOW STATS;"

ProxySQL สำหรับ MySQL

# ProxySQL ตั้งค่าผ่าน Admin Interface
mysql -u admin -p -h 127.0.0.1 -P 6032

# เพิ่ม Backend Server
INSERT INTO mysql_servers (hostgroup_id, hostname, port, max_connections)
VALUES (1, '10.0.1.1', 3306, 100);

# เพิ่ม User
INSERT INTO mysql_users (username, password, default_hostgroup)
VALUES ('app_user', 'password', 1);

# Query Rules — แยก Read/Write
INSERT INTO mysql_query_rules (rule_id, active, match_pattern, destination_hostgroup)
VALUES (1, 1, '^SELECT', 2);  # SELECT ไป hostgroup 2 (read replicas)

# Load & Save
LOAD MYSQL SERVERS TO RUNTIME;
LOAD MYSQL USERS TO RUNTIME;
LOAD MYSQL QUERY RULES TO RUNTIME;
SAVE MYSQL SERVERS TO DISK;
SAVE MYSQL USERS TO DISK;

Performance Monitoring

การ Monitor อย่างต่อเนื่องช่วยตรวจจับปัญหาก่อนที่จะกระทบผู้ใช้งาน ค่าสำคัญที่ควรติดตามมีดังนี้

# MySQL — ค่า Status ที่ควร Monitor
SHOW GLOBAL STATUS LIKE 'Threads_running';        # Active queries
SHOW GLOBAL STATUS LIKE 'Slow_queries';            # สะสม slow query
SHOW GLOBAL STATUS LIKE 'Innodb_row_lock_waits';   # Row lock contention
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_wait_free';  # Buffer pool pressure
SHOW GLOBAL STATUS LIKE 'Created_tmp_disk_tables'; # Temp table บน disk

# PostgreSQL — ค่าที่ควร Monitor
SELECT * FROM pg_stat_activity WHERE state = 'active';  # Active queries
SELECT * FROM pg_stat_database WHERE datname = 'mydb';   # Database stats
SELECT * FROM pg_stat_bgwriter;                          # Background writer

# ดู Table ที่ต้อง VACUUM
SELECT schemaname, relname, n_dead_tup, last_autovacuum
FROM pg_stat_user_tables
WHERE n_dead_tup > 10000
ORDER BY n_dead_tup DESC;

# MongoDB — ค่าที่ควร Monitor
db.serverStatus().opcounters     # จำนวน operation แต่ละประเภท
db.serverStatus().connections     # Connection usage
db.serverStatus().globalLock      # Lock statistics
db.serverStatus().wiredTiger.cache  # Cache performance

ข้อควรระวังในการ Performance Tuning

  • วัดผลก่อนและหลังเสมอ — อย่าปรับค่าโดยไม่มี Baseline และ Benchmark เปรียบเทียบ ใช้เครื่องมืออย่าง sysbench, pgbench หรือ YCSB
  • ปรับทีละค่า — อย่าปรับหลายค่าพร้อมกัน เพราะจะไม่รู้ว่าค่าไหนส่งผล ควรปรับทีละค่าแล้ววัดผล
  • ระวัง Over-indexing — Index ที่มากเกินไปทำให้ INSERT/UPDATE/DELETE ช้าลง และใช้พื้นที่ดิสก์เพิ่ม
  • ทดสอบด้วย Production-like Data — Query ที่เร็วกับข้อมูล 1,000 rows อาจช้ามากกับ 10 ล้าน rows ควรทดสอบด้วยข้อมูลขนาดใกล้เคียง Production
  • ดูแล Autovacuum — PostgreSQL ต้อง VACUUM เป็นประจำเพื่อคืนพื้นที่และอัพเดท Statistics ถ้า Autovacuum ช้าเกินไป Query Planner จะตัดสินใจผิดพลาด
  • อย่าปิด Swap ทั้งหมด — ตั้ง swappiness = 1 แทนที่จะปิดเลย เพื่อป้องกัน OOM Killer ฆ่า Database Process

สรุป

การ Tune ประสิทธิภาพฐานข้อมูลเป็นกระบวนการที่ต้องทำอย่างเป็นระบบ เริ่มจากการวัดผลด้วย Monitoring เพื่อระบุคอขวด จากนั้นวิเคราะห์ Slow Query ด้วย EXPLAIN ปรับ Index ให้เหมาะสม ปรับ Configuration ให้สอดคล้องกับทรัพยากรเซิร์ฟเวอร์ และ Optimize Query ให้มีประสิทธิภาพ

สิ่งสำคัญคืออย่าลืมว่าการ Tuning ไม่ใช่สิ่งที่ทำครั้งเดียวแล้วจบ เมื่อข้อมูลเพิ่มขึ้นและรูปแบบการใช้งานเปลี่ยนไป ค่า Configuration และ Index ที่เคยเหมาะสมอาจไม่เพียงพอ ควร Monitor อย่างต่อเนื่องและปรับค่าตามสถานการณ์จริง

แนะนำบริการ DE

การ Tune ฐานข้อมูลให้ได้ประสิทธิภาพสูงสุดต้องอาศัยเซิร์ฟเวอร์ที่ปรับแต่งได้อย่างอิสระ Cloud VPS ของ DE ให้ root access เต็มรูปแบบ สามารถปรับค่า my.cnf, postgresql.conf, sysctl.conf และติดตั้ง Connection Pooler ได้ตามต้องการ พร้อม SSD storage ที่ช่วยให้ I/O performance ดียิ่งขึ้น

สำหรับผู้ที่ต้องการโฮสต์เว็บไซต์ที่ใช้ฐานข้อมูลอย่าง WordPress หรือ WooCommerce โดยไม่ต้องจัดการเซิร์ฟเวอร์เอง Cloud Hosting ของ DE มาพร้อมฐานข้อมูลที่ถูก Optimize มาแล้วสำหรับงานเว็บไซต์ ช่วยให้เว็บโหลดเร็วโดยไม่ต้องตั้งค่าเอง