วิธีใช้ Gemini เขียน SQL และ Query Database

Google Gemini สามารถช่วยเขียน SQL ตั้งแต่คำสั่งพื้นฐานอย่าง SELECT, WHERE, ORDER BY และ GROUP BY ไปจนถึง JOIN หลายตาราง, Subquery, CTE, Window Function, INSERT, UPDATE และ Query สำหรับวิเคราะห์ข้อมูลจำนวนมากได้ นอกจากนี้ยังช่วยอธิบาย Query ที่มีอยู่ หา Logic ผิด วิเคราะห์ Error และเสนอแนวทางปรับปรุงประสิทธิภาพได้

วิธีใช้ Gemini เขียน SQL ให้ได้ผลดีไม่ควรสั่งเพียงว่า “เขียน SQL ให้หน่อย” แต่ควรระบุ Database ที่ใช้ โครงสร้าง Table, Column, Relationship, ตัวอย่างข้อมูล และผลลัพธ์ที่ต้องการ เพราะ SQL ของ MySQL, PostgreSQL, SQL Server, SQLite และระบบอื่นอาจมี Syntax หรือ Function แตกต่างกัน

สิ่งสำคัญที่สุดคือ Query ที่มีผลต่อข้อมูลจริง เช่น UPDATE, DELETE, ALTER หรือ DROP ไม่ควร Run บน Production ทันทีหลัง Gemini สร้างให้ ต้องตรวจ Query, Backup ข้อมูล และทดสอบใน Environment ที่ปลอดภัยก่อนเสมอ

❶ 🗄️ Gemini เขียน SQL ได้ไหม

ได้ Gemini สามารถช่วยงาน SQL และ Database ได้หลายประเภท เช่น

• เขียน SELECT
• Filter ด้วย WHERE
• Sort ด้วย ORDER BY
• GROUP BY
• Aggregate
• JOIN
• Subquery
• CTE
• Window Function
• INSERT
• UPDATE
• DELETE
• สร้าง Table
• สร้าง Index
• วิเคราะห์ Query
• หา Duplicate
• หา Missing Data
• สร้าง Report
• แปลง Requirement เป็น SQL
• อธิบาย Query
• Debug SQL Error
• ปรับ Query Performance เบื้องต้น
• แปลง SQL ระหว่าง Database

Gemini จึงสามารถทำหน้าที่เป็นผู้ช่วยตั้งแต่การเรียน SQL ไปจนถึงช่วย Developer หรือ Data Analyst เขียน Query ที่ซับซ้อนขึ้น

❷ 🧠 ก่อนให้ Gemini เขียน SQL ต้องบอก Database ก่อน

คำว่า SQL ไม่ได้หมายความว่า Database ทุกตัวใช้ Syntax เหมือนกันทั้งหมด

ควรบอก Gemini ว่าใช้ระบบใด เช่น

• MySQL
• PostgreSQL
• Microsoft SQL Server
• SQLite
• Oracle Database
• MariaDB

ตัวอย่าง Prompt

“เขียน SQL สำหรับ PostgreSQL”

ดีกว่า

“เขียน SQL”

เพราะ Function บางชนิดต่างกัน เช่น

• Date Function
• String Function
• JSON Function
• Pagination
• Auto Increment
• Upsert
• Window Function
• Data Type

ดังนั้น Database Engine เป็น Context สำคัญมาก

❸ 📋 ข้อมูลที่ควรส่งให้ Gemini ก่อนเขียน Query

อย่างน้อยควรมี 5 อย่าง

1. Database

เช่น

PostgreSQL

2. Table

เช่น

orders
order_items
products
customers

3. Column

เช่น

orders:
- id
- customer_id
- order_date
- status
- total_amount

4. Relationship

เช่น

orders.customer_id -> customers.id
order_items.order_id -> orders.id
order_items.product_id -> products.id

5. ผลลัพธ์ที่ต้องการ

เช่น

“ต้องการยอดขายรวมของแต่ละเดือนในปี 2026”

ยิ่ง Schema ชัด Gemini ยิ่งไม่ต้องเดาชื่อ Column หรือ Relationship

❹ 🧠 Prompt ที่ดีที่สุดสำหรับให้ Gemini เขียน SQL

สามารถใช้ Template นี้ได้

“ช่วยเขียน SQL สำหรับงานต่อไปนี้

Database:
[MySQL/PostgreSQL/SQL Server/SQLite]

Schema:
[ใส่ Table และ Column]

Relationship:
[ระบุ Foreign Key]

เป้าหมาย:
[ผลลัพธ์ที่ต้องการ]

ข้อกำหนด:

1. ใช้เฉพาะ Table และ Column ที่ให้มา
2. ห้ามสร้างชื่อ Column เอง
3. อธิบาย Query ทีละส่วน
4. ระบุว่ามีโอกาสเกิด Duplicate Row จาก JOIN หรือไม่
5. ถ้า Query แก้ไขข้อมูล ให้แสดง SELECT สำหรับ Preview ก่อน
6. ห้ามใช้ DELETE, DROP หรือ UPDATE แบบกว้างโดยไม่มี WHERE
7. หากมีหลายวิธี ให้เลือกวิธีที่อ่านง่ายก่อน
8. ระบุสิ่งที่ควรตรวจด้าน Performance
9. ถ้าไม่สามารถเขียน Query ได้เพราะ Schema ไม่พอ ให้ระบุข้อมูลที่ขาดแทนการเดา”

Prompt นี้เหมาะกับงาน Database จริงมากกว่าการให้ AI สร้าง Query โดยไม่มี Schema

❺ 🔍 วิธีใช้ Gemini เขียน SELECT

SELECT คือคำสั่งพื้นฐานสำหรับดึงข้อมูล

ตัวอย่าง

SELECT
    id,
    name,
    price
FROM products;

Prompt

“เขียน MySQL Query แสดง id, name และ price จาก Table products”

หากต้องการทุก Column สามารถใช้

SELECT *
FROM products;

แต่ใน Application จริง การเลือกเฉพาะ Column ที่ต้องใช้มักชัดเจนกว่าและช่วยลดข้อมูลที่ไม่จำเป็น

❻ 🎯 วิธีใช้ Gemini เขียน WHERE

WHERE ใช้ Filter ข้อมูล

ตัวอย่าง

SELECT
    id,
    name,
    price
FROM products
WHERE price >= 1000;

Prompt

“เขียน Query แสดงสินค้าที่ราคาอย่างน้อย 1,000 บาท”

สามารถเพิ่มหลายเงื่อนไข

SELECT
    id,
    name,
    price,
    stock
FROM products
WHERE price >= 1000
  AND stock > 0;

ควรระบุ Logic ให้ชัดว่าใช้ AND หรือ OR เพราะผลลัพธ์ต่างกันมาก

❼ ↕️ วิธีใช้ Gemini เขียน ORDER BY

ตัวอย่าง

SELECT
    name,
    price
FROM products
ORDER BY price DESC;

ใช้เรียงราคาจากสูงไปต่ำ

ถ้าต้องการต่ำไปสูงใช้

ORDER BY price ASC;

Prompt

“จัดสินค้าตามราคาจากสูงไปต่ำ และถ้าราคาเท่ากันให้เรียงชื่อ A-Z”

สามารถได้ Query เช่น

SELECT
    name,
    price
FROM products
ORDER BY price DESC, name ASC;

❽ 🔢 วิธีใช้ Gemini เขียน LIMIT

ถ้าต้องการ Top 10 เช่นใน MySQL หรือ PostgreSQL

SELECT
    name,
    revenue
FROM products
ORDER BY revenue DESC
LIMIT 10;

Prompt

“เขียน Query หา Product 10 รายการที่ Revenue สูงที่สุด”

แต่ Syntax Pagination แตกต่างกันใน Database บางชนิด ดังนั้นต้องระบุ Database ให้ Gemini ทราบ

❾ 📊 วิธีใช้ Gemini เขียน GROUP BY

GROUP BY ใช้รวมข้อมูลตามกลุ่ม

ตัวอย่าง Table sales

product | revenue
A       | 1000
A       | 2000
B       | 500

Query

SELECT
    product,
    SUM(revenue) AS total_revenue
FROM sales
GROUP BY product;

ผลลัพธ์

A | 3000
B | 500

Prompt

“เขียน SQL รวม Revenue ตาม Product และเรียงจากมากไปน้อย”

Query

SELECT
    product,
    SUM(revenue) AS total_revenue
FROM sales
GROUP BY product
ORDER BY total_revenue DESC;

❿ 🧮 Aggregate Function ที่ Gemini ช่วยเขียนได้

Function ที่พบบ่อย ได้แก่

SUM

SUM(revenue)

COUNT

COUNT(*)

AVG

AVG(price)

MIN

MIN(price)

MAX

MAX(price)

ตัวอย่าง Prompt

“เขียน SQL แสดงจำนวน Order, Revenue รวม และค่าเฉลี่ย Order Value ของแต่ละเดือน”

🔗 วิธีใช้ Gemini เขียน JOIN

JOIN เป็นส่วนที่ Gemini มีประโยชน์มาก แต่ก็เป็นจุดที่ AI สามารถเขียนผิดได้หากไม่รู้ Relationship

สมมติ

customers
- id
- name

orders
- id
- customer_id
- total_amount

Relationship

orders.customer_id -> customers.id

Query

SELECT
    orders.id,
    customers.name,
    orders.total_amount
FROM orders
JOIN customers
    ON orders.customer_id = customers.id;

Prompt

“JOIN orders กับ customers โดยใช้ customer_id และแสดงชื่อ Customer กับยอด Order”

การระบุ Foreign Key ชัดเจนช่วยป้องกัน Gemini JOIN ผิด Column

🆚 INNER JOIN กับ LEFT JOIN ต่างกันอย่างไร

INNER JOIN

คืนเฉพาะข้อมูลที่ Match กันทั้งสองฝั่ง

SELECT *
FROM customers
INNER JOIN orders
    ON customers.id = orders.customer_id;

LEFT JOIN

เก็บ Row ฝั่งซ้ายทั้งหมด แม้ไม่มีข้อมูล Matching ฝั่งขวา

SELECT *
FROM customers
LEFT JOIN orders
    ON customers.id = orders.customer_id;

Prompt ที่ดีคือ

“ฉันต้องการรายชื่อลูกค้าทุกคน รวมคนที่ยังไม่เคยสั่งซื้อ ควรใช้ INNER JOIN หรือ LEFT JOIN อธิบายก่อนเขียน Query”

คำตอบควรนำไปสู่ LEFT JOIN เพราะต้องการเก็บลูกค้าที่ไม่มี Order ด้วย

⚠️ ระวัง JOIN แล้วข้อมูลซ้ำ

นี่เป็นปัญหาที่พบมาก

สมมติ

หนึ่ง Order มีสินค้า 5 รายการ

เมื่อ JOIN

orders
+
order_items

Order หนึ่งสามารถกลายเป็น 5 Row

ถ้านำ orders.total_amount ไป SUM หลัง JOIN อาจทำให้ยอดรวมสูงเกินจริง

Prompt ที่แนะนำ

“ตรวจ Query นี้ว่าการ JOIN ทำให้ Row ถูก Multiply หรือไม่ และ Revenue ที่ SUM มีโอกาสถูกนับซ้ำหรือไม่”

การตรวจ Cardinality เป็นสิ่งสำคัญมากใน Query Analytics

🧩 วิธีใช้ Gemini เขียน Subquery

ตัวอย่าง

ต้องการสินค้าที่แพงกว่าราคาเฉลี่ย

SELECT
    id,
    name,
    price
FROM products
WHERE price > (
    SELECT AVG(price)
    FROM products
);

Prompt

“เขียน SQL หาสินค้าที่ราคาสูงกว่าค่าเฉลี่ยสินค้า”

Gemini สามารถอธิบายได้ว่า Subquery ทำงานก่อนเพื่อหาค่าเฉลี่ย จากนั้น Query หลักใช้ค่านั้น Filter ข้อมูล

🧱 วิธีใช้ Gemini เขียน CTE

CTE หรือ Common Table Expression ช่วยทำ Query ซับซ้อนให้อ่านง่ายขึ้น

ตัวอย่าง

WITH monthly_sales AS (
    SELECT
        DATE_TRUNC('month', order_date) AS month,
        SUM(total_amount) AS revenue
    FROM orders
    GROUP BY DATE_TRUNC('month', order_date)
)

SELECT
    month,
    revenue
FROM monthly_sales
ORDER BY month;

ตัวอย่างนี้ใช้ Syntax แบบ PostgreSQL

ดังนั้นจึงเห็นชัดว่าทำไมต้องบอก Database Engine ก่อนให้ Gemini เขียน SQL

🪟 วิธีใช้ Gemini เขียน Window Function

Window Function เหมาะกับ Analytics ที่ต้องคำนวณโดยยังเก็บรายละเอียดแต่ละ Row

ตัวอย่าง Ranking

SELECT
    product,
    revenue,
    RANK() OVER (
        ORDER BY revenue DESC
    ) AS revenue_rank
FROM product_sales;

Prompt

“เขียน PostgreSQL Query จัดอันดับ Product ตาม Revenue โดยไม่รวม Row เข้าด้วยกัน”

สามารถใช้กับ

• Ranking
• Running Total
• Moving Average
• Previous Row
• Next Row
• Partition

ได้

📈 วิธีเขียน Running Total ด้วย Gemini

ตัวอย่าง

SELECT
    order_date,
    revenue,
    SUM(revenue) OVER (
        ORDER BY order_date
    ) AS running_revenue
FROM daily_sales;

Prompt

“เขียน SQL คำนวณยอด Revenue สะสมตามวันที่”

สำหรับ Query จริงควรตรวจกรณีวันที่ซ้ำและ Order ของข้อมูลให้ชัดเจน

📅 วิธีใช้ Gemini Query วันที่

การ Query วันที่เป็นจุดที่ Syntax ต่างกันระหว่าง Database

ตัวอย่าง Requirement

“ยอดขายรายเดือนในปี 2026”

ควร Prompt

“ใช้ PostgreSQL เขียน Query สรุป Revenue รายเดือนตั้งแต่ 1 มกราคม 2026 ถึงก่อน 1 มกราคม 2027”

การใช้ Range แบบ

>= start_date
< next_start_date

มักช่วยจัดการ Date/Time ได้ชัดกว่าการพยายามเทียบ String วันที่โดยตรงในหลายสถานการณ์

🔍 วิธีใช้ Gemini หา Duplicate

สมมติ Table

users
- id
- email

หา Email ซ้ำ

SELECT
    email,
    COUNT(*) AS duplicate_count
FROM users
GROUP BY email
HAVING COUNT(*) > 1;

Prompt

“เขียน SQL หา Email ที่ซ้ำกันและจำนวนครั้งที่พบ แต่ยังไม่ลบข้อมูล”

ควรตรวจ Duplicate ก่อนเสมอ

อย่าเริ่มด้วย DELETE

🕳️ วิธีใช้ Gemini หา NULL

ตัวอย่าง

SELECT *
FROM users
WHERE email IS NULL;

ไม่ควรใช้

email = NULL

ในการตรวจ NULL แบบ SQL ทั่วไป

Prompt

“หา Record ที่ไม่มี Email และแยก NULL ออกจาก Empty String”

อาจต้องตรวจทั้ง

email IS NULL

และ

email = ''

เพราะความหมายไม่เหมือนกัน

✏️ วิธีใช้ Gemini เขียน INSERT

ตัวอย่าง

INSERT INTO products (
    name,
    price,
    stock
)
VALUES (
    'Router',
    1500,
    10
);

หาก Query มาจาก Application และข้อมูลมาจาก User Input ไม่ควรสร้าง SQL ด้วย String Concatenation

ควรใช้ Parameterized Query ผ่าน Database Library ของภาษาที่กำลังใช้

🔄 วิธีใช้ Gemini เขียน UPDATE อย่างปลอดภัย

ตัวอย่าง

UPDATE products
SET price = 1800
WHERE id = 10;

สิ่งที่อันตรายคือ

UPDATE products
SET price = 1800;

เพราะจะเปลี่ยนทุก Row

ก่อน Run UPDATE ควร Preview ด้วย

SELECT *
FROM products
WHERE id = 10;

Prompt ที่ดีคือ

“สร้าง SELECT Preview ก่อน แล้วจึงสร้าง UPDATE โดยใช้ WHERE เดียวกัน”

นี่เป็นกฎที่มีประโยชน์มากสำหรับ Query ที่เปลี่ยนข้อมูล

🗑️ วิธีใช้ Gemini เขียน DELETE อย่างปลอดภัย

ตัวอย่าง

DELETE FROM products
WHERE id = 10;

ก่อนลบให้ใช้

SELECT *
FROM products
WHERE id = 10;

ตรวจว่ามี Row ใดได้รับผลกระทบบ้าง

🚨 ระวังมากเป็นพิเศษ

Query นี้

DELETE FROM products;

สามารถลบข้อมูลทั้งหมดใน Table ได้

ดังนั้นหาก Gemini สร้าง DELETE ให้ตรวจ WHERE อย่างละเอียดทุกครั้ง

💣 DROP TABLE อันตรายอย่างไร

คำสั่ง

DROP TABLE products;

ลบ Table ไม่ใช่เพียงลบข้อมูลบาง Row

หาก AI เสนอคำสั่ง

• DROP
• TRUNCATE
• ALTER
• DELETE
• UPDATE

ควรหยุดและตรวจผลกระทบก่อน Run

โดยเฉพาะ Production Database

🔒 ใช้ Transaction เมื่อแก้ข้อมูลอย่างไร

Database ที่รองรับ Transaction สามารถใช้เพื่อควบคุมการเปลี่ยนแปลง

แนวคิด

BEGIN;

UPDATE products
SET price = 1800
WHERE id = 10;

-- ตรวจผล

ROLLBACK;

หากทุกอย่างถูกต้องจึงพิจารณา Commit ตาม Workflow ของระบบ

Syntax และ Behavior อาจแตกต่างตาม Database และ Tool ที่ใช้

ดังนั้นควรให้ Gemini เขียน Transaction ตาม Database จริง

💾 Backup ก่อน Query สำคัญ

สำหรับ Query ที่เปลี่ยนข้อมูลจำนวนมาก ควรมี Backup หรือ Recovery Strategy

โดยเฉพาะ

• Bulk UPDATE
• Bulk DELETE
• Schema Migration
• ALTER TABLE
• Data Cleanup
• Data Migration

Gemini สามารถช่วยเขียน Query ได้ แต่ไม่สามารถย้อนข้อมูลจริงให้เราได้หากไม่มี Backup หรือ Transaction ที่เหมาะสม

🔐 วิธีป้องกัน SQL Injection

ตัวอย่างที่ไม่ควรทำใน Application

"SELECT * FROM users WHERE email = '" + userInput + "'"

ควรใช้ Parameterized Query หรือ Prepared Statement ผ่าน Library ที่ระบบใช้งาน

หลักสำคัญคือ

User Input ไม่ควรถูกต่อเข้า SQL String โดยตรง

Prompt

“สร้าง Query สำหรับ Application โดยใช้ Parameter Placeholder และอธิบายวิธี Bind Parameter ตาม Library ที่ใช้”

ควรระบุภาษาและ Library เพิ่ม เช่น

• PHP PDO
• Python sqlite3
• psycopg
• Node.js Database Driver

เพราะรูปแบบ Parameter ต่างกัน

🔎 วิธีใช้ Gemini อธิบาย SQL ของคนอื่น

หากเจอ Query ยาวที่อ่านไม่เข้าใจ ใช้ Prompt

“อธิบาย Query นี้ตาม Logical Flow โดยแบ่งเป็น:

1. Table ต้นทาง
2. JOIN
3. WHERE
4. GROUP BY
5. Aggregate
6. HAVING
7. Window Function
8. ORDER BY
9. Output

จากนั้นสรุปเป็นภาษาธรรมดาว่า Query นี้กำลังตอบคำถามอะไร”

วิธีนี้มีประโยชน์มากกับ Query ที่เขียนโดย Developer คนอื่น

🐛 วิธีใช้ Gemini แก้ SQL Error

ควรส่ง

• Database Engine
• Version
• Query
• Error Message
• Schema
• Expected Result

ตัวอย่าง Prompt

“PostgreSQL Query นี้เกิด Error ต่อไปนี้

[Error]

อย่าแก้ Query ทันที

ให้อธิบาย Error ก่อน แล้วระบุบรรทัดและ Syntax ที่น่าสงสัย”

Error สามารถเกิดจาก

• Syntax
• Column ไม่มี
• Table ไม่มี
• Alias
• Data Type
• Function ไม่รองรับ
• Permission
• Constraint

อย่าแก้ด้วยการเปลี่ยนหลายอย่างพร้อมกัน

⚠️ Query รันได้แต่ผลผิดทำอย่างไร

นี่คือ Logic Bug

ตัวอย่าง

ยอด Revenue ควรเป็น

100,000

แต่ Query ได้

250,000

Prompt

“Query นี้ไม่มี Error แต่ยอดรวมสูงกว่าความจริง ตรวจ JOIN Cardinality, GROUP BY และ Aggregate ว่ามี Row ถูกนับซ้ำหรือไม่”

การไม่มี SQL Error ไม่ได้หมายความว่า Query ถูกต้อง

🧪 ใช้ Sample Data ช่วย Gemini

วิธีที่ดีมากคือให้ข้อมูลตัวอย่างขนาดเล็ก

เช่น

orders
1 | customer 10 | 1000
2 | customer 10 | 2000

customers
10 | Somchai

แล้วระบุ Expected Output

Somchai | 3000

จากนั้นถาม Gemini ให้สร้าง Query

การมี Expected Output ช่วยตรวจ Logic ได้ดีกว่าบอก Requirement อย่างเดียว

📊 วิธีใช้ Gemini Query Analytics

ตัวอย่างคำถามธุรกิจที่แปลงเป็น SQL ได้ เช่น

• Top 10 Product
• Revenue รายเดือน
• ลูกค้าที่ซื้อซ้ำ
• Average Order Value
• Customer Lifetime Value
• Conversion
• Product ไม่มีการขาย
• Order ที่ผิดปกติ
• Revenue Growth
• Cohort เบื้องต้น

ตัวอย่าง Prompt

“จาก Schema นี้ เขียน PostgreSQL Query หา Top 10 Product ตาม Revenue โดยคำนวณ Revenue จาก quantity × unit_price และไม่นับ Order ที่ status = cancelled”

การระบุ Business Rule ชัดมีความสำคัญมาก

💰 อย่าคำนวณ Revenue จาก Column ผิด

ระบบหนึ่งอาจมี

subtotal
discount
tax
shipping
total
refund

คำว่า Revenue อาจไม่ได้หมายถึง total

ก่อนให้ Gemini Query ควรกำหนด Formula

เช่น

Net Revenue =
subtotal - discount - refund

ไม่ควรให้ AI ตัดสิน Business Definition เอง

📉 วิธีหาเดือนยอดขายลดลง

สามารถใช้ Window Function เช่น LAG() ใน Database ที่รองรับ

แนวคิด

WITH monthly_sales AS (
    SELECT
        month,
        SUM(revenue) AS revenue
    FROM sales
    GROUP BY month
)

SELECT
    month,
    revenue,
    LAG(revenue) OVER (
        ORDER BY month
    ) AS previous_revenue
FROM monthly_sales;

จากนั้นสามารถคำนวณ Growth ต่อได้

แต่ต้องปรับ Date Function ให้ตรง Database

🚀 วิธีใช้ Gemini Optimize SQL

ถ้า Query ช้า อย่าเริ่มจากการขอ

“ทำ Query ให้เร็วขึ้น”

ควรส่งข้อมูลเพิ่ม

• Query
• Schema
• Index
• จำนวน Row
• Query Plan
• Execution Time

Prompt

“Query นี้ใช้เวลา 8 วินาทีบน PostgreSQL

ตรวจ Query และ EXPLAIN ANALYZE ที่แนบมา แล้วระบุ Bottleneck ที่มีหลักฐานก่อนเสนอ Index หรือ Rewrite”

นี่มีประโยชน์กว่าการให้ Gemini เดาว่าควรสร้าง Index อะไร

🔍 EXPLAIN มีประโยชน์อย่างไร

Database หลายระบบมีคำสั่งหรือเครื่องมือสำหรับดู Execution Plan เช่น EXPLAIN

Gemini สามารถช่วยอธิบาย Plan ได้

Prompt

“อธิบาย Execution Plan นี้สำหรับคนที่ยังไม่ชำนาญ Database โดยระบุ Scan, Join และจุดที่ Cost สูง”

แต่ Performance Tuning ต้องยืนยันกับ Database จริง เพราะ

• Data Distribution
• Statistics
• Index
• Hardware
• Cache
• Concurrent Load

มีผลต่อ Performance

📇 อย่าสร้าง Index ทุก Column

AI อาจเสนอสร้าง Index เพื่อให้ Query เร็วขึ้น

แต่ Index มีต้นทุน เช่น

• ใช้พื้นที่เพิ่ม
• INSERT ช้าลง
• UPDATE ช้าลง
• DELETE มีงานเพิ่ม

ควรถาม

“Index นี้ช่วย Query ใด และมี Write Cost อย่างไร”

ก่อนสร้างจริง

🧱 วิธีใช้ Gemini สร้าง Table

ตัวอย่าง

CREATE TABLE products (
    id INTEGER PRIMARY KEY,
    name VARCHAR(255) NOT NULL,
    price DECIMAL(10, 2) NOT NULL
);

แต่ Data Type และ Auto Increment Syntax ต่างกันตาม Database

ดังนั้น Prompt ควรระบุ

“สร้าง Table สำหรับ PostgreSQL”

หรือ

“สร้าง Table สำหรับ MySQL”

อย่างชัดเจน

🔗 วิธีให้ Gemini ออกแบบ Foreign Key

Prompt

“จาก Requirement ร้านค้าออนไลน์นี้ ออกแบบ Relationship ระหว่าง users, orders, order_items และ products ก่อน โดยยังไม่สร้าง SQL”

จากนั้นตรวจ

• One-to-One
• One-to-Many
• Many-to-Many

ก่อนสร้าง Schema

การวาง Relationship ผิดตั้งแต่ต้นจะทำให้ Query ซับซ้อนในภายหลัง

🏗️ ใช้ Gemini ออกแบบ Database ได้ไหม

สามารถช่วย Draft ได้ เช่น

• Table
• Column
• Primary Key
• Foreign Key
• Relationship
• Constraint
• Index

แต่ไม่ควรยอมรับ Schema แรกที่ AI สร้างทันที

ควรถามต่อเรื่อง

• Business Rule
• Cardinality
• Data Integrity
• Growth
• Query Pattern
• Transaction
• Retention

ก่อนเลือก Design จริง

🧹 วิธีใช้ Gemini ทำ Data Cleanup

ตัวอย่างงาน

• หา Duplicate
• Normalize Email
• แก้ Status
• Fill Missing Data
• ลบข้อมูลเก่า

ขั้นตอนที่ปลอดภัยควรเป็น

SELECT
↓
ตรวจ Record
↓
Backup
↓
UPDATE/DELETE
↓
Verify

ไม่ควรเป็น

UPDATE/DELETE
↓
ค่อยดูผล

Prompt

“สร้าง Query Preview ก่อนทุก Data Cleanup และห้ามสร้าง DELETE จนกว่าจะมี SELECT ที่ใช้เงื่อนไขเดียวกัน”

🔄 วิธีแปลง SQL จาก MySQL เป็น PostgreSQL

Gemini สามารถช่วยได้

Prompt

“แปลง MySQL Query นี้เป็น PostgreSQL

ตรวจเป็นพิเศษ:

• Date Function
• String Function
• LIMIT
• JSON
• Upsert
• Auto Increment
• Data Type

อธิบายทุกส่วนที่เปลี่ยน”

อย่าเปลี่ยน Syntax อย่างเดียวหาก Behavior ของ Function ต่างกัน

📊 วิธีใช้ Gemini วิเคราะห์ CSV แล้วสร้าง SQL

หากกำลังย้ายข้อมูล CSV เข้า Database สามารถให้ Gemini ช่วยออกแบบ

1. Schema
2. Data Type
3. Import Plan
4. Query Analysis

แต่ควรตรวจข้อมูลจริงก่อน เช่น

• Missing Value
• Duplicate
• Date Format
• Decimal
• Encoding

เพื่อไม่ให้ Schema ถูกออกแบบจากตัวอย่างไม่ครบ

💻 ใช้ Gemini Canvas เขียน SQL ได้อย่างไร

Gemini Canvas สามารถใช้สร้างและแก้ Code ได้ จึงใช้เป็นพื้นที่ Draft SQL และอธิบาย Query ได้เช่นกัน

ตัวอย่าง Prompt

“สร้าง PostgreSQL Query จาก Schema นี้ แล้วอธิบายแต่ละ CTE”

จากนั้นสั่ง

“แก้ Query ให้เพิ่ม Month-over-Month Growth”

หรือ

“Review JOIN ว่ามีโอกาส Duplicate Revenue หรือไม่”

อย่างไรก็ตาม Query ต้อง Run กับ Database จริงเพื่อยืนยัน Syntax, Result และ Performance

Canvas ไม่ควรถูกมองเป็นตัวแทน Production Database

📂 ใช้ Gemini กับ Database Project หลายไฟล์

หาก Application มี

• SQL Migration
• Model
• Repository
• Service
• Schema

หลายไฟล์ สามารถ Import Code Folder หรือ GitHub Repository แล้วถาม

“ค้นหา Query ทั้งหมดที่เกี่ยวข้องกับ Order และอธิบายว่า Application อ่านและเขียน Table ใดบ้าง”

เหมาะกับการทำความเข้าใจ Data Access Layer ของโปรเจกต์

🔐 ห้ามส่ง Database Credential

ก่อนส่ง Code หรือ Configuration ให้ Gemini ตรวจหา

• Database Password
• Connection String
• Private Host
• API Key
• Access Token
• Production Credential

ตัวอย่างที่ไม่ควรส่ง

postgres://admin:REAL_PASSWORD@server/database

ควรแทนด้วย

postgres://USER:PASSWORD@HOST/DATABASE

และเก็บ Secret แยกออกจาก Source Code

🚫 อย่าส่งข้อมูล Production ทั้ง Table ถ้าไม่จำเป็น

หากต้องการให้ Gemini ช่วยเขียน Query โดยทั่วไปไม่จำเป็นต้องส่งข้อมูลลูกค้าจริงหลายล้าน Row

ส่วนใหญ่ใช้เพียง

• Schema
• Relationship
• Sample Data ที่ไม่ Sensitive
• Expected Result

ก็เพียงพอ

สำหรับงาน Database ของ comsiam แนวทางที่เหมาะสมคือใช้ข้อมูลจำลองหรือข้อมูลที่ตัดข้อมูลส่วนตัวออกก่อนส่งให้ AI และเก็บ Query Production ไว้ภายใต้กระบวนการ Review และ Backup ตามปกติ

⚠️ SQL จาก Gemini ถูกต้อง 100% หรือไม่

ไม่ควรถือว่าถูกต้อง 100%

Gemini สามารถสร้าง Query ที่

• Syntax ผิด
• ใช้ Function ผิด Database
• JOIN ผิด
• SUM ซ้ำ
• GROUP BY ผิด
• Date Range ผิด
• UPDATE กว้างเกิน
• DELETE ผิด Record
• Query ช้า
• Index ไม่เหมาะ
• ไม่ตรง Business Rule

ดังนั้น Query สำคัญต้อง Run กับ Test Data ก่อนเสมอ

🚫 10 ข้อผิดพลาดเมื่อใช้ Gemini เขียน SQL

❶ ไม่บอก Database Engine

อาจได้ Syntax ผิด

❷ ไม่ส่ง Schema

Gemini ต้องเดา Column

❸ ไม่ระบุ Relationship

JOIN อาจผิด

❹ ไม่บอก Expected Result

ตรวจ Logic ยาก

❺ Run UPDATE ทันที

ยังไม่ได้ Preview

❻ Run DELETE บน Production

มีความเสี่ยงสูง

❼ ไม่ตรวจ Duplicate จาก JOIN

ยอด Aggregate อาจผิด

❽ สร้าง Index ตาม AI ทุกอัน

อาจเพิ่ม Write Cost โดยไม่จำเป็น

❾ ไม่ตรวจ Query Plan

Performance Recommendation อาจเป็นเพียงการเดา

❿ ส่ง Credential จริงให้ AI

เสี่ยงข้อมูลลับรั่ว

🪜 Workflow ใช้ Gemini เขียน SQL อย่างปลอดภัย

แนวทางที่แนะนำคือ

❶ ระบุ Database

MySQL, PostgreSQL หรือระบบอื่น

❷ ส่ง Schema

Table และ Column

❸ ส่ง Relationship

Foreign Key

❹ กำหนด Requirement

ต้องการตอบคำถามอะไร

❺ สร้าง SELECT

เริ่มจาก Query ที่ไม่แก้ข้อมูล

❻ ตรวจ Sample Result

เทียบกับ Expected Result

❼ ตรวจ JOIN

ป้องกัน Row Duplication

❽ ตรวจ NULL และ Edge Case

ดูข้อมูลผิดปกติ

❾ Test Database

Run ใน Environment ที่ปลอดภัย

❿ ตรวจ Performance

ใช้ Execution Plan หากจำเป็น

⓫ Preview การเปลี่ยนข้อมูล

ก่อน UPDATE/DELETE

⓬ Backup หรือ Transaction

ตามความเสี่ยง

⓭ Run Write Query

หลัง Review

⓮ Verify

ตรวจข้อมูลหลังแก้

Workflow แบบนี้ปลอดภัยกว่าการ Copy Query จาก Gemini ไป Run ทันที

💡 10 Prompt ใช้ Gemini เขียน SQL

❶ SELECT

“เขียน PostgreSQL Query เลือก Column เหล่านี้จาก Table นี้ โดยห้ามสร้าง Column เพิ่มเอง”

❷ JOIN

“JOIN Table A กับ B ตาม Foreign Key นี้ และตรวจว่า Row สามารถ Multiply หรือไม่”

❸ GROUP BY

“รวม Revenue ตาม Product และเรียงจากมากไปน้อย”

❹ Duplicate

“หา Duplicate ตาม Email แต่ยังไม่ลบข้อมูล”

❺ NULL

“หา NULL และ Empty String แยกจากกัน”

❻ Analytics

“คำนวณ Revenue รายเดือนและ Month-over-Month Growth”

❼ Debug

“อธิบาย SQL Error นี้ก่อน แล้วระบุ Syntax ที่ควรตรวจ”

❽ Performance

“วิเคราะห์ Query Plan นี้ก่อนเสนอ Index”

❾ UPDATE

“สร้าง SELECT Preview ก่อน แล้วสร้าง UPDATE ด้วย WHERE เดียวกัน”

❿ DELETE

“แสดง Record ที่จะถูกลบก่อน และห้ามสร้าง DELETE หากเงื่อนไขยังไม่เฉพาะเจาะจง”

❓ คำถามที่พบบ่อย

Gemini เขียน SQL ได้ไหม

ได้ Gemini สามารถช่วยสร้าง อธิบาย Debug และปรับปรุง Query ได้ตั้งแต่ SELECT พื้นฐานไปจนถึง JOIN, CTE และ Window Function

ต้องบอก Gemini ว่าใช้ MySQL หรือ PostgreSQL ไหม

ควรบอก เพราะ Database แต่ละระบบมี Syntax, Function และ Data Type บางส่วนแตกต่างกัน

Gemini เขียน JOIN ได้ไหม

ได้ แต่ควรให้ Schema และ Relationship ที่ชัดเจน และต้องตรวจว่า JOIN ทำให้ข้อมูลเกิด Duplicate Row หรือไม่

Gemini ช่วย Optimize SQL ได้ไหม

สามารถช่วยวิเคราะห์เบื้องต้นได้ แต่ควรส่ง Query Plan, Index, จำนวนข้อมูล และ Execution Time เพื่อให้คำแนะนำมีหลักฐานมากขึ้น

ควร Run DELETE หรือ UPDATE ที่ Gemini สร้างทันทีไหม

ไม่ควร ควรสร้าง SELECT Preview ก่อน ตรวจ WHERE, Backup หรือใช้ Transaction ตามความเหมาะสม และทดสอบใน Environment ที่ปลอดภัย

SQL ที่ Gemini เขียนแม่น 100% หรือไม่

ไม่ควรถือว่าถูกต้อง 100% ต้องตรวจ Syntax, Logic, Business Rule, Result และ Performance กับ Database จริงก่อนใช้งาน

🎯 สรุป

วิธีใช้ Gemini เขียน SQL และ Query Database ให้ได้ผลดีที่สุดคือเริ่มจาก Database Engine → Schema → Relationship → Requirement → SELECT → Verify → Optimize → Write Query

Gemini สามารถช่วยสร้าง Query ตั้งแต่ SELECT, WHERE, JOIN, GROUP BY ไปจนถึง CTE และ Window Function แต่สิ่งสำคัญคือ AI ต้องได้รับ Schema จริง มิฉะนั้นอาจสร้าง Table หรือ Column ที่ไม่มีอยู่

สำหรับ Query ที่แก้ไขข้อมูล ควรใช้แนวคิด Preview First โดยสร้าง SELECT ด้วยเงื่อนไขเดียวกับ UPDATE หรือ DELETE เพื่อตรวจ Record ก่อน และควรมี Backup หรือ Transaction ตามระดับความเสี่ยง

Query Analytics ยังต้องตรวจเรื่อง JOIN Duplication, NULL, Date Range และ Business Definition เช่น Revenue ให้ชัดเจน เพราะ SQL สามารถรันได้สำเร็จแต่ให้คำตอบผิดได้

แนวทางของ comsiam คือใช้ Gemini เป็นผู้ช่วยแปลง Requirement เป็น SQL และช่วย Review Query ส่วน Database จริงยังต้องเป็นตัวพิสูจน์ Syntax, Result และ Performance ก่อนนำ Query ไปใช้กับข้อมูล Production