মাইএসকিউএল সূচক রক্ষণাবেক্ষণ


12

বিভাজন রোধ করতে এবং কিছু প্রশ্নের প্রয়োগ কার্যকর করতে মাইএসকিউএলে সূচকগুলি কীভাবে বজায় রাখা যায় সে সম্পর্কে আমি অনেক গবেষণা করেছি।

আমি সেই সূত্রের সাথে পরিচিত যা একটি সারণী ভিএসের জন্য সর্বাধিক স্থানের ডেটা এবং সূচী দ্বারা ব্যবহৃত স্থানের মধ্যে অনুপাত গণনা করে।

তবে আমার প্রধান প্রশ্নগুলি এখনও উত্তরহীন। সম্ভবত এটি এসকিউএল সার্ভারে সূচী রক্ষণাবেক্ষণের সাথে আমার পরিচিত এবং এই কারণেই আমার মনে হয় যে মাইএসকিউএলে এটি কোনওরকম সাদৃশ্যপূর্ণ হওয়া উচিত।

এসকিউএল সার্ভারে আপনার বেশ কয়েকটি সূচী থাকতে পারে এবং এর প্রতিটিটির আলাদা আলাদা স্তর থাকতে পারে। তারপরে আপনি একটি বাছাই করতে পারেন এবং বাকিগুলিকে প্রভাবিত না করে নির্দিষ্ট সূচকটিতে একটি 'পুনর্গঠিত' বা 'পুনরায়' অপারেশন করতে পারেন।

আমার জ্ঞানের সর্বোপরি, এখানে কোনও 'টেবিল বিভাজন' নেই এবং এসকিউএল সার্ভার 'টেবিলের খণ্ডন' ঠিক করার জন্য কোনও সরঞ্জাম সরবরাহ করে না। এটি যা সরবরাহ করে তা হ'ল সূচি বিভাজন (যা কোনও সূচী ভিএস দ্বারা ব্যবহৃত পৃষ্ঠাগুলির সংখ্যার অনুপাতের মতো বোঝা যায় that পৃষ্ঠার পূর্ণতা এবং স্বচ্ছলতা), পাশাপাশি অভ্যন্তরীণ এবং বাহ্যিক খণ্ড খণ্ডন করে।

এগুলি সমস্ত কিছু বোঝার পক্ষে আমার পক্ষে কমপক্ষে সহজবোধ্য।

এখন, যখন মাইএসকিউএল সূচকগুলি বজায় রাখার পালা আসে, কেবল উপরে উল্লিখিত হিসাবে কেবল 'টেবিলের খণ্ডন' ধারণাটি বিদ্যমান।

মাইএসকিউএলে থাকা একটি সারণীতে বেশ কয়েকটি সূচী থাকতে পারে, কিন্তু যখন আমি সেই বিখ্যাত সূত্রটি দিয়ে 'ফ্র্যাগমেন্টেশন রেশিও' পরীক্ষা করি, আমি প্রতিটি সূচির খণ্ডন দেখতে পাই না, পুরো টেবিলটি।

আমি যখন মাইএসকিউএল সূচকগুলি অপ্টিমাইজ করতে চাই তখন আমি কাজ করতে কোনও নির্দিষ্ট সূচক পছন্দ করি না (এসকিউএল সার্ভারের মতো)। পরিবর্তে, আমি পুরো টেবিলটিতে একটি 'অপ্টিমাইজ' অপারেশন করি, যা সম্ভবত সমস্ত সূচককে সম্ভবত প্রভাবিত করে।

যখন টেবিলটি মাইএসকিউএলে অনুকূলিত হয়, তখন ডেটা + সূচক ভিএস দ্বারা ব্যবহৃত স্থানের মধ্যে অনুপাত হ্রাস হয়, যা হার্ড ড্রাইভে কিছু ধরণের শারীরিক পুনঃ-সংগঠনের পরামর্শ দেয় যা শারীরিক স্থান হ্রাস করার জন্য অনুবাদ করে। তবে সূচি খণ্ডন কেবল শারীরিক স্থান সম্পর্কেই নয়, সন্নিবেশ এবং আপডেটের কারণে গাছের কাঠামোটি সময়ের সাথে পরিবর্তিত হয়েছে।

অবশেষে, আমি InnoDB / MySQL এ একটি টেবিল পেয়েছি। এই টেবিলটিতে 3 মিলিয়ন রেকর্ড, 105 কলাম এবং 55 সূচি রয়েছে। এটি সূচকগুলি বাদ দিয়ে 1.5 জিবি, যা 2.1 জিবি।

আপডেট করতে, সন্নিবেশ করানোর জন্য সেই টেবিলটি দিনের হাজার হাজার বার আঘাত হানছে (আমরা আসলে রেকর্ডগুলি মুছিনা)।

এই টেবিলটি কয়েক বছর যাবত তৈরি হয়েছে এবং আমি নিশ্চিত জানি যে কেউ কোনও সূচি বজায় রাখছে না।

আমি সেখানে একটি বিশাল টুকরো টুকরোটি খুঁজে প্রত্যাশা করছিলাম, তবে আমি যখন নির্ধারিত হিসাবে খণ্ডন গণনা সম্পাদন করি

free_space / (data_length + index_length)

দেখা যাচ্ছে যে আমার কাছে কেবলমাত্র 0.2% টুকরো টুকরো আছে। আইএমএইচও এটি বেশ অবাস্তব।

সুতরাং বড় প্রশ্নগুলি হ'ল:

  1. আমি কীভাবে মাইএসকিউএলে কোনও নির্দিষ্ট সূচীর টুকরো টুকরো টেকসই করব, পুরো টেবিলটি নয়
  2. টেবিল অপটিমাইজ করা কি আসলে এসকিউএল সার্ভারের মতো কোনও সূচকের অভ্যন্তরীণ / বাহ্যিক খণ্ড স্থির করে?
  3. আমি যখন মাইএসকিউএল-তে কোনও টেবিলটি অনুকূলিত করি তখন এটি কি টেবিলের সমস্ত সূচী পুনর্নির্মাণ করে?
  4. এটা কি ভাবা বাস্তববাদী যে কোনও সূচকের শারীরিক স্থান হ্রাস (গাছ নিজেই পুনর্নির্মাণ না করা) আসলে আরও ভাল পারফরম্যান্সে অনুবাদ করে?

অপ্টিমাইজ টেবিলটি অবশ্যই ইনসোডাবের ক্লাস্টারড ইনডেক্সটি পরিষ্কার করে

1
এটি একটি দুর্দান্ত প্রশ্ন, কেবল কোনও প্রোগ্রামিং নয়। এটি যেখানে যুক্ত হবে সেখানে স্থানান্তরিত হবে:>

উত্তর:


6

সূচক বিভাজন অনেকটা ওভাররেটেড। এটা সম্পর্কে চিন্তা করবেন না.

দুটি সংলগ্ন, কিছুটা ফাঁকা, ব্লকগুলি প্রাকৃতিক প্রক্রিয়াজাতকরণ হিসাবে InnoDB দ্বারা একত্রিত করা হয়েছে।

একটি BTree এ র্যান্ডম ক্রিয়াকলাপগুলি স্বাভাবিকভাবে গড় গড় 69% এর দিকে মহাকর্ষ ঘটায়। অবশ্যই, এটি 100% নয়, তবে "ফিক্সিং" এর ওভারহেড এটি মূল্যবান নয়।

SHOW TABLE STATUS আপনাকে কিছু মেট্রিক সরবরাহ করে তবে সেগুলি ত্রুটিযুক্ত - "ডেটা_ফ্রি" তে নির্দিষ্ট "মুক্ত" স্থান অন্তর্ভুক্ত থাকে তবে অন্যান্য "ফ্রি" স্পেস থাকে না।

প্রতিটি ব্লকে অব্যবহৃত স্থান রয়েছে; বিনামূল্যে 16 কেবি ব্লক; বিনামূল্যে "এক্সটেন্টস" (এনএমবি খণ্ড); এমভিসিসি সারিগুলি কাটার জন্য অপেক্ষা করছে; নন-লিফ নোডগুলির নিজস্ব বিভাজন রয়েছে; প্রভৃতি

কোনও সূচক কত বড় (ব্লকের সংখ্যা) তা দেখার পারকোনা এবং ওরাকলের বিভিন্ন উপায় রয়েছে। "ফ্রি" এর সীমিত সংজ্ঞার কারণে আমি তাদের উভয়কেই দরকারী বলে মনে করি না। দেখে মনে হয় যে ব্লকগুলি (প্রতিটি 16 কেবি) খণ্ডে বরাদ্দ করা হয়েছে (বেশ কয়েকটি এমবি), যার ফলে এটি বিশ্বাস করে যে সেখানে সমস্ত প্রকার বিভাজন রয়েছে। বাস্তবে, এটি সাধারণত এই বহু-এমবি অংশগুলির মধ্যে বেশিরভাগ। এবং OPTIMIZE TABLEঅগত্যা কোনও স্থান পুনরুদ্ধার করে না।

যদি এসকিউএল সার্ভার বিটিআর ব্যবহার করে, তবে এটি "মিথ্যাচার নেই" বলে মিথ্যা বলছে। "ব্লক বিভাজন" এর কি হবে তা ভেবে দেখুন। অথবা ক্রমাগত ডিফ্র্যাগমেন্টিংয়ের ওভারহেডটি ভাবেন। যেভাবেই আপনি হারাবেন।

আরও নোট করুন যে একটি টেবিল এবং সূচকগুলি মূলত অভিন্ন কাঠামো:

  • কিছু সূচকের উপর ভিত্তি করে বি + ট্রি
  • "ডেটা" প্রাথমিক কী উপর ভিত্তি করে; প্রতিটি গৌণ সূচকটি তার সূচকের ভিত্তিতে একটি বি + ট্রি হয় is
  • "ডেটা" এর পাত নোডে টেবিলের সমস্ত কলাম রয়েছে।
  • গৌণ সূচকের পাতার নোডে সেই মাধ্যমিক সূচকের কলামগুলি, এবং মূল কী এর কলামগুলি থাকে।

যদি আপনার কাছে থাকে তবে আপনি innodb_file_per_table = ONফাইলটির আকারটি দেখে অপ্টিমাইজ টেবিলের পরে সঙ্কুচিত (যদি থাকে তবে) দেখতে পাবেন .ibd। কারণ OFF, তথ্যটি সমাহিত করা হয়েছে ibdata1তবে SHOW TABLE STATUSযুক্তিসঙ্গতভাবে সঠিক হতে পারে যেহেতু সমস্ত "ফ্রি" স্থানটি প্রতিটি টেবিলের অন্তর্গত। ঠিক আছে, প্রাক বরাদ্দ খণ্ডগুলি ছাড়া।

আপনি খেয়াল করতে পারেন যে একটি সতেজ অপ্টিমাইজড ফাইল-প্রতি-সারণী সারণিতে ঠিক 4 এম, 5 এম, 6 এম, বা 7 এম ডাটা_ফ্রি রয়েছে। আবার এটি পূর্ব বরাদ্দ, এবং আপনাকে মিনিটের বিশদ বিবরণ দিতে ব্যর্থ।

আমি এক দশকেরও বেশি সময় ধরে ইনোডিবি-র সাথে কাজ করেছি; আমি বড় এবং ছোট হাজার হাজার বিভিন্ন টেবিলের সাথে কাজ করেছি। আমি বলি যে হাজারে মাত্র একটি টেবিলের সত্যই প্রয়োজন OPTIMIZE TABLE। অন্যান্য টেবিলগুলিতে এটি ব্যবহার করা অপচয়।

105 কলামগুলি অনেক বেশি, তবে সম্ভবত খুব বেশি নয়।

আপনার কি এক টেবিলে 55 টি সূচক রয়েছে? এটা খারাপ. এটি প্রতি 55 আপডেট INSERT। এর আরও আলোচনা করা যাক। মনে রাখবেন যে INDEX(a)এটি অকেজো যদি আপনারও থাকে INDEX(a,b)। আর INDEX(flag)কম cardinality কারণ অনর্থক। (তবে INDEX(flag, foo)দরকারী হতে পারে।)

প্রশ্ন 1: ডেটা বা গৌণ সূচকগুলিতে বিভক্তকরণের সমস্ত প্রকারের জন্য যাচাই করার ভাল কোনও উপায় নেই।

Q2 এর, চতুর্থাংশ 3: OPTIMIZE TABLEদ্বারা টেবিল পুনঃনির্মাণ CREATEingএকটি নতুন টেবিল এবং INSERTingসব সারি, তারপর RENAMEingএবং DROPping। পিকে আদেশে ডেটা পুনরায় সন্নিবেশ করানো নিশ্চিত করে যে ডেটাটি ভাল-ডিফ্র্যাগমেন্টযুক্ত। সূচকগুলি অন্য বিষয়।

Q4 ই: আপনি পারে DROP এবং reCREATEপ্রতিটি সূচক এটা পরিষ্কার করতে। তবে এটি একটি অত্যন্ত ধীর প্রক্রিয়া। 5.6 এর কিছু স্পিডআপ রয়েছে, তবে তারা জানি না তারা ডিফ্রেগমেন্টেশনে সহায়তা করে কিনা।

এটাও সম্ভব হয় ALTER TABLE ... DISABLE KEYS, তাহলে ENABLEতাদের। এটি একইসাথে সমস্ত গৌণ সূচকের আরও কার্যকর পুনর্নির্মাণ করতে পারে।


রিক, আমার অর্থ '105' ক্ষেত্র, ফাইল নয়
নিকোলাস

1

আমি কীভাবে মাইএসকিউএলে কোনও নির্দিষ্ট সূচীর টুকরো টুকরো টেকসই করব, পুরো টেবিলটি নয়

পাস।

টেবিল অপটিমাইজ করা কি আসলে এসকিউএল সার্ভারের মতো কোনও সূচকের অভ্যন্তরীণ / বাহ্যিক খণ্ড স্থির করে?

এটি সম্পূর্ণরূপে সারণী এবং এর সূচীগুলি পুনরায় তৈরি করে।

আমি যখন মাইএসকিউএল-তে কোনও টেবিলটি অনুকূলিত করি তখন এটি কি টেবিলের সমস্ত সূচী পুনর্নির্মাণ করে?

একই উত্তর একই প্রশ্ন।

এটা কি ভাবা বাস্তববাদী যে কোনও সূচকের শারীরিক স্থান হ্রাস (গাছ নিজেই পুনর্নির্মাণ না করা) আসলে আরও ভাল পারফরম্যান্সে অনুবাদ করে?

তা চিন্তা করা আপনি স্থান কমাতে পারে বাস্তবসম্মত নয় ছাড়া গাছ পুনর্নির্মাণ। তারা একসাথে যেতে।


# 1 এর উত্তর দেওয়ার জন্য: যদিও এটি খুব সঠিক নয় তবে এটি কলামে SHOW TABLE STATUS LIKE 'mytable'একটি ইঙ্গিত দেবে data freedev.mysql.com/doc/refman/5.6/en/show-table-status.html
জেহাদ কেরিয়াকি

আমি জানি, তবে এখনও এটি একটি নির্দিষ্ট সূচকের জায়গাটি হারিয়েছে
নিকোলাস
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.