ทำไมตาราง wp_options` จึงไม่มีดัชนีบน "autoload"

ในตอนต้นของแต่ละหน้าเสิร์ฟโดย WordPress มีการเรียก MySQL เพื่อดึงข้อมูลตัวเลือก:

SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes';

เนื่องจากไม่มีดัชนีในautoloadคอลัมน์ MySQL จึงต้องค้นหาแถวทั้งหมด

ฉันเจอความคิดเห็นของคำตอบนี้ด้วยว่าจะไม่มีการเพิ่มประสิทธิภาพแม้ว่าจะมีดัชนีก็ตาม

ในใบสมัครของฉันฉันใช้ค่าชั่วคราวจำนวนมากเพื่อทำหน้าที่แทนเซสชัน พวกเขาทำงานได้ดีและฉันมีกิจวัตรการเก็บขยะของตัวเอง ผมสังเกตเห็นว่าในwp_optionsตารางค่าชั่วคราวของฉัน (คนที่เริ่มต้นด้วย_transient_) autoload=noทุกคนมี ฉันคาดว่าจำนวนแถวของwp_optionsตารางของฉันจะเพิ่มขึ้นตามจำนวนผู้ใช้ที่เกิดขึ้นพร้อมกันเพิ่มขึ้น

ฉันต้องการที่จะรู้ว่าทำไมตารางถูกออกแบบด้วยวิธีนี้ และฉันควรสร้างดัชนีสำหรับกรณีเฉพาะของฉันหรือไม่

ไม่มีดัชนีเพราะความต้องการมันไม่แข็งแกร่งพอ

ในตั๋ว # 14258แนะนำ แต่เนื่องจากตัวเลือกส่วนใหญ่ใช้autoload=yesโดยค่าเริ่มต้นดัชนีจะถูกละเว้นอยู่ดี

นอกจากนี้ยังมียังคงเปิดตั๋ว# 24044 ดัชนี _Add เพื่อ wp_options ช่วยเหลือ / ปรับปรุง performance_

ฉันคิดว่าคุณควรสร้างดัชนี มันจะอยู่รอดการอัพเกรด อาจไม่ช่วยให้ประสิทธิภาพของคุณ แต่คุณสามารถเพิ่มข้อมูลสถิติจริงลงในตั๋วได้

อัปเดตพฤศจิกายน 2019

ดัชนีได้ถูกเพิ่มใน WordPress 5.3 แล้ว ในที่สุด ดูตั๋ว # 24044 ดังกล่าวข้างต้นและบันทึกนักพัฒนาสำหรับการปล่อย

โปรดทราบว่าหากคุณมีดัชนีที่มีชื่อเดียวกันคุณจะได้รับคำเตือนในระหว่างการอัพเกรด

จากเซ็ตการแก้ไข :

ไซต์ส่วนใหญ่จะไม่ได้รับผลกระทบจากการเปลี่ยนแปลงนี้ แต่ไซต์ที่มีจำนวนแถวwp_optionsมากจะมีเพียงจำนวนน้อยที่autoloadกำหนดไว้เท่านั้นที่จะเห็นการปรับปรุงประสิทธิภาพที่สำคัญ
เว็บไซต์ที่มีจำนวนแถวwp_optionsมากโดยที่หลาย ๆ คนautoloadตั้งค่าไว้จะเห็นโทษด้านประสิทธิภาพของการสืบค้นที่ช้ามากซึ่งพวกเขากำลังทำงานอยู่ แต่สิ่งเหล่านี้น่าจะเป็นส่วนน้อย

ฉันใช้งานบล็อก 3 WP บน Debian Squeeze อินสแตนซ์ขนาดใหญ่และกำลังตรวจสอบว่าทำไม mysql ติดอยู่บนโฮสต์นั้นที่การใช้งาน CPU 200% และโหลดระบบระหว่าง 3 ถึง 6 ดูที่ 'รายการกระบวนการแสดง' ภายใน mysql เราเข้าใจ ตาราง wp_option เกี่ยวข้องกับปัญหานี้ดังนั้นเราจึงดำเนินการ:

alter table wp_options add index autoload_idx(`autoload`);

หลังจากการดำเนินการโหลด mysql ดังที่แสดงไว้ด้านบนลดลงอย่างมากถึง 1% และค่าเฉลี่ยการโหลดอินสแตนซ์ตอนนี้คือ 0.10

เรากำลังใช้ปลั๊กอินบางตัวเพื่อให้มีการวนซ้ำบางส่วนในรหัสและนี่อาจเป็นสถานการณ์เฉพาะ แต่ในกรณีของเราการเปลี่ยนแปลงของการแสดงนั้นน่าประหลาดใจอย่างมาก

ตาราง wp_options ของเรามี 347 แถว

ในขณะที่@fuxia ตอบรับการสัมผัสด้วยเหตุผล "อ้างสิทธิ์" (ซึ่งส่วนใหญ่ถูกอ้างสิทธิ์โดยพนักงานของ Automattic ในตั๋ว Trac ต่าง ๆ ฯลฯ ) เหตุผลพื้นฐานสำหรับ WordPress Core ไม่รวมดัชนีสำหรับตัวเลือก autoload ภายในwp_optionsตารางคือ Automattic กังวลว่าจะส่งผลเสียต่อประสิทธิภาพการทำงานของฐานข้อมูล MySQL ที่ยังคงใช้เครื่องมือ MyISAM

โดยเฉพาะพวกเขาชี้ไปที่เว็บไซต์ WordPress.org ซึ่งเป็นฐานข้อมูลที่เก่ามาก / ซับซ้อนเป็นเว็บไซต์ตัวอย่างที่ดัชนีประสิทธิภาพดังกล่าวได้รับผลกระทบ

เกือบทุกเหตุผลอื่น ๆ ที่ไม่เพิ่มดัชนีในช่วง 9 ปีที่ผ่านมา (ใช่ตั้งแต่ปี 2010 ในกรณีของ Trac ticket # 14258และตั้งแต่ปี 2013 ในกรณีของ Trac ticket # 24044 ) ได้รับการพิสูจน์ซ้ำแล้วซ้ำหลายครั้งโดยสมาชิกหลายสิบคนของ ชุมชน WordPress แต่พนักงาน Automattic ที่เกี่ยวข้องซ้ำ ๆ ได้เพิกเฉยต่อการทดสอบเกณฑ์มาตรฐานอิสระหลายครั้งและย้อนกลับไปที่การกล่าวถึง MyISAM

โชคดีที่ในช่วงปลายปี 2019 กับPHP 7.2ตอนนี้เป็นรุ่น "เริ่มต้น" ที่แนะนำโดย WordPress Core และด้วยเครื่องมือ InnoDB ตอนนี้เริ่มต้นในรุ่นของMySQL หลังจาก 5.5และด้วยแรงกดดันอย่างต่อเนื่องจากนักพัฒนาหลายคนรวมถึง @DanBUK ในที่สุด Automattic ก็ให้และตัดสินใจที่จะเพิ่มดัชนี autoload ตั้งแต่ WordPress 5.3+ ในเดือนพฤศจิกายน 2019

พวกเราที่ LittleBizzy ได้เปิดตัวปลั๊กอินที่รู้จักครั้งแรกที่เพิ่มดัชนีโดยอัตโนมัติหากไม่มีอยู่ซึ่งยังคงมีอยู่ใน GitHub และดาวน์โหลดเป็นประจำ โปรดทราบว่าคุณไม่จำเป็นต้องติดตั้งปลั๊กอินดังกล่าวลงในสแต็ก WordPress ของคุณหากคุณใช้ WP Core 5.3 + ...