মাইএসকিউএল খুব সাধারণ নির্বাচনী প্রশ্নের উপর অত্যন্ত ধীর


10

আমাদের ভার্চুয়াল মেশিনে একটি সাধারণ ওয়েব অ্যাপ্লিকেশন চলছে যা InnoDB ইঞ্জিনের সাহায্যে একটি MySQL 5.5 ডাটাবেসে এর ডেটা সংরক্ষণ করে। প্রায় তিন বছর ধরে সবকিছু ঠিকঠাক কাজ করেছিল, তবে হঠাৎ এটি অত্যন্ত ধীর হয়ে গেছে।

উদাহরণস্বরূপ, আমার কাছে খুব সাধারণ টেবিল হোল্ডিং ঠিকানা রয়েছে:

CREATE TABLE `addresses` (
  `address_id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(64) CHARACTER SET latin1 NOT NULL,
  `firstname` varchar(64) CHARACTER SET latin1 NOT NULL,
  `street` varchar(64) CHARACTER SET latin1 NOT NULL,
  `housenumber` varchar(16) CHARACTER SET latin1 NOT NULL,
  `zip` varchar(5) CHARACTER SET latin1 NOT NULL,
  `city` varchar(64) CHARACTER SET latin1 NOT NULL,
  `email` varchar(64) CHARACTER SET latin1 NOT NULL,
  `phone` varchar(16) CHARACTER SET latin1 NOT NULL,
  `birthdate` date NOT NULL,
  PRIMARY KEY (`address_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin

এই টেবিলটি প্রায় 800 টি এন্ট্রি ধারণ করে যা সত্যিই খুব বেশি নয়। কিন্তু ক্যোয়ারী চালাচ্ছে

SELECT * FROM addresses

পরীক্ষার উদ্দেশ্যে, এটি শেষ হয় না বলে মনে হয়। আমি এটি সার্ভারে মাইএসকিএল সিএলআই দিয়ে পরীক্ষা করেছি: এটি টেবিলের কিছু সারি আউটপুট করে এবং পরবর্তী সারিগুলি আউটপুট না হওয়া পর্যন্ত খুব দীর্ঘ সময় অপেক্ষা করে।

সুতরাং এটি ডেটা প্রেরণ পর্বে সমস্যা হতে পারে তবে আমি নিশ্চিত নই।

ভিএমটিতে 2 জিবি র‌্যাম রয়েছে এবং কেবল 320 এমবি ব্যবহৃত হয়। সিপিইউও খুব কম 1 থেকে 2% এ চলে। মাইটোপ সার্ভারটি অবরুদ্ধ করে এমন কোনও কোয়েরি দেখায় না। আইটি প্রশাসক বলেছেন যে তারা হার্ডওয়ারের দিক থেকে কোনও পরিবর্তন করেনি।

আমি ইতিমধ্যে ডাটাবেস সার্ভার পুনরায় চালু করা, ভার্চুয়াল মেশিনটি পুনরায় চালু করার মতো কিছু জিনিস চেষ্টা করেছি। কিছুই সাহায্য করেনি।

সম্পাদনা:

EXPLAIN SELECT * FROM addresses

আমাকে এই ফলাফল দেয়:

+----+-------------+-----------+------+---------------+------+---------+------+------+-------+
| id | select_type | table     | type | possible_keys | key  | key_len | ref  | rows | Extra |
+----+-------------+-----------+------+---------------+------+---------+------+------+-------+
|  1 | SIMPLE      | addresses | ALL  | NULL          | NULL | NULL    | NULL |  793 |       |
+----+-------------+-----------+------+---------------+------+---------+------+------+-------+
1 row in set (0.00 sec)

ভার্চুয়াল বক্স, জেন বা অন্য কিছু? হোস্ট ডিস্ক সেট আপ করা হয় কিভাবে? একই বাক্সে অন্যান্য ভিএম আছে কি ধীর গতিতে চলছে? এই প্রশ্নের উত্তর দেওয়া উত্তর প্রকাশ করতে পারে
ম্যাট

আমি হাইপারভাইজারের মালিক নই, সুতরাং আমি সত্যই এর উত্তর দিতে পারি না। হাইপারভাইজারের প্রশাসককে আমি ইতিমধ্যে জিজ্ঞাসা করেছি তারা সাম্প্রতিক কোনও পরিবর্তন সম্পর্কে জানে কিনা, তবে তিনি না বলেছিলেন।
ট্যাব

যদি আপনি পারেন তবে মাইএসকিএল বন্ধ করুন এবং কিছু ডিস্ক এবং মেমোরি বেঞ্চমার্ক চালান। জটিল হতে হবে না। ধারণাটি কেবল আলাদা করতে হবে যদি এটি মাইএসকিএল নিয়ে সমস্যা হয়, সম্ভবত নীচের উত্তরে নির্দেশিত সূচীর সমস্যা, বা আরও বিস্তৃত।
ম্যাট

ভাল কথা, আমি সম্ভবত এটি কোনও মাইএসকিএল সমস্যা না হওয়ার অভিজ্ঞতা পেয়েছি। রানিং mysql -u username -ppassword mydb -e 'SELECT * FROM addressesআউটপুট করছে ধীরে ধীরে, তবে `> test.txt` যুক্ত করে এটি খুব দ্রুত চলে। এখন এটি সম্ভবত অন্যরকম প্রশ্ন হবে !? আমি কীভাবে এই বিষয়ে তদন্ত করতে পারি?
ট্যাব

হাইপারভাইজারের মালিকের সাথে যোগাযোগ করুন এবং কোনও ত্রুটির জন্য লগগুলি চেক করতে বলুন। বিশেষত ডিস্ক ত্রুটি। তাকে আপনার লক্ষণগুলি বলুন। এখনি ব্যাকআপ করে নিন.
ম্যাট

উত্তর:


13

যদি সিপিইউ লোড কম হয় তবে এটি সূচিত করে যে অনুপস্থিত সূচকে কোনও সমস্যা নেই, যদি এমনটি হয় তবে ক্যোয়ারিতে আরও সিপিইউ এবং ডিস্ক অ্যাক্সেস নেওয়া দরকার need এছাড়াও আপনি বলেছিলেন যে এটি 3 বছর ধরে ভাল কাজ করেছে।

আপনি কি সাধারণ ডিস্ক অ্যাক্সেসের গতি পরীক্ষা করেছেন (বিশেষত পার্টিশনে যেখানে ডাটাবেস রয়েছে)? যেমন dd এখানে মত ব্যবহার । আপনি মৃত ডিস্ক বা অর্ধ-মৃত অভিযানের মতো শব্দগুলির বর্ণনা দিচ্ছেন। আশা করি ব্যাকআপ পেয়েছি?


এটা একটা ভাল দিক. এটি হোস্টে ডিস্ক ত্রুটির মতো সাধারণ কিছু হতে পারে।
ম্যাট

9

আপনি কয়েকটি জিনিস চেষ্টা করতে পারেন,

  1. আপনার কি সূচি সেটআপ আছে?

ইনডেক্সিং প্রথমে একটি পূর্ণ টেবিল স্ক্যান না করে দ্রুত রেকর্ডগুলি সন্ধান করা সম্ভব করে, কার্যকরভাবে নাটকীয়ভাবে কাটায়।

CREATE INDEX idx_name ON addresses(name);
  1. ক্যোয়ারী চালানোর আগে প্রথমে এক্সপ্ল্যান কীওয়ার্ডটি ব্যবহার করুন,

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

  1. আপনার mysql.ini এ কিছু পরিবর্তন করুন, যদি এটি কোনও ভিএম র‌্যাম বাড়ায় এবং আপনার mysql.ini কনফিগার করে পারফরম্যান্স বৃদ্ধি পায় কিনা।

অনেকগুলি মাইএসকিউএল অপ্টিমাইজার রয়েছে যা আপনাকে গাইড করতে পারে।

এই সাহায্য করে


ঠিক আছে, তবে বেশ ছোট টেবিলের উপর একটি সূচক তৈরি করা (<800 সারি) আমার প্রয়োজনের মতো তেমন সহায়ক হবে না বলে মনে হচ্ছে। উপরে উদ্ধৃত কোয়েরিটি শেষ হতে এক মিনিটের বেশি সময় লাগে। এই জাতীয় ছোট টেবিলের একটি পূর্ণ টেবিল স্ক্যানটি এত বেশি সময় নেওয়া উচিত নয়।
ট্যাব

তো ... আপনি কি সূচকগুলি যুক্ত করেছেন? সমস্যাটি কী তা আপনি যদি নিশ্চিত না হন তবে আমি বেসিক শুরু করব এবং আমার পথে নামব। সূচকগুলি যুক্ত করা যদি সঠিকভাবে করা হয় তবে কর্মক্ষমতা বাড়বে।
অ্যান্থনি ফোরনিতো

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

আমি উপরে বর্ণিত ক্যোয়ারির ফলাফল যুক্ত করেছি result এটি আমার কাছে দুর্দান্ত দেখায়, তবে অভিনয়টি এখনও খুব কম। আমি ভার্চুয়ালাইজেশন ম্যানেজারের প্রশাসক না হওয়ায় আমি র‌্যাম বাড়াতে পারি না। তবে htopদেখায় যে 2050MB র‌্যামের মধ্যে কেবল 307MB ব্যবহৃত হয়।
ট্যাব

ইনডেক্স সম্পর্কে আপনাকে কী কলামগুলির সূচকে সত্যই ভাবতে হবে, আপনি কেবল সমস্ত কিছু সূচী করতে চান না, সর্বাধিক পরিমাণে যেগুলি সূচী করতে চান, আমি এটি সম্পর্কে কিছু বুনো অনুমান করছি তবে আমি শুরু করব nameএবং 'প্রথম নাম' দিয়েছি। দ্বিতীয়টি আপনি কি নিশ্চিতভাবেই সঠিকভাবে ইনডেক্সিং করেছিলেন? সম্ভব_কিগুলি: শূন্যস্থানটি যদি কলামটি নুল হয় তবে এটি কোনও সূচক খুঁজে পাওয়া যাবে না।
অ্যান্টনি ফরনিটো
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.