ต่อไป »

[MapTwoZa]

table scan อย่างเยอะ -*-

join ไม่ index ก็มี (ถึงย้ำไงครับว่าควรมี FK Constraints ฮ่าๆ)

ทำ index ให้ว่องครับ

แล้วไล่ดู query ด้วยครับ พวก like '%xxx%' เนี่ย index ไม่ช่วย มันต้อง table scan ซึ่งช้าและเปลืองมากกกกกกกกกกกกกก


ปล. select_scan ไม่จำเป็นต้อง 0 นะครับ แต่ก็ต้องไม่เยอะขนาดนี้ (แต่ต้องรู้ด้วยว่าไอที่ไม่เป็น 0 เพราะ query ตัวไหน ซึ่งบางทีเราไม่จำเป็นต้องทำ index ให้มันครับ)

[postmunnet]

table scan อย่างเยอะ -*-

join ไม่ index ก็มี (ถึงย้ำไงครับว่าควรมี FK Constraints ฮ่าๆ)

ทำ index ให้ว่องครับ

แล้วไล่ดู query ด้วยครับ พวก like '%xxx%' เนี่ย index ไม่ช่วย มันต้อง table scan ซึ่งช้าและเปลืองมากกกกกกกกกกกกกก


ปล. select_scan ไม่จำเป็นต้อง 0 นะครับ แต่ก็ต้องไม่เยอะขนาดนี้ (แต่ต้องรู้ด้วยว่าไอที่ไม่เป็น 0 เพราะ query ตัวไหน ซึ่งบางทีเราไม่จำเป็นต้องทำ index ให้มันครับ)

เรื่อง db ตอนนี้งงๆ มากครับทั้งในส่วนของ FK ในส่วนของการทำ index ส่วน

like '%xxx%' มีข้อแนะนำไหมครับ พอดีผมทำระบบ tag เข้ามาน่ะครับซึ่งไอ้ตัวนี้ผมเยอะมากเลยครับ
เพราะผมเอา title มา split แล้วไล่ select relate ออกมา นั่นแสดงว่าในแต่ละหน้า
ผมมีไอ้ตัวนี้ไม่ต่ำกว่า 5 แน่ สงสัยว่าช้าๆ เพราะไอ้ตัวนี้แน่เลย (ปิดไปก่อนเรียบร้อยครับ จนกว่าจะเจอวิธีที่ดีกว่านี้)
ดูแล้วผมควรเปลี่ยน engine ด้วยใช่ไหมครับเป็น innodb น่าจะดีกว่าเหรือเปล่าครับ

[joei]

table scan ใช้กับ table เล็กๆ (ประมาณ 100 แถว)
ไม่มีปัญหานะครับ บางทีเร็วกว่า index ด้วยครับ แต่ถ้า table ใหญ่มากๆ จะช้าครับ

like '%word%'; ของระบบ tag แนะนำให้ลองทำ 3 table
article
article_id
title
..

tag
tag_id
tag_word

article_tag
article_id
tag_id

พยายามลดการ update นะครับ พยายามตรวจสอบข้อมูลโดยการ select มาตรวจสอบก่อน
และ update เฉพาะส่วนที่ไม่เหมือนกันครับ ลดภาระฐานข้อมูล

ถ้าจะต้อง insert จำนวนมาก ลองปิด AUTOCOMMIT ดูครับ แล้วรัน INSERT ให้ครบก่อน
แล้วค่อย COMMIT ครับ

พยายามลด INDEX ที่ไม่จำเป็น โดยเฉพาะ Table ที่จะต้อง UPDATE บ่อยๆ เพราะทุกครั้งที่
INSERT หรือ UPDATE จะต้องปรับ Index ใหม่ด้วยทุกครั้ง

ใช้ INNODB ก็ดีครับ ใช้ตัวเลือก innodb_file_per_table ด้วยนะครับ

ถ้าใช้ apache ลองเปลี่ยนเป็น nginx ดูครับ เผื่อจะใช้แรมน้อยกว่านี้

MySQL ไม่ควร Restart นะครับ เพราะว่าจะต้องทำให้ต้อง Buffer ข้อมูลใหม่ทั้งหมด

ลอง Log Slow Query ดูครับ จะได้ทราบว่า Query ตัวไหนที่ทำงานนานและ Lock Table

[postmunnet]

table scan ใช้กับ table เล็กๆ (ประมาณ 100 แถว)
ไม่มีปัญหานะครับ บางทีเร็วกว่า index ด้วยครับ แต่ถ้า table ใหญ่มากๆ จะช้าครับ

like '%word%'; ของระบบ tag แนะนำให้ลองทำ 3 table
article
article_id
title
..

tag
tag_id
tag_word

article_tag
article_id
tag_id

พยายามลดการ update นะครับ พยายามตรวจสอบข้อมูลโดยการ select มาตรวจสอบก่อน
และ update เฉพาะส่วนที่ไม่เหมือนกันครับ ลดภาระฐานข้อมูล

ถ้าจะต้อง insert จำนวนมาก ลองปิด AUTOCOMMIT ดูครับ แล้วรัน INSERT ให้ครบก่อน
แล้วค่อย COMMIT ครับ

พยายามลด INDEX ที่ไม่จำเป็น โดยเฉพาะ Table ที่จะต้อง UPDATE บ่อยๆ เพราะทุกครั้งที่
INSERT หรือ UPDATE จะต้องปรับ Index ใหม่ด้วยทุกครั้ง

ใช้ INNODB ก็ดีครับ ใช้ตัวเลือก innodb_file_per_table ด้วยนะครับ

ถ้าใช้ apache ลองเปลี่ยนเป็น nginx ดูครับ เผื่อจะใช้แรมน้อยกว่านี้

MySQL ไม่ควร Restart นะครับ เพราะว่าจะต้องทำให้ต้อง Buffer ข้อมูลใหม่ทั้งหมด

ลอง Log Slow Query ดูครับ จะได้ทราบว่า Query ตัวไหนที่ทำงานนานและ Lock Table

เข้าใจละครับเดี๋ยวลองปรับดูครับ  ขอบคุณทุกท่านที่เข้ามาให้ความช่วยเหลือครับ

[ohmohm]

ขอบคุณทุกท่านมากครับ การทำ index ผมยังงงๆ นะครับ การทำ index อันเดียวอย่าง index(a) index(b) กับการทำ index(a,b) มันไม่เหมือนกันใช่ไหมครับ

ประมาณว่า ผม where a=1 ตัวเดียวก็ทำ index(a) แล้วถ้าผม where a=1,b=2 จะต้องทำ index(a) index(b) หรือ index(a,b) ครับ
เท่าที่อ่านมาเหมือนกับว่าตัวเล็กตัวใหญ่ก็มีผลด้วยนะ แล้วการเรียงซ้ายไปขวาก็มีผลให้ทำงานหรือไม่เช่นกัน ผมเข้าใจถูกต้องไหมครับ


ส่วน memcache เดี๋ยวลองศึกษาดูครับ ยังทำไม่ค่อยเป็น

ถ้ามี index(a) แ้ลวค้นด้วย where a=1 ก็สามารถใช้ประโยชน์จาก index(a) ในการทำ index seek แทนการทำ table scan
ถ้ามี index(a, b) แ้ลวค้นด้วย where a=1 หรือ where a=1 and b=1 ก็จะได้ประโยชน์จาก index(a, b) ครับ แต่ where b=1 จะไม่ได้ประโยชน์นะครับ เพราะ index คือดัชนีค้นหาที่เก็บข้อมูลแบบเรียงไว้แล้วเพื่อค้นหาได้เร็ว (มักเป็นโครงสร้างข้อมูลแบบ B-tree ทำให้การค้นหาที่ช้าแบบ O(n) เปลี่ยนไปเร็วแบบ O(log(n))) a, b คือเอาทั้งสองตัวมาเรียงกัน เหมือนดัชนีค้นหาในสมุดโทรศัพท์ที่เรียงตามชื่อแล้วนามสกุล เอานามสกุลไปค้นย่อมไม่ได้

[MapTwoZa]

table scan ใช้กับ table เล็กๆ (ประมาณ 100 แถว)
ไม่มีปัญหานะครับ บางทีเร็วกว่า index ด้วยครับ แต่ถ้า table ใหญ่มากๆ จะช้าครับ

ใช่เลยครับ

ผมเลยพยายามย้ำว่า ไม่จำเป็นอย่าทำ index ครับ
ทำแต่ตัวที่จำเป็น

ไม่ต้อง table เล็กหรอกครับ table ใหญ่ถ้าทำ index มั่ว มันก็ช้า 555

ถึงมันจะหลักพัน แต่ถ้ามีการเรียกใช้น้อย ผมก็ปล่อยครับ
แล้ว data ธรรมชาติ มันจะ relate กันอยู่แล้ว แค่ทำ FK Constraints ก็ครอบคลุมกว่าครึ่งนึงของ query แล้วด้วยซ้ำ


index มันก็เหมือนดาบสองคม ไปในตัวนะ

ปรกติ ผมจะทำ index เฉพาะพวก data ที่มันโดน frequency access หรือไม่ก็ performance critical หรือไม่ก็ data มันเยอะจริงๆแล้วมีการเรียกใช้เรื่อยๆมันก็จำเป็นต้องทำ
จะว่าไป การทำ index นี่มันทั้ง ศาสตร์และศิลป์ เลยมั้ง 555 ต้องวิเคราห์ case by case ครับ

เรื่อง db ตอนนี้งงๆ มากครับทั้งในส่วนของ FK ในส่วนของการทำ index ส่วน

like '%xxx%' มีข้อแนะนำไหมครับ พอดีผมทำระบบ tag เข้ามาน่ะครับซึ่งไอ้ตัวนี้ผมเยอะมากเลยครับ
เพราะผมเอา title มา split แล้วไล่ select relate ออกมา นั่นแสดงว่าในแต่ละหน้า
ผมมีไอ้ตัวนี้ไม่ต่ำกว่า 5 แน่ สงสัยว่าช้าๆ เพราะไอ้ตัวนี้แน่เลย (ปิดไปก่อนเรียบร้อยครับ จนกว่าจะเจอวิธีที่ดีกว่านี้)
ดูแล้วผมควรเปลี่ยน engine ด้วยใช่ไหมครับเป็น innodb น่าจะดีกว่าเหรือเปล่าครับ

ก็อย่างที่บอกๆไปแหละครับ เคสทั่วไป innodb ดีกว่าอยู่แล้ว (ข้อเสียสุดๆของ myisam คือมันทำ fk constrants ไม่ได้)
ถ้าต้องการเรื่อง search แบบนั้น ต้องใช้การเก็บ + หาข้อมูลด้วยการ tokenization ครับ

ใน PHP มันจะมี Zend Lucene ถ้าใช้ composer ก็ require zendframework/zend-search มั้ง
แต้ถ้าข้อมูลเป็นภาษาไทยก็ต้องเขียน tokenizer เองครับ หรือลอง google ดู เผื่อมีคนเขียนไว้แล้ว

ไม่ก็ไปใช้ Apache Lucene ครับ น่าจะมี tokenizer ของภาษาไทยให้
แต่มันเป็น java คงต้องเขียนเป็น web service เอา

[postmunnet]

table scan ใช้กับ table เล็กๆ (ประมาณ 100 แถว)
ไม่มีปัญหานะครับ บางทีเร็วกว่า index ด้วยครับ แต่ถ้า table ใหญ่มากๆ จะช้าครับ

ใช่เลยครับ

ผมเลยพยายามย้ำว่า ไม่จำเป็นอย่าทำ index ครับ
ทำแต่ตัวที่จำเป็น

ไม่ต้อง table เล็กหรอกครับ table ใหญ่ถ้าทำ index มั่ว มันก็ช้า 555

ถึงมันจะหลักพัน แต่ถ้ามีการเรียกใช้น้อย ผมก็ปล่อยครับ
แล้ว data ธรรมชาติ มันจะ relate กันอยู่แล้ว แค่ทำ FK Constraints ก็ครอบคลุมกว่าครึ่งนึงของ query แล้วด้วยซ้ำ


index มันก็เหมือนดาบสองคม ไปในตัวนะ

ปรกติ ผมจะทำ index เฉพาะพวก data ที่มันโดน frequency access หรือไม่ก็ performance critical หรือไม่ก็ data มันเยอะจริงๆแล้วมีการเรียกใช้เรื่อยๆมันก็จำเป็นต้องทำ
จะว่าไป การทำ index นี่มันทั้ง ศาสตร์และศิลป์ เลยมั้ง 555 ต้องวิเคราห์ case by case ครับ

เรื่อง db ตอนนี้งงๆ มากครับทั้งในส่วนของ FK ในส่วนของการทำ index ส่วน

like '%xxx%' มีข้อแนะนำไหมครับ พอดีผมทำระบบ tag เข้ามาน่ะครับซึ่งไอ้ตัวนี้ผมเยอะมากเลยครับ
เพราะผมเอา title มา split แล้วไล่ select relate ออกมา นั่นแสดงว่าในแต่ละหน้า
ผมมีไอ้ตัวนี้ไม่ต่ำกว่า 5 แน่ สงสัยว่าช้าๆ เพราะไอ้ตัวนี้แน่เลย (ปิดไปก่อนเรียบร้อยครับ จนกว่าจะเจอวิธีที่ดีกว่านี้)
ดูแล้วผมควรเปลี่ยน engine ด้วยใช่ไหมครับเป็น innodb น่าจะดีกว่าเหรือเปล่าครับ

ก็อย่างที่บอกๆไปแหละครับ เคสทั่วไป innodb ดีกว่าอยู่แล้ว (ข้อเสียสุดๆของ myisam คือมันทำ fk constrants ไม่ได้)
ถ้าต้องการเรื่อง search แบบนั้น ต้องใช้การเก็บ + หาข้อมูลด้วยการ tokenization ครับ

ใน PHP มันจะมี Zend Lucene ถ้าใช้ composer ก็ require zendframework/zend-search มั้ง
แต้ถ้าข้อมูลเป็นภาษาไทยก็ต้องเขียน tokenizer เองครับ หรือลอง google ดู เผื่อมีคนเขียนไว้แล้ว

ไม่ก็ไปใช้ Apache Lucene ครับ น่าจะมี tokenizer ของภาษาไทยให้
แต่มันเป็น java คงต้องเขียนเป็น web service เอา

ขอบคุณครับเดี๋ยวผมลองทำดูครับ

[postmunnet]

update ความคืบหน้าหน่อยครับ
พอผมเปลี่ยน table จาก MyISAM เป็น InnoDB
เอา text select scan ออก (เดี๋ยวยังไงก็ต้องทำ แต่จะออกแบบใหม่)
นั่งมอง long time log
เอา index ใส่ลงไปใน where ที่ขึ้นใน long time log
แก้จุดผิดใน select โดยเอา '' ออก เพราะไอ้ที่ผม where มันเป็น int ไม่ใช่ string
ไม่ต้องมี ''

ตอนนี้วิ่งฉิวๆ เลยครับ

ขอบคุณทุกท่านเลยครับ แต่ผมยังไม่หยุดเท่านี้นะครับ ยังคงจะเดินหน้าเรื่อง optimize ต่อไป

[joei]

update ความคืบหน้าหน่อยครับ
พอผมเปลี่ยน table จาก MyISAM เป็น InnoDB
เอา text select scan ออก (เดี๋ยวยังไงก็ต้องทำ แต่จะออกแบบใหม่)
นั่งมอง long time log
เอา index ใส่ลงไปใน where ที่ขึ้นใน long time log
แก้จุดผิดใน select โดยเอา '' ออก เพราะไอ้ที่ผม where มันเป็น int ไม่ใช่ string
ไม่ต้องมี ''

ตอนนี้วิ่งฉิวๆ เลยครับ

ขอบคุณทุกท่านเลยครับ แต่ผมยังไม่หยุดเท่านี้นะครับ ยังคงจะเดินหน้าเรื่อง optimize ต่อไป

ลองดูตัวแปรเหล่านี้ดูนะครับ
- InnoDB Thread Concurrent ไม่ควรมากกว่าจำนวน 2 เท่าของ CPU ในกรณีของคุณมี 1 CPU ก็ควรจะมี 2 Thread
- การใช้หน่วยความจำ Buffer Pool สำหรับ InnoDB แล้ว Buffer Pool สำคัญมาก ผมแนะนำ 512MB สำหรับคุณ
- การเลือกใช้ Charactor Set ปกติแล้ว utf8_general_ci จะเร็วกว่า utf8_unicode_ci

[postmunnet]

update ความคืบหน้าหน่อยครับ
พอผมเปลี่ยน table จาก MyISAM เป็น InnoDB
เอา text select scan ออก (เดี๋ยวยังไงก็ต้องทำ แต่จะออกแบบใหม่)
นั่งมอง long time log
เอา index ใส่ลงไปใน where ที่ขึ้นใน long time log
แก้จุดผิดใน select โดยเอา '' ออก เพราะไอ้ที่ผม where มันเป็น int ไม่ใช่ string
ไม่ต้องมี ''

ตอนนี้วิ่งฉิวๆ เลยครับ

ขอบคุณทุกท่านเลยครับ แต่ผมยังไม่หยุดเท่านี้นะครับ ยังคงจะเดินหน้าเรื่อง optimize ต่อไป

ลองดูตัวแปรเหล่านี้ดูนะครับ
- InnoDB Thread Concurrent ไม่ควรมากกว่าจำนวน 2 เท่าของ CPU ในกรณีของคุณมี 1 CPU ก็ควรจะมี 2 Thread
- การใช้หน่วยความจำ Buffer Pool สำหรับ InnoDB แล้ว Buffer Pool สำคัญมาก ผมแนะนำ 512MB สำหรับคุณ
- การเลือกใช้ Charactor Set ปกติแล้ว utf8_general_ci จะเร็วกว่า utf8_unicode_ci

ขอบคุณครับเดี๋ยวจะเข้าไปตั้งค่าดูครับ