দাবি অস্বীকার: দয়া করে ডাটাবেস ইন্টার্নাল সম্পর্কে আমার জ্ঞানের অভাবটি ক্ষমা করুন। এখানে এটা যায়:
আমরা একটি অ্যাপ্লিকেশন চালিত করি (আমাদের দ্বারা লিখিত হয় না) যা ডাটাবেসে পর্যায়ক্রমিক ক্লিনআপ জবটিতে একটি বড় পারফরম্যান্স সমস্যা আছে। ক্যোয়ারীটি এমন দেখাচ্ছে:
delete from VARIABLE_SUBSTITUTION where BUILDRESULTSUMMARY_ID in (
select BUILDRESULTSUMMARY_ID from BUILDRESULTSUMMARY
where BUILDRESULTSUMMARY.BUILD_KEY = "BAM-1");সোজা এগিয়ে, পড়তে সহজ এবং স্ট্যান্ডার্ড এসকিউএল। কিন্তু দুর্ভাগ্যক্রমে খুব ধীর। ক্যোয়ারির ব্যাখ্যা দেওয়ার মাধ্যমে দেখা যায় যে বিদ্যমান সূচকটি VARIABLE_SUBSTITUTION.BUILDRESULTSUMMARY_IDব্যবহৃত হয়নি:
mysql> explain delete from VARIABLE_SUBSTITUTION where BUILDRESULTSUMMARY_ID in (
-> select BUILDRESULTSUMMARY_ID from BUILDRESULTSUMMARY
-> where BUILDRESULTSUMMARY.BUILD_KEY = "BAM-1");
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+--------------------+-----------------------+-----------------+----------------------------------+---------+---------+------+---------+-------------+
| 1 | PRIMARY | VARIABLE_SUBSTITUTION | ALL | NULL | NULL | NULL | NULL | 7300039 | Using where |
| 2 | DEPENDENT SUBQUERY | BUILDRESULTSUMMARY | unique_subquery | PRIMARY,key_number_results_index | PRIMARY | 8 | func | 1 | Using where |এটি এটিকে খুব ধীর করে তোলে (120 সেকেন্ড এবং আরও বেশি)। এগুলি ছাড়াও, এটি এমন কিউরিগুলি ব্লক করে বলে মনে হচ্ছে যা সন্নিবেশ করানোর চেষ্টা করে BUILDRESULTSUMMARY, এর থেকে আউটপুট show engine innodb status:
---TRANSACTION 68603695, ACTIVE 157 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 360, 1 row lock(s)
MySQL thread id 127964, OS thread handle 0x7facd0670700, query id 956555826 localhost 127.0.0.1 bamboosrv updating
update BUILDRESULTSUMMARY set CREATED_DATE='2015-06-18 09:22:05', UPDATED_DATE='2015-06-18 09:22:32', BUILD_KEY='BLA-RELEASE1-JOB1', BUILD_NUMBER=8, BUILD_STATE='Unknown', LIFE_CYCLE_STATE='InProgress', BUILD_DATE='2015-06-18 09:22:31.792', BUILD_CANCELLED_DATE=null, BUILD_COMPLETED_DATE='2015-06-18 09:52:02.483', DURATION=1770691, PROCESSING_DURATION=1770691, TIME_TO_FIX=null, TRIGGER_REASON='com.atlassian.bamboo.plugin.system.triggerReason:CodeChangedTriggerReason', DELTA_STATE=null, BUILD_AGENT_ID=199688199, STAGERESULT_ID=230943366, RESTART_COUNT=0, QUEUE_TIME='2015-06-18 09:22:04.52
------- TRX HAS BEEN WAITING 157 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 38 page no 30140 n bits 112 index `PRIMARY` of table `bamboong`.`BUILDRESULTSUMMARY` trx id 68603695 lock_mode X locks rec but not gap waiting
------------------
---TRANSACTION 68594818, ACTIVE 378 sec starting index read
mysql tables in use 2, locked 2
646590 lock struct(s), heap size 63993384, 3775190 row lock(s), undo log entries 117
MySQL thread id 127845, OS thread handle 0x7facc6bf8700, query id 956652201 localhost 127.0.0.1 bamboosrv preparing
delete from VARIABLE_SUBSTITUTION where BUILDRESULTSUMMARY_ID in (select BUILDRESULTSUMMARY_ID from BUILDRESULTSUMMARY where BUILDRESULTSUMMARY.BUILD_KEY = 'BLA-BLUBB10-SON')এটি সিস্টেমকে ধীর করে দেয় এবং আমাদের বৃদ্ধি করতে বাধ্য করেছিল innodb_lock_wait_timeout।
আমরা মাইএসকিউএল চালানোর সাথে সাথে, "যোগ থেকে মুছুন" ব্যবহার করতে মুছুন কোয়েরিটি আবার লিখেছি:
delete VARIABLE_SUBSTITUTION from VARIABLE_SUBSTITUTION join BUILDRESULTSUMMARY
on VARIABLE_SUBSTITUTION.BUILDRESULTSUMMARY_ID = BUILDRESULTSUMMARY.BUILDRESULTSUMMARY_ID
where BUILDRESULTSUMMARY.BUILD_KEY = "BAM-1";এটি পড়ার চেয়ে সামান্য কম সহজ, দুর্ভাগ্যক্রমে কোনও স্ট্যান্ডার্ড এসকিউএল (যতদূর আমি এটি জানতে পেরেছি), তবে এটি সূচকটি ব্যবহার করে অনেক দ্রুত (0.02 সেকেন্ড বা তার বেশি):
mysql> explain delete VARIABLE_SUBSTITUTION from VARIABLE_SUBSTITUTION join BUILDRESULTSUMMARY
-> on VARIABLE_SUBSTITUTION.BUILDRESULTSUMMARY_ID = BUILDRESULTSUMMARY.BUILDRESULTSUMMARY_ID
-> where BUILDRESULTSUMMARY.BUILD_KEY = "BAM-1";
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-----------------------+------+----------------------------------+--------------------------+---------+--------------------------------------------------------+------+--------------------------+
| 1 | SIMPLE | BUILDRESULTSUMMARY | ref | PRIMARY,key_number_results_index | key_number_results_index | 768 | const | 1 | Using where; Using index |
| 1 | SIMPLE | VARIABLE_SUBSTITUTION | ref | var_subst_result_idx | var_subst_result_idx | 8 | bamboo_latest.BUILDRESULTSUMMARY.BUILDRESULTSUMMARY_ID | 26 | NULL |অতিরিক্ত তথ্য:
mysql> SHOW CREATE TABLE VARIABLE_SUBSTITUTION;
| Table | Create Table |
| VARIABLE_SUBSTITUTION | CREATE TABLE `VARIABLE_SUBSTITUTION` (
`VARIABLE_SUBSTITUTION_ID` bigint(20) NOT NULL,
`VARIABLE_KEY` varchar(255) COLLATE utf8_bin NOT NULL,
`VARIABLE_VALUE` varchar(4000) COLLATE utf8_bin DEFAULT NULL,
`VARIABLE_TYPE` varchar(255) COLLATE utf8_bin DEFAULT NULL,
`BUILDRESULTSUMMARY_ID` bigint(20) NOT NULL,
PRIMARY KEY (`VARIABLE_SUBSTITUTION_ID`),
KEY `var_subst_result_idx` (`BUILDRESULTSUMMARY_ID`),
KEY `var_subst_type_idx` (`VARIABLE_TYPE`),
CONSTRAINT `FK684A7BE0A958B29F` FOREIGN KEY (`BUILDRESULTSUMMARY_ID`) REFERENCES `BUILDRESULTSUMMARY` (`BUILDRESULTSUMMARY_ID`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin |
mysql> SHOW CREATE TABLE BUILDRESULTSUMMARY;
| Table | Create Table |
| BUILDRESULTSUMMARY | CREATE TABLE `BUILDRESULTSUMMARY` (
`BUILDRESULTSUMMARY_ID` bigint(20) NOT NULL,
....
`SKIPPED_TEST_COUNT` int(11) DEFAULT NULL,
PRIMARY KEY (`BUILDRESULTSUMMARY_ID`),
KEY `FK26506D3B9E6537B` (`CHAIN_RESULT`),
KEY `FK26506D3BCCACF65` (`MERGERESULT_ID`),
KEY `key_number_delta_state` (`DELTA_STATE`),
KEY `brs_build_state_idx` (`BUILD_STATE`),
KEY `brs_life_cycle_state_idx` (`LIFE_CYCLE_STATE`),
KEY `brs_deletion_idx` (`MARKED_FOR_DELETION`),
KEY `brs_stage_result_id_idx` (`STAGERESULT_ID`),
KEY `key_number_results_index` (`BUILD_KEY`,`BUILD_NUMBER`),
KEY `brs_agent_idx` (`BUILD_AGENT_ID`),
KEY `rs_ctx_baseline_idx` (`VARIABLE_CONTEXT_BASELINE_ID`),
KEY `brs_chain_result_summary_idx` (`CHAIN_RESULT`),
KEY `brs_log_size_idx` (`LOG_SIZE`),
CONSTRAINT `FK26506D3B9E6537B` FOREIGN KEY (`CHAIN_RESULT`) REFERENCES `BUILDRESULTSUMMARY` (`BUILDRESULTSUMMARY_ID`),
CONSTRAINT `FK26506D3BCCACF65` FOREIGN KEY (`MERGERESULT_ID`) REFERENCES `MERGE_RESULT` (`MERGERESULT_ID`),
CONSTRAINT `FK26506D3BCEDEEF5F` FOREIGN KEY (`STAGERESULT_ID`) REFERENCES `CHAIN_STAGE_RESULT` (`STAGERESULT_ID`),
CONSTRAINT `FK26506D3BE3B5B062` FOREIGN KEY (`VARIABLE_CONTEXT_BASELINE_ID`) REFERENCES `VARIABLE_CONTEXT_BASELINE` (`VARIABLE_CONTEXT_BASELINE_ID`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin |(কিছু জিনিস বাদ দেওয়া হয়েছে, এটি বেশ প্রশস্ত টেবিল)।
সুতরাং আমি এই সম্পর্কে কিছু প্রশ্ন আছে:
- যোগদানের সংস্করণটি ব্যবহার করার সময় কোয়েরি অপ্টিমাইজারটি যখন সাবকোয়ারি সংস্করণটি মুছে ফেলার জন্য মুছে ফেলার জন্য সূচকটি ব্যবহার করতে সক্ষম হয় না কেন?
- সূচকটি ব্যবহার করে চালাকি করার কোনও (আদর্শ মান অনুসারে) উপায় আছে কি? অথবা
- একটি লেখার একটি পোর্টেবল উপায় আছে
delete from join? অ্যাপ্লিকেশনটি জেডিবিসি এবং হাইবারনেটের মাধ্যমে ব্যবহৃত পোস্টগ্রাইএসকিউএল, মাইএসকিউএল, ওরাকল এবং মাইক্রোসফ্ট এসকিউএল সার্ভার সমর্থন করে। VARIABLE_SUBSTITUTIONসন্নিবেশগুলিতে ব্লক করা থেকে মুছে ফেলা হবে কেনBUILDRESULTSUMMARY, যা কেবলমাত্র সাবলেটতে ব্যবহৃত হয়?
পারকোনা সার্ভার 5.6.24-72.2-1.jessie resp 5.6.24-72.2-1.wheezy (পরীক্ষার সিস্টেমে)।
—
0x89
হ্যাঁ, পুরো ডাটাবেস ইনোডাব ব্যবহার করে।
—
0x89
সুতরাং এটি 5.5 অপ্টিমাইজার উন্নত তেমন মনোযোগ পায় নি বলে মনে হয়। আপনি 5.7 জন্য অপেক্ষা করতে হবে (কিন্তু যদি আপনি করতে পারেন MariaDB চেষ্টা করবেন তাদের অপটিমাইজার উন্নতি তাদের 5.3 এবং 5.5 সংস্করণে ফিরে সম্পন্ন করা হয়।।)
—
ypercubeᵀᴹ
ডায়াল্ট সাবকিউরিটি অপ্টিমাইজড বা ৫.7 করার জন্য কোনও হাইপারইপ নেই আফ্রিক्यूब আফাইক মুছে ফেলা নির্বাচন থেকে পৃথকভাবে অনুকূলিতকরণ।
—
মরগান টকার