Legacy 90s Stack: Delphi, VB6, Crystal Reports, Firebird

รับงานระดับองค์กรจริง — ระบบเงินสด/สต็อก/บัญชี/สาขา/ข้อมูลสำคัญ เน้น ไม่หยุดระบบ, คุมความเสี่ยง, ตรวจสอบย้อนหลังได้ เหมาะกับโรงงานและสถาบันการเงิน

ฐานข้อมูลช้า • โปรแกรมอืด • ระบบไม่เสถียร • ใช้หลายเครื่องพร้อมกัน — เราแก้ได้

อาการยอดฮิตของระบบก่อนปี 2010 คือ DB ช้า, โปรแกรมหน่วง, เปิดหลายเครื่องแล้วค้าง/หลุด หรือ “ทำงานได้แต่ไม่ลื่น” — จุดสำคัญคือ แก้ให้ถูกชั้น (DB / Network / App / Report / Lock) ไม่ใช่เดาสุ่ม

Performance Tuning (SQL/Index/Query) Lock/Deadlock/Transaction แยกงานรายงานออกจากระบบขาย รองรับผู้ใช้พร้อมกันหลายคน/หลายสาขา Monitoring & Log เพื่อเห็นปัญหาจริง

วิธีที่เราแก้ (ทำให้วัดผลได้)

1) แยกชั้นที่ช้า

DB vs App vs Network

ช้าตอน “ค้นหา/สรุป” หรือช้าตอน “บันทึก/ขาย”?
ช้าเฉพาะช่วงสิ้นวัน/สิ้นเดือน หรือช้าตลอด?
ช้าทุกเครื่อง หรือเฉพาะบางเครื่อง/บางสาขา?

แยกให้ได้ก่อน แล้วค่อยยิงไปที่สาเหตุจริง

2) จับคอขวดฐานข้อมูล

Index • Query Plan

Query สแกนทั้งตาราง / Join หนัก / Sort หนัก
Index ขาด หรือ Index ไม่เหมาะกับรูปแบบค้นหา
สถิติ/แผนการทำงานไม่ดี, I/O สูง, Temp/Sort มาก

ปรับแบบ “ก่อน-หลัง” มีตัวเลขรองรับ

3) แก้ Lock/Deadlock

Transaction • Isolation

หลายคนบันทึกพร้อมกันแล้วค้าง
Transaction ยาวเกิน (รอพิมพ์/รอผู้ใช้) ทำให้ล็อกค้าง
ปรับลำดับการเขียน ลดจุดชน และทำ retry ที่ถูกวิธี

ผลคือระบบ “เสถียรขึ้น” และรองรับพร้อมกันได้มากขึ้น

4) แยกงานรายงาน

Report DB/Replica

รายงานหนักไปอ่านตารางหลัก → ทำ POS/บันทึกช้า
แก้ด้วย View/SP สำหรับรายงาน และฐานข้อมูลรายงานแยก
ตั้งรอบ sync ให้เหมาะกับธุรกิจ (ใกล้ real-time หรือเป็นรอบเวลา)

ขายลื่น รายงานก็ได้ โดยไม่ต้องเลือกอย่างใดอย่างหนึ่ง

คำถามที่เจอบ่อย

ฐานข้อมูลช้า เกิดจากอะไรบ่อยที่สุด?

มักเกิดจาก Query ไม่มีดัชนี (Index), Join หนัก, สถิติไม่อัปเดต, Lock/Deadlock หรือมีรายงานไปอ่านข้อมูลตารางหลักโดยตรง ทำให้กระทบงานขาย/งานบันทึก

โปรแกรมอืด แต่เครื่องแรง แก้ยังไง?

แยกให้ชัดว่าอืดที่ DB/เครือข่าย/หน้าจอ/รายงาน แล้วแก้ตามชั้น เช่น ปรับ Query+Index ลด round-trip ทำ caching แบบปลอดภัย และแยกงานรายงานออกจาก Transaction

ใช้งานหลายเครื่องพร้อมกันแล้วไม่เสถียร แก้ได้ไหม?

ได้ โดยจัดการ Transaction/Locking/Isolation และออกแบบการเขียนข้อมูลให้ลดการชนกัน พร้อมทำ Monitoring เพื่อเห็นปัญหาจริงจาก log/metric

ต้องรื้อระบบใหม่ทั้งหมดไหม?

ส่วนใหญ่ไม่จำเป็น เราเริ่มจากแก้คอขวดและแยกส่วนที่เสี่ยงต่ำก่อน (รายงาน/อ่านข้อมูล/อนุมัติ) เพื่อให้ผลลัพธ์เร็วและไม่กระทบธุรกิจ

สรุปแบบตรง ๆ: เราแก้ให้ “ลื่นขึ้น + เสถียรขึ้น + รองรับหลายเครื่องพร้อมกัน” โดยไม่ต้องรื้อระบบใหม่ทั้งก้อน