กลับตัวก็ไม่ได้ จะเดินต่อไปก็ไปไม่ถึง (ภาคการศึกษาไทย อีกครั้ง T_T)

โพสต์ทูเดย์ — ผลสำรวจพบเด็กไทยมีความสามารถแข่งขันด้านการศึกษารั้งท้ายนานาประเทศ

หนังสือพิมพ์โพสท์ทูเดย์ ฉบับวันพฤหัสบดีที่ 10 มกราคม พ.ศ. 2551

นางจรวยพร ธรณินทร์ ปลัดกระทรวงศึกษาธิการ (ศธ.)

กล่าวว่า  จากผลการวัดความสามารถการแข่งขันของประเทศต่างๆ ด้านการศึกษาประจำปี 2550 ของสถาบันนานาชาติเพื่อการพัฒนาการจัดการ (ไอเอ็มดี) พบว่า

  • คนไทยมีสมรรถนะอยู่ในลำดับที่ 46 ทั้งนี้ จากการสำรวจทั้งหมด 55 ประเทศทั่วโลก
  • โดยมีผลประเมินแยกตามโครงสร้างพื้นฐานด้านการศึกษา 10 รายการ คือ
  • อัตราส่วนนักเรียนต่อครูประถมได้อันดับ 43 โดยมีครู 1 คนต่อนักเรียน 20.68 คน
  • อัตราส่วนนักเรียนต่อครูมัธยมได้อันดับที่ 48 มีครู 1 คนต่อนักเรียน 21 คน
  • อัตราเข้าเรียนระดับมัธยมอันดับที่ 46 มีเยาวชนอายุ 12-17 ปีได้เข้าเรียนมัธยม 72% จากประชากรวัยเดียวกัน
  • อัตราการไม่รู้หนังสือของผู้ใหญ่อายุ 15 ปีขึ้นไป อันดับ 43 ในอัตรา 7.4%
  • การลงทุนทางการศึกษาของภาครัฐอันดับ 42 มีการลงทุนในอัตรา 4.1% ของจีดีพี
  • ผลสัมฤทธิ์อุดมศึกษา อันดับที่ 39 มีอัตราผู้สำเร็จระดับอุดมศึกษา 18%
  • ด้านการถ่ายโอนความรู้ระหว่างภาคธุรกิจกับมหาวิทยาลัย มีการจัดการศึกษาตอบสนองภาคธุรกิจ ตลาดแรงงานอันดับที่ 42
  • การตอบสนองความสามารถใน การแข่งขันของระบบการศึกษาอันดับที่ 38
  • การตอบสนองความสามารถในการแข่งขันของการอุดมศึกษาต่อภาคเศรษฐกิจและการแข่งขัน อันดับที่ 39
  • ทักษะด้านภาษาที่ตอบสนองต่อความต้องการของผู้ประกอบการ อันดับที่ 48
  • นอกจากนี้ จากการประเมินเพื่อวัดคุณภาพการศึกษาในประเทศเป้าหมาย 41 ประเทศ ด้านการอ่าน คณิตศาสตร์ และวิทยาศาสตร์ ในปี 2550 ของโครงการสำรวจความรู้และทักษะการเรียนของเด็กอายุ 15 ปี (PISA) ในประเทศสมาชิกขององค์กรเพื่อความร่วมมือและพัฒนาเศรษฐกิจ (OECD) พบว่า เวลาเรียน 2 วิชานี้ของนักเรียนไทยน้อยกว่าประเทศอื่น รวมทั้งขาดแคลนครูที่มีความสามารถ อีกทั้งนักเรียนไทยอายุ 15 ปี เขียนสะกดและใช้คำผิดมากที่สุด ไม่สามารถแยกแยะระหว่างภาษาพูดกับภาษาเขียน เรียงประโยค ไม่เป็น เรียบเรียงความคิดลงเป็นการเขียนไม่ได้
  • นางจรวยพร กล่าวว่า ปัญหาการศึกษาไทยมีสาเหตุจากการคิดและอ่านของเยาวชน 4 ประการ คือ

    1. เยาวชนคิดผิด คือ คิดแบบเอาเปรียบ คิดเรียนลัด คิดเก็งกำไร
    2. คิดไม่เป็น คือ ตามผู้อื่น เลียนแบบ เชื่อเพราะผู้พูดเป็นผู้ใหญ่หรือ ผู้อาวุโส
    3. ไม่คิด คือ ติดนิสัยพึ่งพา ผู้อื่น เชื่อตัวบุคคล เชื่อนักวิชาการ เชื่อหนังสือพิมพ์ โดยไม่ไตร่ตรอง
    4. คิดแล้วไม่ทำ คือ ประชุมเสร็จก็เลิกรา ปล่อยให้คนที่รับผิดชอบไปทำคนเดียว ไม่ช่วยระดมในรูปกลุ่ม ดังนั้นต้องร่วมกันแก้ปัญหาเหล่านี้

     

    แต่ผมว่าเรื่องนี้ไม่ต้องโทษใคร "โทษตัวเองดีกว่า" ครับ ผมว่านะ "พวกเราคือผลผลิตอันสมบูรณ์ของการศึกษาที่ล้มเหลว" อย่างที่พี่เดฟเคยบอกไว้ครับ T_T

    ขจัดขยะ Internet บน Google

    สื่อเนื่องจาก เริ่มทนไม่ได้กับขยะในการค้นหาข้อมูล

    image

    (รูปจาก เริ่มทนไม่ได้กับขยะในการค้นหาข้อมูล by audy )

    ตอนนี้ผมลง CustomizeGoogle ซึ่งเป็น Firefox Add-ons ตามที่คุณ nott เค้าแนะนำไว้ แล้วลง Filter site ไว้ โดย

    เอา File google_filter.zip นี้ไป import เข้า filter ของ CustomizeGoogle ซะ มันจะทำการ filter ข้อมูลพวกนี้ออกไปซะ

    แล้วจะได้ผลเป็นแบบนี้แทน

    image

    คราวนี้ก็ลดความกวนใจไปได้เยอะเลย เนื้อ ๆ น้ำ ๆ กับผลการค้นหาขึ้นมาหน่อยแล้วงานนี้ ;)

    นี่น่าจะเป็นผลพวงจากการทำ SEO โดยไม่คำนึงถึงเนื้อหาสาระครับ ใครทำ SEO ก็ควรทำอย่าง พอเหมาะ พอสม ไม่ใช่ทำแล้วคนอื่นเดือดร้อนกับเนื้อหาที่ไม่มีใครต้องการครับผม

    [Update 11/01/2008 9:52]

    มีคนถามว่าเว็บในไฟล์ที่ให้โหลดมีเว็บอะไรบ้างที่โดนบล็อค ด้านล่างนี่คือรายการทั้งหมดที่โดน block ครับผม

    appjob.com
    truehits.net
    ohsanook.com
    siamha.com
    konthai.com
    thaiza.com
    pangza.com
    24thai.com
    itzaa.com
    tidtak.com
    zengped.com
    mydrmobile.com
    abc-yoga.biz
    ohocute.com
    yingza.com
    lud0xgirlsclub.com
    fwdder.com
    darathai.info
    meemodel.com
    siamhrm.com
    thaieasyjob.com
    jeedza.com
    thaigirlnextdoor.com
    moohin.com
    trirong.com

    โดนกันไปครับ ฮา ……

    [Update 15/02/2008 10:52]

    ดับไปแล้วครับเรียบร้อย

    image

    ดิ่งลงชั่วข้ามคืน 555555

    ว่ากันด้วย PageRank

    จากตอนที่ เทคนิดการทำ SEO เบื้องต้นที่ควรรู้ (reloaded) ที่ทิ้งท้ายไว้ใน comment ว่าจะพูดถึงเรื่องนี้วันนี้เราขอพูดถึงเรื่องนี้ซะเลยครับ

    PageRank หรือในอีกชื่อคือ PageRank of E เรียกสั้น ๆ ว่า PR หรือ PR(E) เป็น graph analysis algorithm ในทฤษฎี graph รูปแบบหนึ่ง โดยถ้าใครเรียนในวิชาพวก project management, software engineering หรือ software analysis จะได้เจอในส่วนของ Critical Path Analysis และ PERT (Program Evaluation & Review Technique) โดยที่ PageRank นั้นพัฒนาขึ้นที่ Stanford University โดย Larry Page และ Sergey Brin โดยเป็นงานวิจัยในระดับปริญญาเอก เพื่อการค้นคว้าหาวิธีการใหม่ ๆ ในการค้นหาข้อมูล โดยเริ่มต้นงานวิจัยในปี 1995 และต้นแบบก็สามารถใช้งานได้ในชื่อของ Google ในปี 1998 ในความเป็นจริงที่ว่า PageRank เป็นเครื่องหมายทางการค้าของ Google Inc. โดยมีหมายเลขสิทธิบัตรอยู่ที่ U.S. Patent 6,285,999 แต่ว่าสิทธิบัตรไม่ได้เป็นของ Google Inc. แต่เป็นของ Stanford University (The Board of Trustees of the Leland Stanford Junior University, Stanford, CA)

    โดยที่ Page Rank ตามความหมายที่ Google ให้ไว้คือ

    PageRank relies on the uniquely democratic nature of the web by using its vast link structure as an indicator of an individual page’s value. In essence, Google interprets a link from page A to page B as a vote, by page A, for page B. But, Google looks at more than the sheer volume of votes, or links a page receives; it also analyzes the page that casts the vote. Votes cast by pages that are themselves “important” weigh more heavily and help to make other pages “important”.

    โดยถ้าจะให้เข้าใจได้ง่าย ๆ นั้นก็คือว่า (แปลสรุปเป็นไทย)

    หน้าใด ๆ บน internet ยิ่งมีการลิงก์ถึงหน้านั้นมาก ๆ ก็ยิ่งได้รับคะแนนสูงขึ้น และถ้าหน้าเหล่านั้นที่มีคะแนนสูง ๆ มีลิงก์ไปหน้าอื่น ๆ หน้าที่ลิงก์ไปปลายทางก็จะได้รับคะแนนตามสัดส่วนไปด้วยและจริง ๆ แล้วเนี่ย แนวคิดนี้เป็นแนวคิดที่ได้จากการอ้างอิงของหนังสือในแวดวงวิชาการ โดยมีแนวคิดที่ว่า “หนังสือเล่มใด มีความน่าเชื่อถือว่าสูงมักจะมีการนำไปใช้อ้างอิงอยู่เสมอ ๆ”

    ตัวอย่างเช่น

    ตามรูปด้านล่างนี้ครับ

    เรามีเว็บ A, B, C และ D โดยที่ทุกหน้ามี PR(E) อยู่ที่ 0.25

    โดยที่ B, C และ D นั้นลิงก์ไปที่ A โดยที่ A จะได้คะแนนไป 0.25 จากทุก ๆลิงก์เป็น 0.75

     1

    โดยเราจะเขียนเป็นสมการว่า

    image

    ต่อมาเมื่อ B ทำลิงก์ไปที่ C และ D ทำลิงก์ไปที่ A, B และ C ค่า PR(E) ของตนที่จะให้กับหน้าปลายทางจะถูกหารตามจำนวนลิงก์ที่ลิงก์ออกไป ส่วนหน้า D ตามตัวอย่างที่ไม่มีลิงก์เข้ามาที่หน้านี้ ก็จะยังคงค่าคะแนนที่ 0.25 เท่าเดิม (แต่ในความเป็นจริงแล้วจะเป็น 0 หรือค่าตั้งต้นใด ๆ )

    PR(B) / 2 = 0.125 / link

    PR(D) / 3 = 0.083 / link

    PR(C) / 1 = 0.25

    2

    จะได้สมการดังนี้

    image

    เราเรียกวิธีการแบบนี้ว่า link-votes หรือบางครั้งอาจจะเรียกว่า outbound link ก็ได้ โดยใช้ฟังค์ชัน L() แทนด้วยด้วยจำนวน outbound link

    image

    โดยสรุปให้สั้นได้ว่า

    image

    จากตัวอย่างด้านบนที่ได้กล่าวไปนั้น เอามาสร้างแบบจำรองได้ดังรูปด้านล่างนี้ครับ

    image

    Mathematical PageRanks (out of 100) for a simple network (PageRanks reported by google are rescaled logarithmically). Page C has a higher PageRank than Page E, even though it has fewer links to it: the link it has is much higher valued. A web surfer who chooses a random link on every page (but with 15% likelihood jumps to a random page on the whole web) is going to be on Page E for 8.1% of the time. (The 15% likelihood of jumping to an arbitrary page corresponds to a damping factor of 85%.) Without damping, all web surfers would eventually end up on Pages A, B, or C, and all other pages would have PageRank zero. Page A is assumed to link to all pages in the web, because it has no outgoing links.

    นั้นหมายความว่ายิ่งเรามีลิงก์กลับมาหน้าของเว็บเรามากเท่าใด ก็ยิ่งได้รับ PR(E) สูงมากขึ้นเท่านั้น แต่เราต้องผสมกับการใช้ SEO เข้าร่วมด้วยเช่นกัน

    ถ้าจะให้สรุปง่ายก็คือ SEO นั้นทำให้ Crawler เข้ามา index ข้อมูลของเราได้ง่ายมากขึ้น และนำข้อมูลของเราไปจัดอันดับ โดยอ้างอิงจาก PR(E) ด้วยเช่นกัน โดยการที่จะได้ PR(E) สูง ๆ นั้นเว็บของเราต้องมีลิงก์ที่อยู่บนเว็บที่มี PR(E) ที่สูงกว่ามาก ๆ เพื่อช่วยดึงค่า PR(E) ของเว็บของเราให้สูงขึ้นตามไปด้วย ซึ่งบางเว็บที่อยากให้เว็บตัวเองมีค่า PR(E) สูง ๆ มักทำ spam comment หรือ content ขึ้นมาเพื่อสร้างลิงก์ต่าง ๆ ให้วิ่งเข้าหาเว็บหลักของตัวเอง ซึ่งตาม blog หรือ community มักจะโดย spam กันอยู่ในช่วงหลายปีที่ผ่านมานี้นั้นเองครับ

    ปล. ข้อมูลต่าง ๆ ใน entry นี้เป็นระดับเบื้องต้นครับ การจัด PR(E) ของ Google นั้นมีตัวประกอบอื่น ๆ อีกมากมายครับ แต่ที่ผมนำเสนอนี้เป็นส่วนหลักของการทำงานของ PageRank โดยรวมครับผม

    เอกสารอ้างอิง

    เทคนิคการทำ SEO เบื้องต้นที่ควรรู้ (reloaded)

    การทำ SEO หรือ Search Engine Optimizer นั้นเป็นการทำให้โครงสร้างข้อมูลภายในเว็บของเราที่บรรจุอยู่ใน HTML ของเรา และพวก URL ของเรานั้น มีความหมายและทำให้ Crawler (ซึ่งต่อไปจะขอเรียกเป็น Search Engine เพื่อให้เข้าใจตรงกัน) นั้นสามารถเข้ามาเก็บข้อมูลในเนื้อหาของเราได้ง่าย และตรงกับความต้องการให้ได้มากที่สุด

    ซึ่งโดยปกติแล้วจะแนะนำให้ใช้ XHTML ร่วมกับ CSS โดยที่ XHTML นั้นเป็นส่วนที่ใช้สำหรับใส่ข้อมูลและมี Tag พวก XHTML ต่าง ๆ เข้ามายุ่งเกี่ยวกับเนื้อหาให้น้อยที่สุด โดยมีแต่ส่วนที่กำหนดพื้นที่สำหรับแสดงผลต่าง ๆ เป็นชื่อที่สื่อความหมาย โดยใช้พวก <div> และ <span> แล้วกำหนดพื้นที่ของ Layout ด้วยชื่อที่กำหนดใน id หรือ class และโยนหน้าที่การกำหนด Layout ต่าง ๆ ไปที่ CSS ทั้งหมด เพื่อลดขนาดของไฟล์ HTML ที่ตัว Search Engine จะดึงไปเพื่อทำการ Parse ข้อมูลออกมา ทำให้ Search Engine ใช้เวลาประมวลผลต่าง ๆ ลดลงได้มากด้วย แถมลด B/W ลงไปได้เยอะมาก ๆ ในกรณีที่เว็บของเรานั้นมี Priority ในการเข้ามา index ข้อมูลของ Search Engine สูง ๆ

    เทคนิดง่าย ๆ แต่ได้ผลนั้นผมสรุปจาก Best and Worst practices for designing a high traffic website อีกทีครับ

    1. ใส่ Keywords หลัก ๆ ลงบน Title เพราะเป็นพื้นที่ที่ระบบ Search Engine ใช้ในการเข้ามา index ข้อมูลอันดับแรก ๆ
    2. ใช้ tag Heading (พวก <h*></h*> ต่าง  ๆ) ให้เป็นประโยชน์เพื่อให้ Search Engine นั้นเข้าถึงข้อมูลสำคัญ ๆ ในส่วนนี้ก่อนเสมอ เพราะ Search Engine จะมองว่า Heading เป็นเหมือนหัวหลักของเนื้อหาเพื่อนำไปใช้สรุปเนื้อหาตอนค้นหาต่อไป
    3. ใช้ alt, title, id, class และพวก caption ต่าง ๆ ที่ใช้อธิบายข้อมูลนั้น ๆ เพราะ Search Engine ไม่เข้าในว่ารูปภาพ หรือข้อมูลพวก Binary ต่าง ๆ ว่ามันคืออะไร
      เช่น <img src=”dog.jpg” alt=”Dog jumping into the air” />
    4. ใช้ META Tag ถึงแม้ว่า META Tag จะเป็นเทคนิคเก่า ๆ นับตั้งแต่มี WWW แต่ก็เป็นการดีที่เราควรจะมีไว้ เพราะ Search Engine ยังคงใช้ข้อมูลนี้เพื่อการจัดอับดับข้อมูลของเรา ในกรณีที่ข้อมูลในหน้านั้น ๆ มีมากเกินไป
    5. ใช้ Sitemap โดยการสร้าง Sitemap นั้นมีเครืองมือให้ใช้อยู่มากมาย และยิ่งใช้พวก CMS/Blogware ต่าง ๆ พวก Drupal, WordPress, XOOP, Joomla/Mambo, PHP-nuke ฯลฯ ก็มี module/component/plug-in เข้ามาช่วยสร้าง Sitemap ให้แทบทั้งนั้น โดยประโยชน์ของ Sitemap นั้นช่วยให้ตัว Search Engine นั้นไม่ต้องวิ่งไต่ไปตามลิงส์ต่าง ๆ ของเว็บของเราเพื่อเข้าถึงข้อมูลทั้งหมด และยิ่งเว็บมีขนาดใหญ่และซับซ้อนมาก ๆ ยิ่งทำให้หน้าที่อยู่ในส่วนของรากลึก ๆ ต้นไม้ที่เป็นลำดับของลิงส์นั้นเข้าถึงยาก การมี Sitemap จึงช่วยในการบ่งบอกกับ Search Engine ได้ว่าเว็บของเรามีหลายอะไรอยู่บ้าง เพื่อให้ตัว Search Engine เข้ามา Index ข้อมูลได้รวดเร็วและสะดวกขึ้น
    6. ทำ URL Friendly หรือ Rewrite URL การทำ URL Friendly นั้นช่วยให้ Search Engine เข้าใจ URL ของเราและทำให้การเก็บ URL และแสดงผล URL เพื่อลิงส์กลับมาหน้าต่าง ๆ ของเว็บเรานั้นทำได้ง่ายมากขึ้น

    MySQL with Innodb Performance Optimization (2 and never ending in optimization)

    มาต่อตอนที่ 2 กันครับผม จากตอนที่แล้ว MySQL with Innodb Performance Optimization (1) ตอนนี้ส่วนใหญ่ตัวภาษาอังกฤษค่อนข้างตรงตัวอยู่แล้ว เลยเสริม ๆ ส่วนที่ผมมีประสบการณ์ลงไปบ้างนิดหน่อยครับผม

    Speed up Shutdown

    • Innodb may take very long to shutdown
      • Flushing dirty buffers from buffer pool
    • Increase downtime for upgrades etc
    • innodb_max_dirty_pages_pct
      • Maximum percent of dirty pages
    • SET GLOBAL innodb_max_dirty_pct=0
      • Wait as dirty pages get close to 0, and shut it down

    ตัว innodb นั้นใช้เวลาในการ shutdown ตัวเองนานเพราะต้องมีการเคลียร์พวก memory/connection/buffer_pool ต่าง ๆ ก่อนเสมอ เพื่อป้องกันข้อมูลสูญหายจากการทำ transaction บางอย่างที่ยังไม่เสร็จ หรือยกเลิกทั้ง transaction group ไปเลยก่อน วิธีที่ทำให้ innodb นั้น shutdown ได้เร็วขึ้นก็ใช้การ innodb_max_dirty_pages_pct แล้วตั้งให้เป็น 0 เพื่อไม่ให้มีการเขียน page ใหม่  ๆ ลงใน buffer_pool อีก

    SHOW INNODB STATUS

    • The instrument for understanding what is going on inside InnoDB
    • Partially exported as SHOW STATUS variables in MySQL 5.0
    • Shows statistics about latches, locks, IO, logging activity, row level activity, thread queue activity etc.

    ใช้ SHOW INNODB STATUS เพื่อดูสถิติของระบบ innodb ว่านำมาปรับแต่งอยู่เสมอ ๆ

    InnoDB and Hardware

    • RAID With battery backed up cache may be important.
    • NAS known to cause the problems
    • May have problems scaling with many CPUs
      • Fix on a way
      • Faster CPUs, multiple low end boxes
      • Disabling HyperThreading may be good

    ใช้ RAID ที่มี battery backed up cache ถ้าเป็นไปได้ (เพื่อป้องกันข้อมูลสูญหายในกรณีที่ใช้ RAID) และไม่ควรใช้ NAS ด้วยประการทั้งปวง เพราะถ้า swtich ระหว่าง server กับ storage เดี้ยงทุกอย่างจบ พังยับ ล้มกระจายครับงานนี้ และปิด HyperThreading ซะ แต่จริง ๆ แล้วการทดสอบล่าสุด (Results of Performance Measurements on MySQL 5.0 Using DBT-1: Intel Xeon Dual-Core Version Consideration) พบว่าจะปิดหรือเปิด performance แตกต่างกันแค่ 1% เท่านั้น เพราะปัญหาเรื่อง performance-drop นั้นถูกแก้ไขแล้ว (แนะนำให้อ่านลิส์ดังกล่าวร่วมกับคำแนะนำนี้ครับ) เพื่อใช้ในการปรับแต่งสำหรับเครื่อง Multi-Core/Multi CPU ครับ

    Innodb Aware Schema

    • Use short PRIMARY KEY
      • Long PK make all secondary index larger
    • Have Primary key
      • InnoDB will use internal key anyway
      • And it will be 6 bytes in length
    • Have sequential PRIMARY KEY
      • Non sequential inserts cause fragmentation

    Handling Long PRIMARY KEY

    • If you have long primary key you can promote it to UNIQUE KEY
      • Add auto_increment pseudo_id column and make it primary key
      • Change real primary key to UNIQUE KEY
    • Note: Lookups are slower by secondary key

    Power of PRIMARY KEY

    • PRIMARY KEY is special key in InnoDB
    • PRIMARY KEY lookups are much more efficient
      • Both in memory and IO bound
    • PRIMARY KEY range scans have same speed as full table scans.
    • Joins on PRIMARY KEYs are more efficient
      • Account in schema design

    การออกแบบ Schema (Database Structure) นั้นใช้ข้อมูลที่เป็น PRIMARY KEY ให้สั้นและกระชับ เช่นพวก int ไม่แนะนำให้ใช้ข้อมูลจำพวก String ใด ๆ เพราะทำให้ตัว PRIMARY KEY นั้นใหญ่และการค้นหานานกว่าเดิม และอย่างน้อย ๆ ทุก table ต้องมี PRIMARY KEY อยู่ 1 field เพื่อใช้ในการค้นหา แบบ WHERE/ORDER Cause (เป็นเรื่องปกติในวิชาที่ว่าด้วยเรื่อง Database ของ Computer Science อยู่แล้ว) ใครไม่ทราบว่าทำไมต้อง INDEX ให้ลองคิดถึงการค้นหาหนังสือในห้องสมุดที่ถ้าไม่มี PRIMARY KEY พวก OPAC หรืออย่างเก่า ๆ หน่อยก็ตู้สารบัญหนังสือ (ที่เป็นบัตรเล็ก ๆ เรียงตามอักษรชื่อเรียง) การค้นหาคุณต้องไปนั่งไล่หาตามตู้หนังสือที่ละชั้น หรืออย่างดีที่สุดคือไล่ตามหมวด ซึ่งช้ามาก ๆ ยิ่งห้องสมุดใหญ่เท่าใด ยิ่งหายากเท่านั้น จริง ๆ แล้วตามหลักแล้ว PRIMARY KEY มันก็คือ INDEX รูปแบบหนึ่งนั้นแหละครับ โดยเวลาทำการ Join Tables กันควรใช้พวก INDEX มาทำการ Join กันเสมอ ๆ

    No Key Compression

    • InnoDB does not have key compression
      • As MyISAM does
    • InnoDB Indexes can be 10 times larger than MyISAM indexes
      • One of the reasons InnoDB tables generally take 2-3 times more space
    • Be easy on indexes
    • May be fixed by gzip page compression

    ตัว innodb ไม่มี key compression เหมือนกับ MyISAM (ซึ่งเป็นต้นเหตุให้บางครั้งมันช้า) ทำให้มันเสียเวลา scan ตัว index นานกว่า MyISAM ถึง 10 เท่า (แต่ปกติจะอยู่ที่ 2-3 เท่า)

    Power of clustering

    • Get benefit of clustering by primary key
    • Messages Table
      • Primary key(user_id,message_id)
      • Very fast to get all messages for given user
      • Would be even better with multi column auto_increment key support
    • General rule: data which you need together to have close PK values

    Table Fragmentation

    • InnoDB tables fragment over time
    • Rows are not fragmented but pages can be scattered
      • Less of the problem because of large pages
    • OPTIMIZE TABLE to rebuild the table
      • Slow (no index rebuilt by sort)
      • Blocks whole table during operation
      • Master-Master replication may help

    High Performance Backup

    • Use physical level backup
      • Logical level backup is very slow to recover
      • But do NOT copy files with database running
    • Innodb Hot Level Backup
      • Commercial solution
    • LVM/Snapshot based backup
      • About same performance but free
      • Requires specific OS Setup

    Blob handling

    • InnoDB can skip reading blobs if they are not in select column list
      • Makes sense to keep blobs in the same table
    • Blobs stored each at separate page(s) if it does not fit to the page
      • Consuming at least 1 page
    • Blobs are allocated in new space on update.

    Avoid count(*) without where

    • SELECT COUNT(*) FROM TBL
      • Instant for MyISAM, Memory etc
      • Slow for InnoDB
        • Performs table/index scan
    • Try to avoid
      • SHOW TABLE STATUS LIKE ‘table’
        • Approximate number of rows
      • Counter table for exact number of rows

    Innodb Row count

    • Count of rows is inaccurate
      • And guessed for each query execution
        • Using random BTREE dives
      • Can cause fluctuating plans
      • May be problem hard to catch.
    • OPTIMIZE TABLE may help row count estimation accuracy

    Innodb Statistics

    • Cardinality values computed using BTREE dives as well
      • Can also be inaccutrate
    • Computed first time table is opened after start
      • Make first table open rather slow
    • ANALYZE TABLE forces refresh
      • Using same estimation method

    ถ้าจะนับข้อมูลให้ใช้การ SHOW TABLE STATUS LIKE ‘tablename’ แทนการใช้ SELECT COUNT(*) FROM ‘tablename’ ถึงแม้บน MyISAM จะเร็ว แต่บน innodb กลับช้า จริง ๆ ส่วนนี้สามารถแก้ไขด้วยการใช้ query-cache แต่ถ้ามีการ update index ใหม่เข้าไปก็ต้องนับใหม่อีกทีซึ่งก็ยังช้าอยู่ดีครับ โดยการใช้ SHOW TABLE STATUS LIKE ‘tablename’ นั้นเป็นการดึงข้อมูลตัว counter มาจาก information_schema นั้นเอง และจริง ๆ แล้วถ้าต้องการรายละเอียดข้อมูลของ schema เพื่อเอาไปใช้งานด้าน ORM (Object-Relational mapping) ให้ใช้ข้อมูลใน information_schema เข้ามาช่วยได้เช่นกัน (จริง ๆ การมีตาราง information_schema นั้นเป็นไปตามข้อกำหนดของ ANSI/ISO SQL:2003 standard ใน Part 11 Schemata) ใน information_schema นั้นจะบอกทั้งโครงสร้างของแต่ละตารางและความสัมพันธ์ต่าง ๆ ทั้งหมด ช่วยให้ทำพวก tools หรือ program พวก automatic-generate SQL command ได้ดีมาก ๆ

    สำหรับเรื่อง Optimization นี่ไม่มีที่สิ้นสุด และไม่มีอะไรที่ถูกที่สุดครับ การทำต้องทดสอบเสมอ และควรทดสอบและตรวจสอบว่าสิ่งที่เรา optimize ลงไปนั้นยังใช้งานได้ดีอยู่หรือไม่ และควรปรับแต่งอยู่เสมอ และในทางกลับกัน เมื่อระบบออก major/minor-release ใหม่ ๆ ออกมาควรทำการศึกษา release-note ทุกครั้งก่อนการ upgrade เสมอ เพราะอาจจะกระทบต่อ performance และสิ่งที่เรา optimize ลงไปอาจจะใช้ไม่ได้ผลในตอนที่เรา upgrade ไปแล้วก็ได้ จึงเป็นเรื่องที่ต้องทำอยู่สม่ำเสมอครับ