ถ้าต้องดึงออกมาทำ report คงต้องทำเป็น service ที่รันหลังบ้านแล้วล่ะครับเมื่อรันเสร็จก็ค่อยแจ้ง user ทางเมลล์หรือให้ user มาดูสถานะทางหน้าเวบ ถ้าทำงานเสร็จแล้วก็ให้ user ดึงเฉพาะ report ที่ generate แล้วออกมาดู

โดยปกติทั่วไป report ที่ต้องดึงข้อมูลจำนวนมากมักจะเป็น report รายเดือน สิ้นเดือนทำทีนึงอะไรประมาณนั้น

แต่ถ้าการ query แบบทั่วไปช้าด้วยเหตุว่าข้อมูลเยอะ (ปรับจูน ทำ index แก้ query แล้วก็ยังช้า) ก็ลองพิจารณาย้ายข้อมูลเก่าๆไปเก็บไว้อีกที่นึงแทน แต่ถ้าไม่สะดวกทำแบบนั้นก็ลองพวก nosql ดู เห็นว่ามีคนแถวนี้มีประสบการณ์ implement redis ด้วย :)

ตาม คห ข้างบนครับ เช็คดูดีๆว่า index ถูกตองหมดรึเปล่า

ถ้าครบหมดแล้วอาจต้องโมฮาร์ดแวร์กันบ้าง เช่น ssd ไรงี

จริงๆ ต้องแยกเป็น 2 ประเด็นนะครับ คือ ฝั่ง hardware กับฝั่ง program

ฝั่ง hardware ก็ต้องลองหาข้อมูลพวกการ sizing ดูอ่ะครับ ซึ่งอันนี้ขึ้นอยู่กับว่าเอา database ไปใช้ทำอะไร แล้ว characteristic การใช้เป็นยังไง เช่น ใช้เป็น OLTP หรือทำ data warehouse มันก็จะต่างกัน แล้วโดยปกติถ้ามี hardware แล้วก็อาจจะลอง monitor performance ฝั่ง hardware ดูได้ ว่าตอนนี้เครื่องยังไหวหรือเปล่า มีตรงไหนที่ควรจะต้อง upgrade เพิ่มเติมหรือเปล่า ซึ่งหลักๆ ก็พวก Memory usage, page file usage, I/O usage, CPU usage อะไรประมาณนี้

ส่วนฝั่ง program อันนี้ต้อง fine tune ตัว config ของ database หรือ query ดูอ่ะครับ เช่น มี index หรือเปล่า index ถูกใช้หรือเปล่า ทำ data partitioning ได้มั้ย ซึ่งอันนี้ก็ต้องดูเป็น case ไปอ่ะครับ

ไม่ทราบว่า Query ที่ใช้ต้องการข้อมูล Real-time มากน้อยแค่ไหนครับ
แล้วฐานข้อมูลมีการอัพเดต บ่อยแค่ไหนครับ เป็นข้อมูลลักษณะยังไง ใช้งานยังไง

ฯลฯ ถ้าโจทย์กระชับขึ้น ตรงนี้อาจจะมีทางออกอื่นๆ เพิ่มขึ้นครับ

เช่นมีฐานข้อมูลเฉพาะไว้พักข้อมูล ก่อนจะออกรายงาน ฯลฯ ประมาณนี้ครับ

เอาคิวรีมา แล้วกด Ctrl + L เพื่อดู Execution Plan เพื่อดูว่ามีการใช้งาน index หรือไม่
เอา query กับรูป execution plan จะบอกให้ได้ว่าเป็นยังไง

แค่ 25 ล้าน สบาย ๆ ครับ

อีกจุดที่ควรเช็คคือพวกที่เป็น Composite key ครับ

DBMS บางตัวจะตรงไปตรงมาไม่ค่อย Optimize ให้เราสักเท่าไรเช่น DB2 (ไม่แน่ใจว่า MSSQL เป็นเหมือนกันรึเปล่า)

เช่นมี Composite Key เป็น Table1(A,B,C), Table2(B,C) เวลาเขียน inner join จะใช้ key ของ Table1 ไม่ครบ เพราะ join กันแค่ B, C มันจะไม่ใช้ PK index ของ Table1 ที่สร้างบน A,B,C ทำให้ช้า

แก้ด้วยการเพิ่ม index ของ B, C บน Table1 เข้าไปเอง DBMS ถึงจะเรียกใช้ index ครับ

Disk storage management RAID R/W Section Table ไหนมีการอ่านเขียนบ่อย แยก Sector ของ Disk,Indexing,Query Plan, Big(O) Analysis,Materialize View, อันสุดท้าย Query Syntax

เก็บ log น่ะซิ แยก table ละวันไปเลย หรือไม่ก็อาทิตย์ละ table ส่วนข้อมูลที่เก่ากว่านั้นก็ส่งไปเก็บรวมไปอีก 1 table (ก่อนที่จะรับของอาทิตย์ใหม่เข้ามา) (คราวนี้ล่ะ query ข้อมูลช่วง 1-2 เดือนแรกเร็วปี๊ด)

partition ข้อมูลตามเวลาน่าจะช่วยได้ครับ SQL Server 2005 support feature นี้แต่ถ้า database ใช้งานตลอดคงต้องวางแผ่นเรื่อง migration ดีๆ

http://www.databasejournal.com/features/mssql/article.php/3638236/Data-partitioning-in-SQL-Server-2005---Part-I.htm