MySQL เป็นร้านค้าที่สั่งคีย์-ค่า

เอกสารบอกว่า:

ดัชนี MySQL ส่วนใหญ่ (คีย์หลัก, UNIQUE, INDEX และ FULLTEXT) จะถูกจัดเก็บไว้ใน B-tree

ดังนั้นทางกายภาพแล้วข้อมูลจึงถูกจัดเรียงตามคีย์แล้ว ฉันต้องการรูปแบบคีย์-ค่าใน MySQL พร้อมรองรับการสืบค้นช่วง: SELECT key, value FROM MyTable WHERE key >= key1 and key < key2;

ในตัวอย่างจำนวนมาก (ส่วนใหญ่) บนเว็บ ฉันเห็นว่าผู้คนเพิ่ม ORDER BY แม้ว่าจะเลือกด้วยคีย์หลักก็ตาม

คำถามของฉัน:

  • ORDER BY จำเป็นจริงๆ ไหมที่นี่เพื่อให้ได้ผลลัพธ์ที่เรียงลำดับอยู่เสมอ และถ้าใช่ - เพราะเหตุใด
  • การเรียงลำดับจะส่งผลต่อประสิทธิภาพหรือจะถูกปรับให้เหมาะสมหรือไม่
  • มันจะสมเหตุสมผลหรือไม่ถ้าจะทำให้ค่าเป็นส่วนหนึ่งของดัชนีคอมโพสิต หากค่าเหล่านั้นไม่ใหญ่เกินไป เช่น แค่ตัวเลขเหรอ?
  • SELECT key, value FROM MyTable WHERE key > key1 LIMIT 1; จะส่งคืนคีย์ถัดไปที่มากกว่า key1 หรือคีย์ใดๆ ที่มากกว่า key1 หรือไม่ จะรับแบบสอบถามจุด LT, LE, GT, GE ได้อย่างน่าเชื่อถือได้อย่างไร

(ฉันต้องการมันใน MySQL ด้วยเหตุผล 'ทางการเมือง' และเครื่องมือก่อนที่จะย้ายไปยังที่เก็บข้อมูล KV ที่ใช้ B+-tree อื่นที่มีอยู่ ฉันได้เลือก LMDB ที่ดีที่สุดแล้ว ดังนั้นคำถามเกี่ยวกับการเยาะเย้ยโครงการใน MySQL เท่านั้น)


person V.B.    schedule 23.03.2015    source แหล่งที่มา
comment
ถ้าเป็นในเว็บก็ต้องเป็นเรื่องจริง ;)   -  person nomistic    schedule 23.03.2015
comment
@การเสียดสีแบบ nomistic? :) หลังจาก googling และเห็นตัวอย่างมากมาย ฉันต้องการการตรวจสอบสุขภาพจิตจริงๆ   -  person V.B.    schedule 23.03.2015
comment
ฉันไม่ใช่ผู้เชี่ยวชาญที่นี่ ดังนั้นฉันจะหลีกเลี่ยงการตอบคำถามจริงๆ แต่การใช้คำสั่ง order by ควรมีผลกระทบที่เป็นกลางหรือเชิงลบต่อข้อความค้นหานี้เสมอ ในคอลัมน์ที่ไม่ได้จัดทำดัชนี การเรียงลำดับตัวพิมพ์ที่ดีที่สุดจะเป็น O(n log n) เสมอ ในขณะที่การตรวจสอบทุกบันทึกด้วยการสแกนตารางแบบเต็มจะเป็น O(n) ในคอลัมน์ที่จัดทำดัชนีซึ่งจัดเก็บไว้ใน B-Tree การเรียงลำดับจะไม่มีผลใดๆ หากใช้ตัวดำเนินการเปรียบเทียบเดียวกัน และจะส่งผลเสียหากใช้ตัวดำเนินการอื่น   -  person Nick Bailey    schedule 23.03.2015
comment
ใช่ขอโทษ. ความเข้าใจของฉันในส่วนแรกคือมันเกิดจากนิสัยและการฝึกเขียนโค้ดที่ดี (มันจะสมเหตุสมผลถ้าไม่ใช่คีย์หลัก) นอกจากนี้ บางครั้งคีย์หลักก็ไม่ใช่ตัวเลข (เช่นตัวแปรประเภท type_code... ฉันใช้สิ่งเหล่านี้เป็นจำนวนมากสำหรับตารางที่มีการควบคุมระดับหนึ่งเพื่อเพิ่มความสะดวกในการสืบค้น แต่ในกรณีนั้นฉันมักจะสั่งโดย ค่า ไม่ใช่โค้ด) บางครั้งฉันจะสั่งสองรายการ ขออภัย ฉันไม่รู้เกี่ยวกับประสิทธิภาพ แต่ฉันเดาว่ามันน้อยมาก ไม่มีความคิดเกี่ยวกับส่วนสุดท้าย   -  person nomistic    schedule 23.03.2015


คำตอบ (1)


  • #P1#
    #P2# #P3#
  • #P4#
    #P5# #P6# #P7#
  • #P8#
    #P9# #P10#
  • #P11#
    #P12# #P13#
    SELECT key, value FROM MyTable WHERE key > key1 ORDER BY key LIMIT 1
    
    #P14#
    SELECT key, value FROM MyTable WHERE key <= key1 ORDER BY key DESC LIMIT 1
    
person eggyal    schedule 23.03.2015
comment
ขอบคุณ! ฉันต้องการความถูกต้องก่อน - เพื่อให้ค่าเรียงลำดับตามคีย์เสมอ (ฉันได้อัปเดตคำถามและเพิ่มคำถามย่อยอื่น - คุณช่วยแสดงความคิดเห็นกับคำถามที่ 4 ได้ไหม) ในเวลาเดียวกัน ฉันไม่ต้องการทำอะไรโง่ๆ เพื่อที่ว่าในระหว่างการสืบค้น ลำดับที่มีอยู่ของ B-tree จะถูกทำลาย และฉันจะต้องสมัคร ORDER BY อีกครั้งพร้อมค่าโสหุ้ยของมัน การเยาะเย้ยนี้สำหรับเวลาออกแบบเป็นหลัก แต่ปริมาณข้อมูลยังไม่ใหญ่มากและ MySQL ก็อาจเพียงพอในระยะยาว ฉันแค่ต้องซ่อนพื้นที่เก็บข้อมูลไว้ด้านหลังอินเทอร์เฟซและรับพฤติกรรมแบบเดียวกับ B-tree ธรรมดาทุกประการ น่าแปลกที่ MySQL ซ่อนมันไว้ - person V.B.; 23.03.2015
comment
เจ๋งเลย ขอบคุณมาก! แค่อยากรู้อยากเห็น สำหรับจุดที่ 4 คุณคิดว่าเช่น InnoDB เครื่องมือเพิ่มประสิทธิภาพฉลาดพอที่จะทำการค้นหาแบบไบนารี่และเลื่อนถัดไป/ก่อนหน้า แทนที่จะเลือกคีย์ที่มากขึ้น/น้อยลงทั้งหมด จากนั้นเรียงลำดับคีย์เหล่านั้นแล้วจึงเลือกคีย์แรก หรือ EXPLAIN จะแสดงสิ่งนี้เช่นกัน? - person V.B.; 23.03.2015
comment
@V.B.: ดูการเพิ่มประสิทธิภาพ LIMIT Queries—หากคุณรวม LIMIT row_count กับ ORDER BY MySQL สิ้นสุดการเรียงลำดับทันทีที่พบ row_count แถวแรกของผลลัพธ์ที่เรียงลำดับ แทนที่จะเรียงลำดับผลลัพธ์ทั้งหมด หากการสั่งซื้อเสร็จสิ้นโดยใช้ดัชนี จะรวดเร็วมาก...ทันทีที่ MySQL ส่งแถวตามจำนวนที่ต้องการไปยังไคลเอนต์แล้ว ระบบจะยกเลิกการสืบค้นเว้นแต่คุณจะใช้ SQL_CALC_FOUND_ROWS - person eggyal; 23.03.2015