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

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

ทำความเข้าใจ EXPLAIN และ EXPLAIN ANALYZE

ก่อนจะปรับแต่ง Query ได้ ต้องรู้ก่อนว่า PostgreSQL ประมวลผลคำสั่ง SQL อย่างไร เครื่องมือหลักที่ใช้คือ EXPLAIN ซึ่งแสดงแผนการทำงาน (Query Plan) ที่ Planner เลือกใช้

EXPLAIN พื้นฐาน

-- แสดง Query Plan โดยไม่รันจริง
EXPLAIN SELECT * FROM orders WHERE customer_id = 100;

-- แสดง Query Plan พร้อมรันจริง (ได้เวลาจริง)
EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 100;

-- แสดงข้อมูลละเอียด (buffers, timing)
EXPLAIN (ANALYZE, BUFFERS, TIMING) SELECT * FROM orders WHERE customer_id = 100;

-- แสดงผลในรูปแบบ JSON (อ่านง่ายด้วยเครื่องมือ)
EXPLAIN (ANALYZE, FORMAT JSON) SELECT * FROM orders WHERE customer_id = 100;

อ่าน Query Plan

ผลลัพธ์จาก EXPLAIN จะแสดงข้อมูลสำคัญหลายอย่าง

Seq Scan on orders  (cost=0.00..1520.00 rows=50 width=120) (actual time=0.015..12.345 rows=48 loops=1)
  Filter: (customer_id = 100)
  Rows Removed by Filter: 99952
Planning Time: 0.085 ms
Execution Time: 12.400 ms

ความหมายของแต่ละส่วน

• Seq Scan — สแกนทั้งตาราง (ช้ากว่า Index Scan)
• cost=0.00..1520.00 — ค่าประมาณต้นทุน (startup cost..total cost)
• rows=50 — จำนวนแถวที่ Planner คาดว่าจะได้
• actual time=0.015..12.345 — เวลาจริงที่ใช้ (เฉพาะ EXPLAIN ANALYZE)
• rows=48 — จำนวนแถวจริงที่ได้
• Rows Removed by Filter: 99952 — แถวที่ถูกกรองออก (ยิ่งมากยิ่งสิ้นเปลือง)

ประเภท Scan ที่พบบ่อย

Scan Type	คำอธิบาย	เมื่อไหร่ที่ใช้
Seq Scan	อ่านทุกแถวในตาราง	ไม่มี Index หรือต้องอ่านข้อมูลจำนวนมาก
Index Scan	ใช้ Index ค้นหาแล้วกลับไปอ่านข้อมูลในตาราง	มี Index และเลือกข้อมูลจำนวนน้อย
Index Only Scan	ใช้ข้อมูลจาก Index อย่างเดียว ไม่ต้องอ่านตาราง	คอลัมน์ที่ต้องการอยู่ใน Index ทั้งหมด
Bitmap Index Scan	ใช้ Index สร้าง Bitmap แล้วอ่านตารางเป็น Block	เลือกข้อมูลจำนวนปานกลาง

Index: หัวใจของการปรับแต่งประสิทธิภาพ

Index เป็นโครงสร้างข้อมูลที่ช่วยให้ PostgreSQL ค้นหาข้อมูลได้เร็วขึ้นโดยไม่ต้องสแกนทั้งตาราง แต่การสร้าง Index มากเกินไปก็มีต้นทุน เพราะทุกครั้งที่ INSERT, UPDATE หรือ DELETE ข้อมูล PostgreSQL ต้องอัพเดต Index ด้วย

ประเภท Index ใน PostgreSQL

ประเภท	ใช้เมื่อ	ตัวอย่าง
B-tree (ค่าเริ่มต้น)	เปรียบเทียบ =, <, >, BETWEEN, ORDER BY	CREATE INDEX idx ON t(col)
Hash	เปรียบเทียบ = เท่านั้น	CREATE INDEX idx ON t USING hash(col)
GIN	ค้นหาใน Array, JSONB, Full-text Search	CREATE INDEX idx ON t USING gin(col)
GiST	ข้อมูล Geometric, Range, Full-text	CREATE INDEX idx ON t USING gist(col)
BRIN	ตารางขนาดใหญ่ที่ข้อมูลเรียงตามลำดับ	CREATE INDEX idx ON t USING brin(col)

สร้าง Index ที่มีประสิทธิภาพ

-- B-tree Index พื้นฐาน
CREATE INDEX idx_orders_customer ON orders(customer_id);

-- Composite Index (หลายคอลัมน์ — ลำดับสำคัญ!)
CREATE INDEX idx_orders_status_date ON orders(status, created_at);

-- Partial Index (เฉพาะข้อมูลที่ตรงเงื่อนไข)
CREATE INDEX idx_orders_active ON orders(customer_id) WHERE status = 'active';

-- Expression Index
CREATE INDEX idx_users_email_lower ON users(LOWER(email));

-- Covering Index (รวมคอลัมน์เพิ่มเพื่อ Index Only Scan)
CREATE INDEX idx_orders_covering ON orders(customer_id) INCLUDE (total, status);

-- สร้าง Index โดยไม่ล็อกตาราง (สำคัญสำหรับ Production)
CREATE INDEX CONCURRENTLY idx_orders_amount ON orders(amount);

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

• คอลัมน์ใน WHERE — สร้าง Index บนคอลัมน์ที่ใช้กรองข้อมูลบ่อย
• คอลัมน์ใน JOIN — สร้าง Index บน Foreign Key และคอลัมน์ที่ใช้ JOIN
• คอลัมน์ใน ORDER BY — สร้าง Index ที่เรียงลำดับตรงกับ ORDER BY
• ลำดับใน Composite Index — ใส่คอลัมน์ที่มี Selectivity สูง (มีค่าหลากหลาย) ไว้ก่อน
• อย่าสร้างซ้ำซ้อน — Index บน (a, b) ครอบคลุม Query ที่ค้นหา a อยู่แล้ว

เทคนิคการเขียน SQL ให้มีประสิทธิภาพ

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

-- ไม่แนะนำ: ดึงทุกคอลัมน์
SELECT * FROM orders WHERE customer_id = 100;

-- แนะนำ: ระบุเฉพาะคอลัมน์ที่ต้องการ
SELECT order_id, total, status FROM orders WHERE customer_id = 100;

การระบุคอลัมน์ช่วยให้ PostgreSQL ใช้ Index Only Scan ได้ (ถ้าคอลัมน์ทั้งหมดอยู่ใน Index) และลดปริมาณข้อมูลที่ต้องส่งไปยัง Client

ใช้ WHERE แทน HAVING สำหรับกรองข้อมูลทั่วไป

-- ไม่แนะนำ: กรองด้วย HAVING ก่อน Aggregate
SELECT customer_id, SUM(total)
FROM orders
GROUP BY customer_id
HAVING customer_id IN (100, 200, 300);

-- แนะนำ: กรองด้วย WHERE ก่อน Aggregate
SELECT customer_id, SUM(total)
FROM orders
WHERE customer_id IN (100, 200, 300)
GROUP BY customer_id;

หลีกเลี่ยง Function บนคอลัมน์ใน WHERE

-- ไม่แนะนำ: ใช้ Function ครอบคอลัมน์ (Index ใช้ไม่ได้)
SELECT * FROM users WHERE UPPER(email) = '[email protected]';

-- แนะนำ: สร้าง Expression Index แล้วใช้ตรงกัน
CREATE INDEX idx_users_email_upper ON users(UPPER(email));
SELECT * FROM users WHERE UPPER(email) = '[email protected]';

-- หรือใช้ CITEXT type ถ้าต้องการเปรียบเทียบแบบ Case-insensitive

ใช้ EXISTS แทน IN สำหรับ Subquery

-- IN กับ Subquery (อาจช้าถ้า Subquery ใหญ่)
SELECT * FROM customers
WHERE id IN (SELECT customer_id FROM orders WHERE total > 1000);

-- EXISTS (หยุดเมื่อเจอแถวแรก — มักเร็วกว่า)
SELECT * FROM customers c
WHERE EXISTS (SELECT 1 FROM orders o WHERE o.customer_id = c.id AND o.total > 1000);

ใช้ JOIN อย่างมีประสิทธิภาพ

-- ตรวจสอบว่าคอลัมน์ที่ JOIN มี Index
EXPLAIN ANALYZE
SELECT o.order_id, c.name
FROM orders o
JOIN customers c ON o.customer_id = c.id
WHERE o.status = 'pending';

-- ลำดับ JOIN ไม่สำคัญ — Planner จะเลือกลำดับที่ดีที่สุดเอง
-- แต่ถ้า join_collapse_limit น้อยกว่าจำนวนตาราง อาจต้องจัดลำดับเอง

Pagination ที่ถูกต้อง

การทำ Pagination ด้วย OFFSET เป็นวิธีที่พบบ่อยแต่มีปัญหาด้านประสิทธิภาพเมื่อ Offset สูง เพราะ PostgreSQL ต้องอ่านและข้ามแถวทั้งหมดก่อน Offset

-- วิธีที่ช้า: OFFSET สูง
SELECT * FROM products ORDER BY id LIMIT 20 OFFSET 100000;
-- PostgreSQL ต้องอ่าน 100,020 แถว แล้วทิ้ง 100,000 แถว

-- วิธีที่เร็ว: Keyset Pagination (ใช้ค่าสุดท้ายของหน้าก่อน)
SELECT * FROM products WHERE id > 100000 ORDER BY id LIMIT 20;
-- PostgreSQL ใช้ Index ข้ามไปตรงจุดที่ต้องการทันที

Common Table Expressions (CTE)

ตั้งแต่ PostgreSQL 12 เป็นต้นมา CTE จะถูก Inline เข้าไปใน Query หลักอัตโนมัติ (ถ้าอ้างอิงแค่ครั้งเดียว) ทำให้ Planner สามารถปรับแต่งได้ดีขึ้น

-- CTE ที่ถูก Inline (PostgreSQL 12+) — Planner ปรับแต่งได้
WITH recent_orders AS (
    SELECT * FROM orders WHERE created_at > now() - interval '7 days'
)
SELECT customer_id, COUNT(*)
FROM recent_orders
GROUP BY customer_id;

-- บังคับให้ CTE เป็น Materialized (ไม่ Inline)
WITH recent_orders AS MATERIALIZED (
    SELECT * FROM orders WHERE created_at > now() - interval '7 days'
)
SELECT customer_id, COUNT(*)
FROM recent_orders
GROUP BY customer_id;

ใช้ MATERIALIZED เมื่อ CTE ถูกอ้างอิงหลายครั้งหรือเมื่อต้องการคำนวณผลลัพธ์ครั้งเดียว

ปรับแต่ง PostgreSQL Configuration

นอกจากการปรับแต่ง SQL แล้ว การตั้งค่า PostgreSQL ให้เหมาะสมกับ Hardware ก็มีผลต่อประสิทธิภาพอย่างมาก

พารามิเตอร์ที่สำคัญ

# postgresql.conf — ค่าแนะนำสำหรับเซิร์ฟเวอร์ RAM 16 GB

# หน่วยความจำ
shared_buffers = 4GB                # 25% ของ RAM
effective_cache_size = 12GB         # 75% ของ RAM
work_mem = 64MB                     # หน่วยความจำต่อ Operation (Sort, Hash)
maintenance_work_mem = 1GB          # สำหรับ VACUUM, CREATE INDEX

# Planner
random_page_cost = 1.1              # ลดลงถ้าใช้ SSD (ค่าเริ่มต้น 4.0)
effective_io_concurrency = 200      # เพิ่มสำหรับ SSD
default_statistics_target = 200     # เพิ่มความแม่นยำของ Statistics

# WAL
wal_buffers = 64MB
checkpoint_completion_target = 0.9

# Parallel Query
max_parallel_workers_per_gather = 4
max_parallel_workers = 8

work_mem กับผลกระทบ

work_mem กำหนดหน่วยความจำที่แต่ละ Operation (Sort, Hash Join, Hash Aggregate) ใช้ได้ ถ้าตั้งต่ำเกินไป PostgreSQL จะเขียนข้อมูลชั่วคราวลงดิสก์ (Spill to Disk) ทำให้ช้า

-- ตรวจสอบว่ามี Sort Spill to Disk หรือไม่
EXPLAIN (ANALYZE, BUFFERS)
SELECT * FROM orders ORDER BY created_at;
-- ถ้าเห็น "Sort Method: external merge" แสดงว่า work_mem ไม่พอ

-- ตั้ง work_mem เฉพาะ Session (ไม่กระทบ Session อื่น)
SET work_mem = '256MB';

VACUUM และ Statistics

PostgreSQL ใช้ MVCC (Multi-Version Concurrency Control) ซึ่งจะเก็บ Version เก่าของข้อมูล (Dead Tuples) ไว้ VACUUM จะทำความสะอาด Dead Tuples เหล่านี้ และ ANALYZE จะอัพเดต Statistics ที่ Planner ใช้ตัดสินใจ

-- รัน VACUUM + ANALYZE บนตารางเฉพาะ
VACUUM ANALYZE orders;

-- ดู Dead Tuples ของตาราง
SELECT relname, n_dead_tup, n_live_tup, last_vacuum, last_autovacuum
FROM pg_stat_user_tables
WHERE relname = 'orders';

-- ดู Statistics ของคอลัมน์
SELECT attname, n_distinct, most_common_vals, correlation
FROM pg_stats
WHERE tablename = 'orders' AND attname = 'status';

-- เพิ่มความละเอียดของ Statistics บนคอลัมน์ที่มีการกระจายไม่สม่ำเสมอ
ALTER TABLE orders ALTER COLUMN status SET STATISTICS 500;
ANALYZE orders;

Partitioning สำหรับตารางขนาดใหญ่

เมื่อตารางมีข้อมูลหลายสิบล้านแถว การแบ่งตาราง (Partitioning) ช่วยให้ PostgreSQL สแกนเฉพาะ Partition ที่เกี่ยวข้อง แทนที่จะสแกนทั้งตาราง

-- สร้างตารางแบบ Range Partition
CREATE TABLE orders (
    id          BIGSERIAL,
    customer_id INT NOT NULL,
    total       DECIMAL(10,2),
    status      VARCHAR(20),
    created_at  TIMESTAMP NOT NULL
) PARTITION BY RANGE (created_at);

-- สร้าง Partition ตามเดือน
CREATE TABLE orders_2026_01 PARTITION OF orders
    FOR VALUES FROM ('2026-01-01') TO ('2026-02-01');

CREATE TABLE orders_2026_02 PARTITION OF orders
    FOR VALUES FROM ('2026-02-01') TO ('2026-03-01');

CREATE TABLE orders_2026_03 PARTITION OF orders
    FOR VALUES FROM ('2026-03-01') TO ('2026-04-01');

-- เมื่อ Query มีเงื่อนไข created_at PostgreSQL จะสแกนเฉพาะ Partition ที่เกี่ยวข้อง
EXPLAIN SELECT * FROM orders WHERE created_at BETWEEN '2026-02-01' AND '2026-02-28';

Parallel Query

PostgreSQL รองรับการประมวลผลแบบขนาน (Parallel Query) สำหรับ Sequential Scan, Index Scan, Hash Join, Aggregate และอื่น ๆ ช่วยเร่งความเร็วบนตารางขนาดใหญ่

-- ตรวจสอบว่า Parallel Query ทำงานอยู่หรือไม่
EXPLAIN ANALYZE
SELECT status, COUNT(*), SUM(total)
FROM orders
GROUP BY status;
-- ถ้าเห็น "Gather" หรือ "Parallel Seq Scan" แสดงว่าใช้ Parallel

-- ตั้งค่าจำนวน Worker
SET max_parallel_workers_per_gather = 4;

-- บังคับเปิด Parallel สำหรับตารางเล็ก (ทดสอบ)
SET parallel_tuple_cost = 0;
SET parallel_setup_cost = 0;
SET min_parallel_table_scan_size = 0;

ค้นหา Slow Query

เปิด pg_stat_statements

pg_stat_statements เป็น Extension ที่บันทึกสถิติของทุก SQL Statement ช่วยหา Query ที่ช้าหรือใช้ทรัพยากรมาก

-- เปิด Extension (ต้องเพิ่มใน shared_preload_libraries ก่อน)
-- postgresql.conf: shared_preload_libraries = 'pg_stat_statements'
CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

-- ดู Top 10 Query ที่ใช้เวลามากที่สุด
SELECT query,
       calls,
       mean_exec_time::numeric(10,2) AS avg_ms,
       total_exec_time::numeric(10,2) AS total_ms,
       rows
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 10;

-- ดู Query ที่อ่าน Buffer มากที่สุด (I/O-heavy)
SELECT query,
       calls,
       shared_blks_read + shared_blks_hit AS total_buffers,
       shared_blks_read AS disk_reads
FROM pg_stat_statements
ORDER BY shared_blks_read DESC
LIMIT 10;

-- รีเซ็ตสถิติ
SELECT pg_stat_statements_reset();

ใช้ auto_explain สำหรับ Slow Query Log

# postgresql.conf
shared_preload_libraries = 'pg_stat_statements, auto_explain'

# บันทึก Query Plan ของ Query ที่ช้ากว่า 1 วินาที
auto_explain.log_min_duration = '1s'
auto_explain.log_analyze = true
auto_explain.log_buffers = true

เทคนิคขั้นสูง

Materialized View สำหรับ Query ที่ซับซ้อน

-- สร้าง Materialized View สำหรับรายงานที่คำนวณหนัก
CREATE MATERIALIZED VIEW mv_monthly_sales AS
SELECT date_trunc('month', created_at) AS month,
       COUNT(*) AS order_count,
       SUM(total) AS revenue
FROM orders
WHERE status = 'completed'
GROUP BY date_trunc('month', created_at);

-- สร้าง Index บน Materialized View
CREATE INDEX idx_mv_month ON mv_monthly_sales(month);

-- Refresh ข้อมูล (ไม่ล็อก View ระหว่าง Refresh)
REFRESH MATERIALIZED VIEW CONCURRENTLY mv_monthly_sales;

Bulk Operations

-- Bulk INSERT ด้วย COPY (เร็วกว่า INSERT หลายเท่า)
COPY orders(customer_id, total, status, created_at) FROM '/tmp/orders.csv' CSV HEADER;

-- Bulk UPDATE ด้วย FROM
UPDATE orders o
SET status = 'archived'
FROM (
    SELECT id FROM orders WHERE created_at < '2025-01-01' AND status = 'completed'
) sub
WHERE o.id = sub.id;

-- Batch DELETE เพื่อลดการล็อกและ WAL
DELETE FROM orders
WHERE id IN (
    SELECT id FROM orders WHERE status = 'cancelled' LIMIT 10000
);

ใช้ LATERAL JOIN

-- ดึง 3 Order ล่าสุดของแต่ละ Customer
SELECT c.id, c.name, latest.*
FROM customers c
CROSS JOIN LATERAL (
    SELECT order_id, total, created_at
    FROM orders o
    WHERE o.customer_id = c.id
    ORDER BY created_at DESC
    LIMIT 3
) latest;

ตรวจสอบ Index ที่ไม่ได้ใช้

Index ที่สร้างไว้แต่ไม่ถูกใช้จะเป็นภาระให้ Write Operations ช้าลง ควรตรวจสอบและลบ Index ที่ไม่จำเป็นเป็นประจำ

-- ดู Index ที่ไม่เคยถูกใช้ (idx_scan = 0)
SELECT schemaname, tablename, indexname, idx_scan, pg_size_pretty(pg_relation_size(indexrelid)) AS size
FROM pg_stat_user_indexes
WHERE idx_scan = 0
ORDER BY pg_relation_size(indexrelid) DESC;

-- ดู Index ที่ถูกใช้น้อย (รวมขนาด)
SELECT indexrelname, idx_scan, idx_tup_read, idx_tup_fetch,
       pg_size_pretty(pg_relation_size(indexrelid)) AS size
FROM pg_stat_user_indexes
ORDER BY idx_scan ASC
LIMIT 20;

-- ดู Duplicate Index
SELECT a.indexrelid::regclass, b.indexrelid::regclass
FROM pg_index a
JOIN pg_index b ON a.indrelid = b.indrelid
  AND a.indexrelid != b.indexrelid
  AND a.indkey::text = b.indkey::text;

Connection Pooling

การเปิด Connection ใหม่กับ PostgreSQL มีต้นทุนสูง (Fork Process) ถ้าแอปพลิเคชันเปิด-ปิด Connection บ่อย ควรใช้ Connection Pooler เช่น PgBouncer เพื่อลดภาระ

# ตรวจสอบจำนวน Connection ปัจจุบัน
SELECT count(*) as total_connections,
       count(*) FILTER (WHERE state = 'active') as active,
       count(*) FILTER (WHERE state = 'idle') as idle,
       count(*) FILTER (WHERE state = 'idle in transaction') as idle_in_txn
FROM pg_stat_activity;

# ถ้า idle_in_transaction สูง แสดงว่ามี Transaction ค้าง — ต้องแก้ไขโค้ดแอปพลิเคชัน

Checklist สำหรับปรับแต่งประสิทธิภาพ

1. รัน EXPLAIN ANALYZE เพื่อดูแผนการทำงานจริง
2. ตรวจสอบว่ามี Seq Scan บนตารางขนาดใหญ่ที่ไม่ควรมีหรือไม่
3. ตรวจสอบว่า Rows Removed by Filter สูงผิดปกติหรือไม่
4. สร้าง Index ให้ตรงกับ WHERE, JOIN และ ORDER BY
5. ใช้ Partial Index หรือ Covering Index เมื่อเหมาะสม
6. ตรวจสอบว่า Statistics เป็นปัจจุบัน (รัน ANALYZE)
7. ตรวจสอบ work_mem ว่าเพียงพอ (ไม่มี Disk Spill)
8. ตรวจสอบ Dead Tuples (รัน VACUUM ถ้าจำเป็น)
9. พิจารณา Partitioning สำหรับตารางที่มีข้อมูลมากกว่า 10 ล้านแถว
10. ใช้ pg_stat_statements เพื่อหา Slow Query อย่างเป็นระบบ

สรุป

การปรับแต่ง Query ใน PostgreSQL เริ่มจากการวิเคราะห์ด้วย EXPLAIN ANALYZE เพื่อเข้าใจว่า Planner เลือกแผนการทำงานอย่างไร จากนั้นจึงสร้าง Index ที่เหมาะสม เขียน SQL อย่างมีประสิทธิภาพ และปรับแต่งค่า Configuration ให้ตรงกับ Hardware สิ่งสำคัญคือการตรวจสอบอย่างต่อเนื่อง เพราะเมื่อข้อมูลเปลี่ยนแปลง แผนการทำงานที่เหมาะสมอาจเปลี่ยนตามไปด้วย

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

การปรับแต่งประสิทธิภาพ PostgreSQL ให้ได้ผลดีที่สุดต้องอาศัยเซิร์ฟเวอร์ที่ควบคุมได้เต็มที่ ตั้งแต่การปรับ postgresql.conf, จัดสรร RAM ให้ shared_buffers, ไปจนถึงการตั้งค่า SSD สำหรับลด random_page_cost Cloud VPS ของ DE ให้ Root Access เต็มรูปแบบ พร้อม SSD NVMe ที่ให้ประสิทธิภาพ I/O สูง เหมาะสำหรับ Workload ที่ต้องการความเร็วในการเข้าถึงข้อมูล

สำหรับผู้ที่ต้องการโฮสต์เว็บแอปพลิเคชันที่เชื่อมต่อกับ PostgreSQL Cloud Hosting ของ DE ก็เป็นตัวเลือกที่ดี มีระบบจัดการที่ใช้งานง่ายและรองรับการเชื่อมต่อฐานข้อมูลภายนอก